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. 

 

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

STANAG-4538, LDL32 transfer bearing a clear-text message

The transmission was heard at 0904z on 11426.5 KHz USB (01 Feb 2018) and it's the first time I meet a clear-text message sent using a 3G-HF xDL protocol, in this case the LDL (Low-Latency Data Link) protocol.

In this transfer each LDL_DATA PDU carries a single data packet composed of 32 bytes of user data (LDL32 mode) followed by a 17-bit sequence number and an 8-bit control field (presently unused) added by the LDL protocol: this way the LDL32 PDUs are composed of 256+25 = 281 bits. The Burst Waveform 3 (BW3) is used for transfers of traffic data by the LDL protocol; BW3 computes and adds a 32-bit Cyclic Redundancy Check (CRC) to the LDL data packet plus 7 flush bits having the value 0, so the total length of an LDL32 BW3 is 281+32+7 = 320 bits (Figure 1).

Fig. 1 - LDL32 BW3 structure

As indicated in Figure 1, in order to get the user-data stream we have first to remove the first packet since it is sent twice, then remove the 64-bit LDL32 and BW3 overhead from each of the remaining 3 packets.  The result, 3 x 32-byte user data segments, is shown in Figure 2.

Fig. 2 - 3x32 byte user data segments

As you see the stream exhibits a 8-bit period and consists of a clear-text (not encrypted!) message composed using the  "Arabic chat alphabet" also known as Arabish:

KI YALHAG GHAZALI 3ANDKOM YAHBAT M3AH 5

"The Arabic chat alphabet is used to communicate in Arabic over the Internet or for sending messages via cellular phones. It is a character encoding of Arabic to the Latin script and the Arabic numerals.  Regional variations in the pronunciation of an Arabic letter can also produce some variation in its transliteration (e.g. ﺝ might be transliterated as j by a speaker of the Levantine dialect, or as g by a speaker of the Egyptian dialect)." [1] 
Since there are different transliterations depending on the region, and considering possible receive errors, the right English translation of the message is difficult. I tried to translate the received text directly into Arabic using the on-line google translator but got a bit poor meaning text ("So that you may go down with me") so I twitted a brief analysis hoping to have some useful comments... and I had them from my friends Guido (aka Decode_Signals) and - naturally - from KarapuZ.
Guido confirmed my opinion about the Arabish and advised the above link to wikipedia, while KarapuZ suggested another transliteration that probably makes a better sense: "(so that) he will come to Gaza with him" (Figure 3).

Fig.3 - the transliteration proposed by KarapuZ

I do not know who run the 11426.5 KHz frequency, AFAIK S-4538 is used in military environment, neither if the received text is a test message o a real message: maybe other messages (useful to understand the context) were sent just before and I did not hear them, anyway that frequency deserves to be monitored. 
I post the analysis for the same reason: anyone have some other comments or can shed a light on the meaning of the message?

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

https://yadi.sk/d/e5515bbl3S4EU8

short bit-analysis of a STANAG-4538 LDLn transfer (BW3 bursts)

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 segment (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 Cyclic Redundancy Check (CRC) value is computed across the  data bits of each data packet (8n+25 bits) and is then appended to the data packet. Then, 7 flush bits having the value 0 are appended to the data packet with CRC (8n+57 bits) 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 given by:

total on-air LDLn bits (n = 32,64,96,...,512) = 8n + 64

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 ten BW3 bursts  (Fig. 1):

Fig. 1

 Some aspects must be first considered:

a) 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;
b)  following the last bit of the Payload field-value, the bits of the Sequence Number field are transmitted starting with the least significant bit (bit 0) rather than the most significant bit (bit 16). Most likely it's the modus operandi of the decoder, as above;
c) as in the Sequence Number of HDL Tx frames (see the previous post), the bits 14-6 of the first packet in datagram contain the number of user bytes in packet -1 and this contrasts what specified in Table 7.1.4.1-2; it depends on the particular STANAG-4538 implementation?

In this sample the values of the Packet Number fields are: 0,0,1,1,2,2,3,3,4,4: maybe the destination station requested a retransmissions or, most likely, each TX Frame is sent twice so to improve the reliability of the transfer (also note the values of the CRC fields). Correspondly, the Packet Byte Count fileds are: 128,128,...,67,67, this means it's a LDL128 transfer.
Note that the bytes contained in the packet #4 is less than 128 bytes because it includes the last data byte of the original datagram (the remaining 128-67 bytes are filled with "0" value bytes). That said, the original datagram of this sample is composed of the single packet numbers 0,1,2,3,4 (ie BW3 #0, #2, #4, #6, #8) and its length is (128 x 4) + 67 = 579 bytes (Fig. 2); the receive station shall discard the duplicated packet numbers.
It's worth noting that in this sample there are no BW4 ACK bursts returned back: it could be an MDL (Multicast Data Link protocol) transmission or maybe I did not heard these bursts!

