STANAG-4538 LDL packets retransmissions, an interesting case

A few days ago I was casually watching the 4 MHz band when an unusually long STANAG-4538 (3G-HF) transmission on 4561.0 KHz/USB caught my attention and I decided to record it for later analysis.
Basically, in the usual STANAG-4538 way (ARQ), after the data link connection has been configured, the sending station and the receiving station alternate transmissions: the sending station transmitting xDL PDUs (Protocol Data Unit) containing payload data packets and the receiving station transmitting acknowledgment/control packets of whether or not the data packet in the preceding PDU was received without error (1). In this case the LDL protocol is used (Figure 1).

Fig. 1 - STANAG-4538 LDL transfer

As per STANAG-4538, the "original" datagram to be sent is split into fixed-length segments which will be processed into packets by the chosen LDLn protocol. Indeed, a LDL data packet is defined as a fixed-length sequence of n-byte data segment (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused). During the construction of the LDL BW3, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the  data bits of each data packet and then appended. Then, 7 flush bits having the value 0 are added to ensure that the encoder is in the all-zero state upon encoding the last flush bit. Sumarizing, the on-air length of a LDLn BW3 burst is computed in bit as 8n + 64, in this case (LDL512, n = 512) 4096+64 = 4160 bit or 520 bytes (Figure 2).

Fig. 2 - LDL512 demodulated bitstream

That said, we can inspect the last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits) of the recorded BW3 bursts  (Figure 3).

Fig. 3 - last 64 bits of the demodulated LDL512 bitstream

The 8-bit reserved field is added after the CRC field and not after the Sequence Number, as specified in Annex C to STANAG-4538; I don't know if it's the modus operandi of the decoder. Moreover, the bits of the Sequence Number field are transmitted starting with the Last Significant Bit (bit 0) rather than the most significant bit (bit 16), most likely it's the modus operandi of the decoder, as above.
In this sample you may see that the Packet Number #3 is sent 20 times and it clarifies the unusually length of the transmission (actually the number of packet retransmissions is greater than 20 since some bursts were not correctly demodulated, hence not present in Figures, due to their bad SNR value). The Packet Byte Count field is always 511, this means it's a LDL512 transfer. The EOM & SOM fields are both set to "0" meaning that's an "interior" packet. The CRC fields show the same value.

110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
110000  111111111 00  10110010110011010001111111100111 000000000000000
3           511          EOM                 CRC field                          control + flush bits
                             SOM

I stopped recording after more than 5 minutes, see Figure 4, and most of the time (4 minutes and 4 seconds!) was spent on the transmissions of the single packet #3; also note the repeated transmissions of packets #2 (2 times) and #4 (6 times) at the beginning and end of the recording (Figs. 2,3).

Fig. 4 - duration of the whole recording (software "audacity")

 

So, why so many retransmissions? 

STANAG-4538 is designed for High-Frequency (HF) radio communication, which is notorious for having a highly unstable and challenging channel environment. The large number of retransmissions may be a direct consequence of the protocol's need to ensure reliable data delivery over this unreliable medium. STANAG-4538 employs an ARQ (Automatic Repeat reQuest) scheme as part of its data link protocols to achieve this reliability. The maximum number of retransmissions in ARQ schemes is specified by the parameter N_tx (or often N_max​ or N_retries​): if the packet is not acknowledged as successfully received after the last retransmission it is typically discarded by the data link layer, and the link connection may be closed (2).  This clause normalizes the trade-off between reliability and efficiency/latency (preventing the channel from being permanently blocked by an unrecoverable packet). 

The usual or default value for the N_tx parameter is not specified in standard documentation summaries, not even in STANAG-4538, as it is a configurable parameter of the HF modem which is set by the manufacturer or even by the system operator. In commercial and military HF implementations of similar ARQ schemes, the maximum retransmission count is often set to a value like 4, 8, or 10, but the actual number should be verified against the specific equipment's configuration settings.

One of the causes of retransmissions is poor HF channel conditions: fading, multipath distortion, noise, interference and man-made interference (from electronics or other users). Any of these factors can cause bit errors in the received packet, which the receiver detects via a checksum (CRC) and then requests a retransmission of the corrupted packet.
A second important cause is the Adaptive Code Combining (Hybrid-ARQ). Indeed,  STANAG-4538's data link protocols utilize a form of Hybrid-ARQ with code combining. This mechanism is specifically designed to work in poor channels and directly contributes to retransmissions. Instead of just discarding an unreadable packet, the receiver stores the corrupted data. When a retransmitted copy of that same packet arrives, the receiver combines the information from all received copies (the original and all retransmissions) to try and successfully decode it. The fact that it takes over 20 attempts may mean the combined information only reaches the decoding threshold after a significant number of transmissions.

