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