Fig. 2

Back to the whole bitstream, once structured in a 1088-bit period ((8 x 128) + 64), the original datagram can be extracted by isolating the firts 4 rows and removing the overhead bytes: the resulting is an HARRIS "Citadel" encrypted file (Fig. 3).

 

Fig. 3

The ten LDL128 bursts, the retransmitted packets, and the "0" value bytes fillers can be noted looking at the whole bitstream in Figure 4.

Fig. 4

https://yadi.sk/d/P0BIYELb3Lg5ex

splitting datagrams into LDLn Tx Frames

This post is added  to complete the previous one, so to study and verify the way a datagram is splitted to fit the length of the chosen LDLn Tx frame (n =32,64,96,…,512 bytes) and the mechanism used to fill the remaining room. This recording concerns a 139-byte lenght 'Citadel' encrypted datagram which is sent within five LDL32 PDUs, ie using 5 x 32 = 160 bytes: the protocol shall fill the extra 21 bytes of the last PDU with 0-value bytes (Fig. 1). 

Fig. 1

After the data link connection has been configured (FLSU/BW5), the sending station and the receiving station alternate transmissions in the usual STANAG-4538 manner: the sending station transmitting LDL PDUs containing payload data packets (BW3), and the receiving station transmitting ACK PDUs (BW4) each containing an acknowledgment of whether or not the data packet in the preceding LDL PDU was received without error. The sending station sends an EOM PDU (BW4) repeated as many times as possible to indicate to the receiving station that the the datagram have been delivered successfully and the link will be terminated (Fig. 2)

Fig. 2

For a better understanding of the way LDL protocol works the incoming datagram, let's see how the LDL PDU and BW3 are formed (quoting Annex C to NATO STANAG-4538).
If the Tx Frame buffer is clear, construct a new outgoing data packet in the following manner (Fig. 3):
1. Get the next data segment (the next PacketLength consecutive data bytes to be transmitted) from Tx Datagram buffer; place these in the Payload field of the data packet. If fewer than PacketLength data bytes remain to be transmitted, place these bytes at the
beginning of the Payload field; fill the remainder of the field with zero-valued bytes so that the Payload field contains a filled segment.
2. Construct a sequence number and write this value into the packet’s Sequence Number field.
3. Construct a control field with all 8 bits set to zero.
4. Place the data packet generated in steps 1-3 into the Tx Frame buffer.
5. Send an LD PDU containing the tx frame in Tx Frame buffer, using BW3 waveform.

Fig. 3

It's worth noting that:
- one LDLn Tx Frame, same as an LDLn PDU, consists of a single data packet of n-bytes (n=32,64,96,…,512); then LDLn delivers chunks of n-bytes at time (n=32,64,96,…,512);

- one HDLn Tx Frame, same as an HDLn PDU, consists of n-data packets each of 233 bytes (n=3,6,12,24); then HDLn delivers n-packets at time, each of 233 bytes (n=3,6,12,24).
 
The number of bits in a BW3 data packet is of the form 8n+25, where n = 32, 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, 480, or 512 (number of payload data bytes carried by each LDL protocol forward transmission);  the additional 25 bits of payload in each BW3 transmission are LDL overhead (17 bits Sequence number + 8 bits for reserved use). A 32-bit Cyclic Redundancy Check (CRC) value is computed across the payload data bits in the data packet, and is then appended to the data packet, then 7 flush bits having the value 0 are appended to the (8n+57) bits of the data packet with CRC to ensure that the encoder is in the all-zero state upon encoding the last flush bit.
So each BW3 data packet has a length of 8n+64 bits (8n+17+8+32+7): just the latest eigth bytes will be used for the analysis.

From theory to practice, the way the 139 byte datagram is splitted in five LDL32 Tx Frames can be verified by inspecting the  Sequence Number fields in the last 64 bits of the five BW2 data packets of the copied transmission (Fig. 4).

Fig. 4

Some aspects must be first considered:

a) 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;

b)  following the last bit of the Payload field-value, the bits of the Sequence Number field are transmitted starting with the least significant bit (bit 0) rather than the most significant bit (bit 16). Most likely it's the modus operandi of the decoder, as above;

c) as in the Sequence Number of HDL Tx frames (see the previous post), the bits 14-6 of the first packet in datagram contain the number of user bytes in packet -1 and this contrasts what specified in Table 7.1.4.1-2; it depends on the particular STANAG-4538 implementation?

c) the 'Packet Number', bits 5-0 in the Sequence Number field, indicates the position occupied by a data segment within a datagram. Since the datagram passed to LDL for delivery is an ordered sequence of up to 16,384,000 bytes (7,634,944 bytes for LDL), limiting the packets addressing to 6 bits could be fastidious in ARQ.