In short, the retransmissions aren't necessarily a sign of failure, but rather the core mechanism of STANAG-4538 actively working to provide error-free data transfer despite the inherent unreliability of the HF radio channel.

It should also be considered that the used KiwiSDR receiver [1] is a sort of "man in the middle", i.e. it sees all the traffic on the channel, but this does not necessarily apply to the stations actually involved (not all data/ACK packets can be correctly received by the two peers).

So, it is likely that the N_tx parameter is set to a value greater than 20 and channel conditions are very poor... but we could also consider another cause besides  STANAG-4538 ARQ.
Perhaps we are observing retransmissions "forced" by the higher-layer protocol running over the STANAG-4538 data link (running at Layer 2), specifically TCP (Transmission Control Protocol, running at Layer 4). The limit of N_tx applies strictly to the LDL/ HDL protocol itself. A high retransmission count may occur because of the interaction between the two layers, particularly when running IP over HF:

 

- STANAG-4538 (Layer 2) action
the STANAG-4538 data link protocol tries to deliver a single packet  and if all attempts fail, it discards the packet and moves on to the next one. Result: The packet is considered lost by the Data Link Layer.
- TCP (Layer 4) action
TCP is the reliable transport protocol often used for applications like web browsing, email, or file transfer, and it runs over IP, when a packet is lost by the lower layer (Layer 2, STANAG-4538), the TCP sender never receives an acknowledgment for that packet, TCP's retransmission timer eventually expires, and it assumes the network failed to deliver the data (TCP is not HF-aware!), crucially, TCP retransmits the data independently of the Layer 2 protocol.
- the domino effect
STANAG-4538 transmits a packet several times, it fails and discards the packet. TCP times out. It retransmits the data. The new TCP segment is given to STANAG-4538 which treats it as a new packet to send. STANAG-4538 transmits this "new" packet up to N_tx times again. If it fails again, TCP times out a second time, and the process repeats until the packet is successfully acknowledged.

If the channel conditions are so poor that the STANAG-4538 link fails more than N_tx times in a row before TCP gives up, the total number of retransmissions for a single packet could easily assume a large value, as the higher layer continually resubmits data to the persistently failing lower layer.
Anyway, technically TCP cannot directly cause packet retransmission, only STANAG-4538 does that: TCP increases the likelihood of retransmissions, but it does not initiate them!

Summarizing: 

N_tx parameter is set to a large value (>20) to prioritize ultimate delivery reliability over speed and to support Hybrid-ARQ mechanism

or

N_tx parameter is set to a low value (often in the range of 3 to 10 or similar small number) and TCP times out and re-injects the data.

Definitely channel conditions were undoubtedly poor and severe.

 

Perhaps - in my opinion - it would have been better to use LDL packets size smaller than 512 bytes (4160 bits). Under poor channel conditions, a smaller packet size is generally better, even though the number of packets increases. Shorter transmissions (reduced airtime) reduce exposure to fades, have lower probability of interference and collisions, enable faster ARQ cycles and improve latency:
large packet → high chance of corruption → many retransmissions

small packet → lower chance of corruption → fewer retransmissions (even though more packets)

 

Fig. 5 - Packet Error Probability (PEP) vs. packet length (theoretical model)

The airtime, or duration, of STANAG-4538 LDLn BW3 bursts is variable and depends on the amount of data being sent, specified by the parameter n. The total burst duration is given by the formula: duration (ms) =373.33 + n×13.33, (n = 32,64,96,...,512).

The possible total airtimes for a single BW3 burst for the four standard BW3 burst sizes (n=64,128,256,512) are:

n Value	Payload Duration	Total Burst Duration
64	853.12 ms	1226.45 ms (≈1.23 seconds)
128	1706.24 ms	2079.57 ms (≈2.08 seconds)
256	3412.48 ms	3785.81 ms (≈3.79 seconds)
512	6824.96 ms	7198.29 ms (≈7.20 seconds)

 

