Harris' 3G-ALE FLSU Async call: a 141B/STANAG-4538 optimised implementation?

I recently had the chance to study some good quality recordings of (certified) Harris 3G-ALE Asynchronous calls and surprisingly I found some features of implementation derived from the now superseded 188-141B that are not defined - or even not supported - by the relevant standard STANAG-4538.

More than once I came across such type of "long duration" FLSU bursts and so far I have always identified them as FLSU Asynchronous calls (STANAG-4538) [1][2] ...but this time it is not like that. What doesn't fit is that while each burst 2-4-6 consists of a single FLSU BW5 PDU (Protocol Data Unit), as expected, also the bursts 1-3-5, although of longer duration, seem apparently formed of single FLSU BW5 PDUs (figure 1).

Fig. 1 - Harris 3G-ALE bursts

A short recap for background... 

As per STANAG-4538 #5.1.3, the Asynchronous call consists of a "sequence" of FLSU PDUs sent consecutively, more precisely:
"The Asynchronous call begins with the LBT [...] followed by the transmission of about 1.35N Async FLSU_Request PDUs on the requested link frequency, where N is the number of channels in the scan list, and 1.35 is the duration of each dwell (in seconds) [...] the sequences of the Async FLSU_Requests (Type-3 PDU) is then terminated by one normal FLSU_Request (Type-0 PDU)"(1):

Fig. 2 - Asynchronous FLSU call (1) (FIGURE 5.1.10-4 STANAG-4538)

Therefore, the Async FLSU call is easily reacognizable by the 1013ms "spikes" (ie the duration of the BW5 PDU) resulting from its Cross-Correlation Function. Obviously, the 7296-bit (or 2432-tribit symbols) period of the bitstream matches the PSK8 symbols of the BW5 waveform. Figure 3 shows the CCF and the bitstream of an Async call recording ( the .wav file is in the download list).

Fig. 3 - CCF and bitstream of the FLSU Async call

The 50-bit frames resulting from its demodulation (fortunately Linking Protection was not used) are consistent with the standard protocol. By the way, since the 10 Type-3 PDUs, the scan list consists of 8 channels.

 

That said, let's back to the Harris 3G-ALE recordings.

The Cross-Correlation Function of bursts 1-3-5 shows strong ~906ms spikes instead of the expected 1013ms ones, consequently the demodulated bitstreams have a 6528-bit period length which in turn makes 2176 PSK8 symbols: so, we have  

 

(2432 - 2176) = 256 missing symbols

Fig. 4 - CCF and bitstream of the Harris FLSU Async call

Looking at the BW5 timing, the initial TLC section consists of 256 PSK8 symbols: well, these are exactly the symbols that we are looking for! 

I mean that the TLC section is sent only in the first BW5 PDU thus the following ones are a bit shorter being composed of only the preamble and data sections: hence the (576 + 1600) = 2176 symbol length period and the ~906ms CCF spikes. This "formation" of the Async call also clarifies why my decoder recognizes only the "first" BW5 PDU (figure 1). By the way, the value 

1013.33 + (5 × 906.66) = 5546.63ms 

fits perfectly in Harris recordings.

Fig. 5 - formation of the Harris FLSU Async call

Such a call is exactly described in paragraph C.5.2.4.5.2 of  MIL 188-141B Appendix C:
"The LE_Scanning_Call PDU shall be sent repeatedly to capture scanning receivers [...] During a scanning call, only the first LE_Scanning_Call PDU shall include Ttlc (used for transmitter level control and receiver AGC settling). All succeeding LE_Scanning_Call PDUs and the LE_Call PDU shall omit Ttlc, and include only the BW0 preamble (Tpre) and data (Tdata) portions".(2)(3)

So, we face a STANAG-4538 FLSU Async call (since the use of BW5 waveform) which is 188-141B compliant for what regards its formation (since the omission of  the TLC sections): ie, a sort of  188-141B/STANAG-4538 mixed implementation. Below I have tried to find a satisfactory answer to this "particular" 3G-ALE call.

For simplicity and clarity of exposition, for now on I will refer to:
- "188-141B" as an FLSU Async call with omitted TLC sections (only the firts one is sent);
- "STANAG-4538" as an FLSU Async call w/out the omission of the TLC sections;
the FLSU protocol obviously implies the use of BW5 PDUs.

One could say that, given the nature of the TLC section (basically 256 throwaway symbols), sending it in a sequence of contiguous BW5 PDUs would makes a poor sense... but that's not entirely true. It is possible to verify that, starting from a certain number of channels onwards, the TLC sections act as a "buffer" and, ultimately, allow a successfully link establishment. Indeed, defining "scan time" the interval of time required for scan N-1 channels, linking is successful as long as the scan time does not exceed the duration of the Async call (figure 6).

Fig. 6 - "scan time" Vs Async call duration

Suppose we have a 21 channel network: the worst case that can happen is that a 141B async caller begins a call on the last channel of the scan list (after a successful Listen Before Transmit interval) while the called station has just begun to dwell on the first channel. Let's calculate how many PDUs must be sent in the call:

1.35 × 21 = 28.35 ≅ 28 Async FLSU_Request PDUs + 1 normal FLSU_Request PDU

for a total duration of (including the initial 1350 milliseconds LBT interval):

1350 + 106.66 + (906.66 × 29) = 27749.8 ms.

The called station will employ (20 x 1350) = 27000 ms to come upon channel 21, so it will receive only a portion of  (27750 - 27000) = 750 ms of the Async call: this means that a part of the acquisition preamble of the final FLSU_Request will be lost and presumably the linking attempt will fail or at least will be at risk. Such a problem will not happen in case of a STANAG-4538 async caller, since its call will last:

1350 + (1013.33 × 29) = 30736.57 ms

therefore the called station will receive a quite large portion of about (30736.57 - 27000) = 3736.57 ms of the Async call (ie more than 3 times the duration of a BW5 FLSU PDU).(4)

I plotted the durations of Async calls and scan times versus a scan list of 5 to 30 channels: the results are quite interesting (figure 7). In case of 141B, starting from channel 16 the distance between the duration of the call and the scan time is getting thinner, until it becomes null or even negative. STANAG-4538 implementation instead maintains a quite wide margin (figures 7a). Then I plotted the the difference (async call duration - scan time) referred to the "useful" duration of a BW5 PDU ( 906.66ms, ie preamble + data): say a sort of measure of the "linking useful margin" versus the number of channels. In case of 141B calls, as expected, the linking gets problematic starting from a 16-channel scan list (figure 7b); no problems in case of S4538 calls (figure 7c).

Fig. 7

Well, how many channels can be allocated to a scan list? Looking at the framing of BW5, the "Argument 1" field reserves 6 bit for the channel; excluding the default value ("111111"), 63 values (0...62) remain available. As it was already evident from figure 7, a 141B Async call does not capture the called station in case of such a large number of channels but - conversely - it's best performing then STANAG-4538 in a network with a smaller scan set (number of channels < 17) just because it has a shorter call duration and therefore a faster linking time (figure 8).

Fig. 8

Probably the Harris' choice of omitting the exceeding TLCs just lies in the fact of better performance in small scan lists (say an "optimised" implementation): perhaps a specific algorithm chooses whether or not to omit the TLCs exceeding the first, or perhaps it's a manual setting. That solution is anyway not compatible with the 188-141B implementation (BW5 is unknown to that standard) and probably also with a "strict" implementation of STANAG-4538: the unanswered calls in figure 1 could be a sign of interoperabilty problems (5), who knows. Judging by the behavior of my decoder, however, I verified that in case of a "late entry" the decoding is successfully only when the Async call contains multiple TLCs: but it's just a decoder, I don't know the algorithm it uses and doesn't matter. Unfortunately I don't have a military grade STANAG-4538 appliance to test its responses, so further analysis are needed to confirm my guess.

I want to thank my friend ANgazu who helped in the analysis and identification of the signal and sent me some recordings of these "mixed" Async calls that he heard just some days ago around 6950 KHz: sign that this solution is still in use today.

https://disk.yandex.com/d/xbGLZvU5y5A1Qg 188-141B FLSU Async call (single TLC)
https://disk.yandex.com/d/gXsMejYAvHFstA   S4538 FLSU Async call (multiple TLCs)
(regarding the Harris recordings, the author prefers that I keep this material confidential)

Some ending comments:

a) I played Lego ® bricks with the burst #1 of the Harris recordings. Using the great tool Audacity ® [3] First I isolated and removed the TLC section of the first BW5, then I did my best by cutting the burst into segments each of 906.66 ms duration. Then I assembled a new burst by inserting the TLC section before each segment and putting it all together. The result confirms the expectations, apart from two error PDUs due to the approximate way of the cut & paste. By the way, five scanning PDUs mean 4 channels in the scan list.

b) You've probably noticed the possibility of a 768-bit/256-symbol period in figure 4:

 

As per STANAG.4538 #13.9.6, the BW5 PDU data symbols are PN-spread using a spreading sequence which is repeated every 4 blocks of 64 tribit sequences, ie every (64×4) = 256 symbols: these repetitions cause the 106.66ms ACF and hence the 256-symbol periodicity:

 By the way, yet another 106.66ms ACF...

(1) Transmitting 1.35N Async FLSU_Request PDUs guarantees that all other scanning PUs (Partecipating Units, ie the other nodes in the HF network) will scan the calling channel during the Async call, even under the worst case time of day offset conditions. If the time of day offset can be estimated more accurately, fewer than 1.35N Async FLSU_Request PDUs may be sent to capture the desired PU. Since the address of the called PU(s) is contained in the Async FLSU_Req PDU, all PUs that are not included in the call are free to resume scanning. Called PU(s) that receive one of the Async FLSU PDU’s stop scanning and wait for the normal FLSU_Request.

(2) MIL 188-141B refers to BW0 as the waveform to convey "LE_Scanning_Call PDU" and "LE_Call PDU" (LE stands for Link Establishment): FLSU, and consequently the BW5 waveform, were not yet defined at that time. 

(3) 188-141B (released on March 1999!) was superseded by 188-141C (December 2011), in its turn superseded by 188-141D (December 2017): the last two standards no longer have the Appendix C but only some short paragraphs, among them the #C.6 says "The specifications previously contained in this appendix have been replaced with reference to the essentially identical NATO STANAG 4538".

(4) The Called station that receive one of the asynchronous FLSU PDUs stop scanning and wait for the normal FLSU_Request PDU, which is sent immediately after the final Async_FLSU_Request PDU. After receiving a valid FLSU_Request PDU, the addressed stations responds normally with the FLSU_Confirm PDU (STANAG-4538 #5.1.3)

(5) The BW5 bursts 2-4-6 of figure 1 may convey the FLSU_Terminate link PDU (type-2) which is sent by the caller station in case of link failure (STANAG-4538 #5.1.5). Unfortunately, Linking Protection is used so the decoding does not help to indentify the used BW5 types.

[1] https://i56578-swl.blogspot.com/2019/10/async-flsu-followed-by-stanag-4197-3g.html
[2] https://i56578-swl.blogspot.com/2021/04/a-long-and-protected-flsu-async.html
[3] https://www.audacityteam.org/download/