As expected, EOM and SOM fields (bits 16,15) show that the BW2 packet 0 contains the first packet of the datagram, while BW2 packet 4 contains the last packet of the datagram. Consequently, the Packet Number (bits 5-0) starts from 0 to 4: ie, the useful payload consists of five BW2 packets. Consider now the Packet Byte Count (bits 14-6): as already specified, this field show the number of user bytes in packet –1. Each of the first four packets contains 32 bytes (00001111 = 31) and the last packet contains 11 bytes (00001010 = 10). The outgoing datagram was then (4 x 32) + 11 = 139 bytes length.
During the traffic setup phase, the user process determines the number of data bytes per LDL PDU so as to deliver the user data efficiently. Once it is determined, every transmitted LDL PDU shall contain the same number of data bytes until the entire datagram has been delivered.

https://yadi.sk/d/PvOS5FbM3H96Wz
https://yadi.sk/i/UgFjnPTv3H97zz

 
 

an LDL160 transfer with nine retransmissions

this is a copy of an 10 x LDL160 transfer, heard on 8327.0KHz/USB, with up to nine retransmissions of the same 'Citadel' encrypted  data packet (Fig. 1). Since the LDL forwards are followed by ACKs from the receiver station, although they are faintly visible, the nine retransmissions could be due to repeat requests.

Fig. 1

The analysis of the last 64 bits of each BW3 bursts shows a fixed structure in the Sequence Number field: if the reps had been in the datagram passed to the LDL protocol then the sequence number would have been incremented, moreover the EOM and SOM fileds (bits 16,15) are both to 1 in all the packets meaning that this is the only packet in the sent datagram  (Fig. 2)

Fig. 2

As said, since the ARQ ACK mechanism of xDL protocols, it could be that the nine retransmissions are requested by the receiver (bad channel conditions at receiver side?) but it could also be a technique to improve the reliability of the transmission: transmitting the same information more than once (each time encoded using alternate FEC codes) during a particular link increase the probability that user data will be received correctly.

https://yadi.sk/d/_SCU3U073GzPf9

a possible EMCON retransmission mode for Multicast Data Link protocol ?

This is an MDL-N (Multicast Data Link with NACKs) transfer received on 10958.0 KHz/USB. The transfer begins with an FLSU Point-to-MultiPoint call (BW5) followed by four forward transmissions consisting of LDL288 DATA PDUs (BW3); the ending BW4 burst is the LDL EOM PDU informing the receiving stations that the entire datagram has been transmitted. In MDL-N each forward transmission is followed by a pause, during which receivers that were not able to decode that transmission emit a very robust pseudonoise PSK symbol sequence to request retransmission: in this sample there is no NACK PDUs issued by the receiver stations.

At a first glance, one could say that the incoming datagram at the sender has been splitted in four LDL 288-byte data packets (unless the padding bytes in the last packet) which are then forwarded using four BW3 bursts ...but things are not properly in this way.
Indeed, looking at Figures 1-2,  it's easy to notice that packets #1 and #2 are exactly the same, as well as the packets #3 and #4 (275 bytes length). 

Fig. 1 - packets #1, #2

Fig. 2 - packets #3, #4

This means that each packet is sent twice before to clear the TxFrame buffer, so that the receiver stations have two copy of the same message, each obtained by adding the packets #1, #3 and the packets #2, #4 (Fig. 4)

Fig. 4 - the received entire datagram

(note that the encryption is applied before the datagram is segmented).

According to these observations, I try to give an explanation that makes sense to that scenario.
For a reliable transmission of the message, each packet is always sent twice (at leats in this sample): a station that decodes the entire error-free message can deliver the message and discard the copy. Otherwise it must process the copies and attempt to correctly decode the message. Summarizing: each packet is transmitted n-times instead of n-retransmissions of the complete message.  This mechanism could contrast with the chance of use ACK/NACK PDUs, but - other than adds redundancy - it could be also a good solution in case of receiver stations which must remain in EMCON mode (radio silence) for extended periods and consequently can't send NACKs neither delayed acknowledgements.  
The same behavior has been observed also in some LDLn transfers, but here the retransmissions could be requested by the receiver station.
Most likely, to increase the reliability a sort of 'retransmission counter', or a 'configurable setting', indicates the number of times each packet shall be retransmitted (repeated) or not during a particular link , according to the established xDL PDU for that transmission and the conditions of the channel, no matter if the packets have been ACKed or not, to increase the probability that user data will be received correctly.

As pointed out, this is a my thought, a supposition based on what I see: I do not know if it's  just a coincidence or a sort of implementation of STANAG-4538 since I have not found confirmations in the documentation that is publicy available in the web. Further recordings are needed in order to better understand this kind of scenario. By the way, your comments are welcome.

 https://yadi.sk/d/J8mreWoP3Go2ip