Longer packets like $n=512$ transmit more data per burst, leading to higher throughput, but they are also significantly more vulnerable to errors (higher PEP) since require a much longer airtime (up to $7.2$ seconds).

[1] recording tanks to linkz KiwiSDR #3 (French Alps)

https://disk.yandex.com/d/2r0xOdGLWu45UA

 

(1) STANAG-4538 xDL protocols:
HDL (High-throughput Data Link protocol) waveforms: BW1 for acknowledgement and traffic management, BW2 for traffic data
LDL (Low-latency Data Link protocol) waveforms: BW3 for traffic data, BW4 for acknowledgement and traffic management
HDL+ waveforms: BW6 for acknowledgement and traffic management, BW7 for traffic data

(2) Why the Limit is Necessary
HF Channel Volatility: HF radio conditions are highly variable due to ionospheric fading and noise. While the LDL protocol uses Code Combining (Hybrid-ARQ) to increase the likelihood of decoding a packet with each attempt, a limit is needed to account for extreme or prolonged channel outages.
Preventing Link Stall: Unlimited retransmissions would cause the entire data link to stall, continually trying to send a packet that may be unrecoverable due to a sudden deep fade or interference. By limiting the attempts, the protocol can decide to terminate the link and allow the higher layers (or the operator) to attempt a new link setup on a different, possibly better, frequency. 

 

about the unid 32-bit protocol used in S-4538 + MS-110A transfers

This is the third time I have encountered these transmissions [1] and, given the good number of recordings made over a few days on the frequency 6964.5 KHz/USB, it is now possible to draw a more definitive "picture".

Transmissions normally occur each 5 minutes and last 1.5 - 2 minutes average. STANAG-4538 (3G-HF) "circuit mode service" is used, where MS-110A (usually in 75bps/Long Interleaver mode) is the used traffic waveform; sometimes a transmission may consist of two or more distinct data transfer sessions (Figure 1).

Links are established using the FLSU (Fast Link SetUp) Asynchronous scanning call, using BW5 and an "optimized" waveform which provides no repetition of the initial TLC section (used for transmitter level control and receiver AGC settling). Such a scanning 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 TLC. All succeeding LE_Scanning_Call PDUs and the LE_Call PDU shall omit TLC, and include only the BW0 preamble and data portions" (1)(2). So, we look at 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 most likely implemented by L3Harris [2][3]. That "formation" of the Async call clarifies why decoders recognize only the "first" BW5 PDU. 

Fig. 1

Looking at the asynchronous scan calls, at first glance it seems that Linking Protection (LP) is not used: in fact, as you can see, the decoded strings are identical. This should not happen since when operating in encrypt mode, the LP algorithm takes as inputs the PDU to be scrambled, a key variable, and a “seed” that contains Time of Day (TOD) and the frequency that carries the protected transmission.

2024-08-21T09_54_32Z BW-5 00111001010000100011011001001010011110001000011010
2024-08-21T09_56_17Z BW-5 00111001010000100011011001001010011110001000011010
2024-08-21T10_01_54Z BW-5 00111001010000100011011001001010011110001000011010

2024-08-22T07_46_52Z BW-5 00010110100000110011111110111010101110111100000110
2024-08-22T07_51_52Z BW-5 00010110100000110011111110111010101110111100000110

Anyway, it's to note that when the protection against spoofing offered by LP is not required, LP may be used without a key variable or seed to provide only scrambling based on the network number as described in STANAG-4538 4.1.2 (in this regard, note that the scanning calls of 2024-08-22, for example, do not have the expected value "001" in the first three bits). 

The analysis of the MS-110A decoded bitstreams show initial 100 bytes length headers which have some parts common to all the bitstreams, the header "format" is more evident after the removal of the initial "10"s sequence (Figures 2,3).

Fig. 2

Fig. 3

In my opinion, headers are made up of the following structure (Figure 4):

1) common initial sequence

1100000100011100101001 (maybe 001100000100011100101001, 0x0CE294)

2) common 193 bits length "01"s sequence, (phasing?). Boundaries are marked by two consecutive logical "1"

3) common 160 bits / 20 bytes length sequence (sync sequence for the receive crypto device?)

10001011010001111000010010000111
01111011101101001011100010000111
01000100011110000100100001110111
10111011010010111000101101110100
01000111100001001000011101111011

4) 256 bits / 32 bytes length sequence which is different in every bitstream (Initialization Vector?)

5) common 5×32 bits / 4 bytes repeated sequence (frame sync?). Note that the sequence can't be an Initialization Vector since it's always the same in every bitstream.

10001011010001111000010010000111
10001011010001111000010010000111
10001011010001111000010010000111
10001011010001111000010010000111
10001011010001111000010010000111

Also note that the 4 bytes repeated sequence is used in the first 4 bytes of the 160 bits sequence.

Fig. 4 - the common blocks in the headers of the bitstreams

According to the results of the "Shannon Entropy" and "Statistical" tests, the ansferred data are most probably encrypted (Figure 5).
The measure of the Shannon Entropy can be used, in a broad sense, to detect whether data is likely to be structured or unstructured. 8 is the maximum, representing highly unstructured, 'random' data. Properly encrypted or compressed data should have an entropy of over 7.5 The statistical test below determines the randomness, the number of single bits in the stream is counted, then the double bits, then the triple bits and so on to the end. The result is a graph: if the information is not systematic, the adjacent columns should be half the size of the previous ones. Both the test shows good encryption quality.

Fig. 5 - Shannon Entropy and Statistical tests on the data portions

The transmissions are fairly receivable only in the northern regions of Europe, likely a low power transmitter is used or a local/domestic area shall be served. Just about the site of the transmitter,  all my direction finding attempts point to a quite large area in Norway (Figure 6): maybe a Royal Norwegian Navy Tx? Anyway, it's to notice that the DF results "suffer" from the lack of detection points west of Norway.

Fig. 6 - Direction finding attempts (TDoA algorithm)

Monitoring & recordings thanks to the remote KiwiSDRs SM0KOT (Sweden) and OZ1AEF (Denmark) [4][5]. 

https://disk.yandex.com/d/AcwncUTKxXlQ_A (decoded bitstreams)

(1) 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.

(2) 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".

[1] http://i56578-swl.blogspot.com/search/label/P%3D32
[2] http://i56578-swl.blogspot.com/2022/10/harris-3g-ale-flsu-async-call.html
[3] http://i56578-swl.blogspot.com/2022/10/harris-3g-ale-flsu-async-call-2.html
[4] http://aspliden.kostet.se:8074/
[5] http://85.191.35.22:8073/

 

3G-HF Fast Traffic Manager (FTM) at work

This sample provides an example of the use of 3G-HF (STANAG-4538) Fast Traffic Manager (FTM) protocol, which is sometimes referred to as simply FLSU (Fast Link SetUp). More precisely, FLSU is used to set up links, and it includes the traffic type that will be used immediately after the link set up is complete; FTM is used after the FLSU for cases in which the traffic type needs to be changed, or to negotiate channel access among linked stations.
As stated in S-4538 Annex-C Edition1 Amendment2, if a link has been established for delivery of packet traffic using the HDL+ data link protocol (BW7), all FTM and FLSU Protocol Data Units (PDUs) transmitted for the remaining duration of the packet link shall be transmitted using the BW6 burst waveform: thus, since the use of BW6, the link was initialized for HDL+ protocol. But, as you can see in Figure 1, at some point an FTM negotiation causes the change of the traffic type: from HDL+  (BW7 waveform) to LDL (BW3 waveform).

Fig. 1 - traffic type change

It's worth noting the use of BW4 waveform bursts after LDL data delivery, it's requested by the #4.6.5 Dual Demodulation condition: "Under no circumstances shall stations be required to simultaneously demodulate more than two waveforms. Any scenario requiring more than dual-demodulation is either an error in the specification or an error in interpretation" (1).

 
By the way, the BW3 burst transports a L3Harris "Citadel" encrypted message (Figure 2).

Fig. 3

https://disk.yandex.com/d/YCupV-cFBXOmqQ

(1) HDL+ states is missing in the Table 4.6.5-1: however, since BW6 burst waveform is used for Ack/EOM/Term messages, Master and Slave stations expect to receive a BW6 or a BW7 waveform.

LDL 139-byte packets

For a few days I have been following the 3G traffic that takes place on 6682.0 KHz/USB and I have noticed that many of the transfers are exactly the same length (139 bytes) and follow the same sending formality, ie the protocol used is LDL (3G-HF STANAG-4538) and are retransmitted twice within the same link session.

Fig. 1

The caller node issues a 2-way FLSU_Request Protocol Data Unit (PDU) which conveys the caller node address,  priority, and the desired traffic service (packet or circuit mode). The called node responds with a FLSU_Confirm PDU, indicating the ability to continue with the requested traffic service. As it's known, FLSU protocol use the BW5 waveform.
Both the caller and called alternate sending LDL PDUs, with the caller sending data using the LDL Data Send PDU (BW3), and the called responding with the LDL ACK/NAK PDU (BW4).  This process continues until all data has been transferred error-free, as indicated by the caller sending redundant LDL End Of Message (EOM) PDU’s. Immediately after the LDL transfer is complete, both stations iunitiate the Fast Traffic Management (FTM) protocol to negotiate further traffic. This gives the called node an opportunity to send data in the reverse direction. After a the Link Timeout has occurred, the last station to receive an LDL transfer terminates the link by sending an FLSU_Term PDU. It's worth noting that after the EOM PDUs, both nodes remain linked (!) and given that the caller has already completed its data transfer, it is up to the called node to deliver any packet traffic it has, or to terminate the link if it doesn't have traffic to send. Note that:
- the EOM PDU indicates to the receiving station that the data transfer will be terminated;
- the Term PDU indicates to the receiving station the sender’s departure from the current link.
in EMCON scenarios the link termination is up to the caller node

Fig. 2

In these recordings, packet-mode service and LDL160 protocol are used. Before analyzing the bitstreams let's see how an LDL packet is built.
The "original" datagram to be sent is split into fixed-length segments which will be processed into packets by the chosen LDL protocol. An LDL data packet is defined as a fixed-length sequence of n-byte data segment (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused). During the construction of the LDL BW3, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the  data bits of each data packet and then appended. Then, 7 flush bits having the value 0 are added to ensure that the encoder is in the all-zero state upon encoding the last flush bit. Sumarizing, the on-air length of a LDLn burst is computed in bit as 8n + 64 (n = 32,64,96,...,512 bit), in this case (LDL160, n = 160) 1334 bit or 168 bytes.
That said, lt's go back to two decoded LDL packets (belonging to the same link session) by inspecting their last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits):

Fig. 3

Let's try to analyze the 139 bytes messages. As indicated by the value of the bits 5-0 (all 0s, Packet Number #0) and SOM/EOM bits (all 1s) the original datagram consists of only one packet, the Packet Byte Count field (bits 14-6) indicates that the user bytes are 139 thus the remaining 21 bytes are filled with 0s.

0000000000000000000000000000000010000000100000001011010001111000
0110101001111000011010100111100001101010011110000000000001011000
1011101001011000101110100101100010111010010110001011101011010010
1010001111010011100111110000100101010011101000110011010010101101
0110100100111000000101000100011001100010011001010001100010111100
0110010010100001001101111111111100011001101100011001010001010011
1001010110000111011010110010100100001001110101111101000100100111
1010110000001010010010100101011000010100000001000100011001110110
1100110001101100001101110001011100011010110101101010010101010101
0001011010001100000011010111111111110110111000110001111001111110
1101100010101100011000010000111011001100111001101101011110011010
0111111010011110001001000010011100100000000010101011100111010110
0110111110101011111110110100010001110011100001001010100001100101
0011000110100011000111111011111101011000111001001010010101011100
0111010011110011000010100011010001111110100101101001100101001010
1010001000110100111100000101011110100010010110111101001101000101
0001110110100001011010010111100001101010011110000110101001111000
0110101001111000010000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000101000101110110111001010011111111001011110000000000000000

The analysis of the bitstreams shows that each datagram is always sent twice (Figs 4,5): I don't know if it's due to a negative ACK sent back by the reiceiver or rather a usual way of doing to give redundancy and reliability to the system.

Fig. 4

 

Fig. 5

After the removal of the 31-byte encapsulation added by the Harris "Citadel" cripyographic engine

00 00 00 00 01 01 2D 1E 56 1E 56 1E 56 1E 00 1A 5D 1A 5D 1A 5D 1A 5D (header)
1E 56 1E 56 1E 56 1E 02 (tail)

the resulting datagrams consist of 108 bytes. Such messages are very frequent(!), also sent using the circuit-mode service and MS-110A as traffic waveform. Sometimes it's occured to see that the 139-byte encrypted message is split into five packets and then sent using LDL32 [1] or even 9 times repeated using LDL160 [2], as shown in the Sequence Number fields in Figure 6

Fig. 6

https://disk.yandex.com/d/Ug94lJ40coIUDg

[1] https://yadi.sk/d/PvOS5FbM3H96Wz
[2] https://yadi.sk/d/_SCU3U073GzPf9

Harris' 3G-ALE FLSU Async call (2)

Commenting the recent post about the Harris's implementation of the FLSU Async call [1], an anonymous reader sent me a good quality recording of that signal. Observing the spectrum/time FFT of figure 1 the call has a duration of about 9 seconds (9170 ms) and, according to the value of the ACF , it consists of 10 BW5 frames. By calculating the respective durations and taking into account the omission of the TLC sections exceeding the first, we get

1013.33 + (9 × 906.66) = 9173.27 ms

ie a value that matches the duration of the call and confirms the FLSU Async call implementation adopted by Harris (by the way, a 7-channel scan list in this sample).

Fig. 1

In addition to the time based approach, in order to verify the above results I tried a tribit symbols based analysis of the demodulated bitstream. Indeed, as per STANAG-4538 (and 188-141B too) the TLC section (256 pseudo-random tribit symbols) and BW5 preamble sequence (576 tribit symbols) are modulated directly without undergoing the PN spreading thus their patterns are easily identifiable within the bitstream. A good way to bring out the two desired sequences is to use synchronization of the bitstream:

a) synchronizing on the preamble sequence
10 rows come out, which therefore correspond to the preambles of the 10 BW5 PDUs (don't fall into the 4-bit HEX trap: since the PSK8 modulation, the symbols we are looking consist of tribit values, ie 4,4,7,3,... = 100, 100, 111, 011,...):

Fig. 2

b) synchronizing on the TLC sequence
as expected, the result consists of only 1 row which is just the one relating to the "entire" first BW5 PDU:

Fig. 3

As a further confirmation, I synchronized the stream on the "border" of the two sequences getting a single row result:

Fig. 4

So, in my opinion, both approaches demonstrate the composition of the FLSU Async call which is implemented by Harris: ie, the TLC section is sent only in the firts BW5 PDU (as per 188-141B #C.5.2.4.5.2):

 

Looking at the bitstream, it's also  evident that this network uses the Linking Protection (LP) procedure [2]. As per STANG-4538 #9.3.2 "Scanning call PDUs shall be scrambled using alternating word numbers 00000000 and 00000001. The word number used in scrambling the first scanning call PDU shall be selected so that the scanning call PDU sent immediately before the Call PDU is scrambled using word number = 00000001. The Call PDU that concludes an asynchronous-mode call shall be scrambled using word number = 00000010": that's the reason of the alternating patterns of figure 5.

 

Fig. 5

By the way, it's worth noting that LP does not address jamming or similar techniques, which are best countered by TRANSEC, nor is it intended to replace the COMSEC function of traffic protection: indeed, LP protects the linking function, including related addressing and control information.

 

A recent monitoring of 6.9 MHz band by my friend ANgazu (who I thanks for sending some recordings) shows the use of the same async call also in WBALE & WHARQ scenarios:

 

Fig. 6

 

https://disk.yandex.com/d/JCbCPlmTV_wl1g (Harris Async call)

https://disk.yandex.com/d/IQe71tmy0VIA3g  (WBALE & WHARQ)

[1] https://i56578-swl.blogspot.com/2022/10/harris-3g-ale-flsu-async-call.html
[2] https://i56578-swl.blogspot.com/2017/02/stanag-4538-3g-ale-flsu-calls-with.html

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/

a long (and protected) FLSU async scanning call

STANAG-4538 async call of FLSU protocol consists of the transmission of 1.35N (nearest integer value) Request type 3 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 period in seconds; the "scanning call" ends with a single FLSU request PDU of type 0 (Fig. 1). Since up to 61 requests are used, 45 are the allocated channels for this network.

000 10 1000100000 1010100110 0 0 011 101100 011111 11011111
001 00 1101010101 0010000011 0 1 110 001100 010111 01011010
000 10 1000100000 1010100110 0 0 011 101100 011111 11011111
001 00 1101010101 0010000011 0 1 110 001100 010111 01011010
000 10 1000100000 1010100110 0 0 011 101100 011111 11011111
001 00 1101010101 0010000011 0 1 110 001100 010111 01011010
000 10 1000100000 1010100110 0 0 011 101100 011111 11011111
...
...
001 10 1000100101 0111010110 0 0 011 011111 000101 00110111
 

Fig. 1 - LFSU async call

One might be wondering why the 61 requests have different formats: the answer is that the calling station uses the Linking Protection (LP) procedure. 3G-ALE LP scrambles the 50-bit PDUs using a scrambling algorithm that depends on a key variable, the time of transmission of the PDU, and the frequency on which it is sent (the latter two dependencies enter via a seed that is distinct from the key variable). The 50-bit PDUs are scrambled using alternating the two "Word Numbers" (provided by the seed) 00000000 and 00000001 while the PDU of type 0 that concludes the asynchronous call is scrambled using the "Word Number" 00000010: thus that the same PDU is scrambled 61 times (in this sample) using two alternating keys, that's the reason of the alternating patterns seen above. The effect of this alternating scrambling is also reproduced in the ACF function of figure 2.

Fig. 2 - Auto Correlation Function of the async call

The scrambling  procedure use the SoDark-6 algorithm (48-bit length) and then only the last rightmost 48 bits of each FLSU PDU are scrambled so the first leftmost two bits are sent without scrambling. 

Note that LP does not address jamming or similar techniques, which are best countered by TRANSEC, nor is it intended to replace the COMSEC function of traffic protection. LP protects the linking function, including related addressing and control information.

https://disk.yandex.com/d/YM8rWZvP4heOoA (wav)
https://disk.yandex.com/d/wNR0-nLOl7i87g (bitstream)

STANAG-4538 to forward 188-220 App.D (SINCGARS) Tx frames to HF

6898 KHz/USB seems to be a good place to catch transmissions which deal with STANAG-4538 3G-HF and COMSEC. After the 256-bit Initialization Vectors encryption, it happened to hear some STANAG-4538 transmissions that used the LDL protocol: nothing particularly interesting except for the transported datagrams that are certainly attributable to SINCGARS traffic which is usually exchanged, however, between 30 and 88 MHz! Indeed, after the analysis of the LDL bitstreams, it turned out that MIL 188-220 App. D "COMMUNICATIONS SECURITY STANDARDS" (shortly idicated as 188-220/D) exactly describes the structure of the transmitted datagrams.
In short, SINCGARS (Single Channel Ground and Airborne Radio System) [1] is a VHF Combat Net Radio (CNR) [2] WF providing secure voice and data communications; MIL 188-220 [3] is a military standard that governs the use of Combat Net Radios and covers layers 1 through 3 (physical, data link, and network) of the OSI stack.

Fig.1 - STANAG-4538 LDL session

LDL protocol analysys
Each LDLn transfer consists of a TX Frame consisting of one data packet. A data packet is defined as a fixed-length sequence of n-byte data (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused), both added by the LDL protocol. Each TX Frame is sent using burst waveform BW3. During the construction of BW3, a 32-bit CRC is computed across the data bits of each data packet and is then appended to it. Then, 7 flush bits having the value 0 are added to ensure that the encoder is in the all-zero state upon encoding the last flush bit. Sumarizing, the on-air LDLn bits are equal to 8n + (17+8+32+7)  or  8n + 64 (n  =  32,64,96,...,512).

That said, we can go back to the original datagram by inspecting the last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits) of the four BW3 bursts (Figure 2). In this sample the values of the Packet Number fields are: 0,0,1,1: most likely, each TX Frame is sent twice to improve the reliability of the transfer (the receive station discards the duplicated packets). Correspondly, the values of the single Packet Byte Count fileds are 415 (110011111) and 346 (101011010): this means that LDL416 protocol is used and therefore the original datagram was splitted into two packets each of 416 and 347 bytes (the Packet Byte Count field contains the number of user bytes -1). 

Fig. 2 - LDL overhead bits

Datagram analysis
The original datagram can be retrieved by reshaping the bitstream in a 3392-bit period (ie (8 × 416) + 64),  isolating the four rows, removing either the duplicated packets and the 64 overhead bits: the resulting bitstream is shown in Figure 3.

Fig. 3 - the original 15-bit period datagram

As said, 188-220/D exactly describes the regular patterns which compose the datagram, particularly the COMSEC preamble field that consist of three components: the bit synchronization subfield (it may consists of a string of alternating ones and zeros), the Frame Synchronization subfield, and a Message Indicator (or Initialization Vector, IV) subfield (Figure 4).

Fig. 4 - traditional COMSEC transmission frame structure (MIL 188-220 App.D)

As per 188-220/D #D.5.1.1.2, frame sync subfield, and Message Indicator are encoded using Phi patterns, a method of redundantly encoding data bits :

a logical "1" data bit is encoded as a Phi(1) = 111101011001000
a logical "0" data bit is encoded as a Phi(0) = 000010100110111

A simple majority voting process may be performed at the receiver to decode the Phi-encoded patterns to their origlnal format. 

 

It's to notice that the Phi patterns are generated by the polynomial x^4+x+1 [initial state 1,1,1,1]: this could be misleading if you are looking for a suitable descrambler for the preamble.

I extracted the original datagrams from three STANAG-4538 transmissions heard on 6898 KHz, removed the initial (long) bit sync subfields and placed the bitstreams side by side for better visibility of the COMSEC Frame Sync and IV subfields (Figure 5).

 

Fig. 5 - COMSEC preambles

As you see the Frame Sync subfield is the same in the three datagrams, this subfield is 465 bits long and consists of 31 Phi-encoded bits (as per 188-220/D): 

 

01) 111101011001000 → 1
02) 111101011001000 → 1

03) 111101011001000 → 1 

...

29) 111101011001000 → 1

30) 111101011001000 → 1
31) 000010100110111 → 0 

 

As expected, the pattern resulting after Phi-decoding matches exactly the one reported in 188-220/D:

 

1111111111111111111111111111110

 

The Initialization Vector subfield, a stream of random bits, is redundantly encoded using Phi patterns and is 1305 bits long (87 Phi-encoded bits) in all the three datagrams:

 

01001101001000000010001010110011110110110011

0111010010000110001011111010001111101000011
 

11100011100001100011110000110000101100111111

1100101101010111010101011111110100000000011

11101011101000001110101100100000000001001100

0110101100101010101001001010110101110010001

 

The ecrypted data block follows the Initialization Vector subfield, the external crypto device is presumably KY-57 [4] or the more advanced KY-99.

 

The same frame structure, and the same subfields lengths, was found in

- SINCGARS transmissions heard on 33 MHz (low VHF, GFSK 16000 Baud) (Figure 6)

- SATCOM transmission heard on 261.5 MHz (UHF, FM 16000 Baud) [5]

Fig. 6 - frame structure of a SINCGARS transmission

 

i.e. just where do you expect to find it (V/UHF).

 

Conclusions are hard to draw from such observations: since the LDL packets transport whole 188-220/D frames "as is", STANAG-4538 appears to be used as a kind of "bridge or relay" between V/UHF and HF (Figure 7).

 

Fig. 7

 

It sounds quite weird and unusual but however this is what was on-air. What is it, then? 

Since this type of transmission occurred several times and for some days, I tend to exclude that it was an operator mistake or a malfunction of the equipment: both would have been noticed and perhaps fixed. Maybe some kind of tests? Anyway, I find it difficult to think that such a mix is possible by using a "traditional" setup. Indeed, I think that using a SCA-based Software Defined Radio a skilled operator could instantiate a 188-220/D + S4538 session, but... why? Using a such SDRs configuration would be possible outrun the transmission range of (VHF line-of-sight) SINCGARS, but honestly such a solution seems rather crude and impractical. Maybe it was just occasional needs to forward 188-220/D frames to a certain HF endpoint.

In conclusion, at present I don't have a clear explanation and comments will be greatly appreciated. For completeness, it should be added that in these days I have tried some sporadic monitoring but I have not been able to hear these transmissions anymore (at least on 6898 KHz).

 

A big thank to my friend KC9FFV Marco (Forney, TX USA) who allowed me to use his KiwiSDR beyond the 120 minute time limit [6].
 

 

https://yadi.sk/d/uXodd0sc6oiLLw 

 

[1] https://en.wikipedia.org/wiki/SINCGARS

[2] https://en.wikipedia.org/wiki/Combat-net_radio

[3] https://yadi.sk/i/pauZfUz63Nxs-g

[4] https://www.cryptomuseum.com/crypto/usa/ky57/

[5] http://www.radioscanner.ru/forum/../msg335301

[6] http://marcocam.selfip.com:8073