housing of data packets in a HDLn Tx Frame

This recording is nothing special but rather a good example in order to study and verify the way the data packets are housed in an HDLn Tx frame and the mechanisms used to fill the unused room when the length of the outgoing datagram is less than the length of the Tx frame of the used HDLn version (n = 3,6,12,24 packets each of 233 bytes). Particularly, the recording concerns a 1889-byte lenght 'Citadel' encrypted datagram which is sent in one HDL12 PDU, ie using 233 x 12 = 2796 bytes: the protocol shall use the extra space of 907 bytes adding 0-value bytes and reinserting one or more data packets (Fig. 1).

Fig. 1

For what concerns the on-air signal (Fig. 2), the HDL12 PDU is trasmitted within a BW2 waveform across an already-established HF link (FLSU/BW5) and is folowed by three EOM PDUs (BW1) sent by the transmitter station meaning that entire datagram has been successfully delivered. The HDL12 PDU is acknownledged by an ACK PDU (BW1) transmitted by the receiver station. The logical link will be terminated by a couple of FLSU exchanged  between the two stations. The transmission was copied on 8327.0 KHz/USB.

Fig. 2

For a better understanding of the way HDL protocol arranges the extra 917 bytes, let's see how the HDL PDU and BW2 are formed (quoting Annex C to NATO STANAG-4538).

For each of the first data packet positions in HDL TxFrame buffer (12 positions in this case), if the data packet position is empty, construct a new outgoing data packet in this position:

1. Get the next data segment (the next 233 consecutive data bytes to be transmitted) from
TxDatagram buffer; place these in the payload field of the data packet. If fewer than 233 data bytes remain to be transmitted, place these bytes at the beginning of the payload field; fill the remainder of the field with zero bytes.

2. Construct a sequence number value and write this value into the packet’s Sequence Number field.

 3. If TxDatagram buffer is completely emptied of payload data before all packet positions in TxFrame buffer have been filled with new packets, fill the remaining packet positions with repetitions of packets already residing in other positions of TxFrame buffer. The HDL transmitter is at liberty to select packets from the current datagram to repeat as it pleases; the HDL receiver must inspect the sequence number of each packet received without errors, and use this information to discard duplicate packets. 

4. Send an HDL PDU containing the tx frame in TxFrame buffer, using BW2 waveform.

Fig. 3 - formation of the HDL12 Tx fame for this example

The 0-value bytes and the packet repetions are well visible in Fig. 1.

During the construction of BW2 waveform structure, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the 1881 payload data bits in each data packet (1864 bits of user data, plus a 17-bit Sequence Number added by the protocol), and is then appended to the data packet. The seven encoder flush bits with values of zero (Flush) are then appended to produce an Extended Data packet of 1920 bit length that will be used for FEC, frame formation, symbol formation, and so on. 

From theory to practice, the way the data packets are housed in TxFrame buffer can be verified by inspecting the  Sequence Number fields in the last 56 bits of the first nine BW2 extended data packets of the copied transmission (Fig. 4).

Fig. 4 - the last 56 bits (Sequence Number + CRC + Flush) of the copied BW2 Extended Packets

As expected, EOM and SOM fields (bits 16,15) show that the positions 0 and 9 of the TxFrame buffer are both filled with the first packet of the datagram, while position 8 of the TxFrame buffer is filled with the last packet of the datagram. Consequently, the Packet Number (bits 5-0) starts from 0 to 8: ie, the useful payload consists of 9 packets (note also that positions 0 and 9 have the same Packet Number).
Consider now the Packet Byte Count (bits 14-6): this field show the number of user bytes in packet –1. The first eight packets, positions 0-7, contain 233 bytes (011101000 = 232) and the last packet, in position 8, contains 35 bytes (000100010 = 34). The outgoing datagram was then (8 x 233) + 35 = 1899 bytes length.

One could say "since the datagram length is 1899 bytes and fills 9 data packets, why don't use 1 HDL6 PDU + 1 HDL3 PDU?". It would be impossible.
During the link setup phase, the session manager process determines the number of data packets per HDL PDU (3, 6, 12, or 24) shortening the HDL PDU whenever the entire datagram is short enough to fit within the shortened PDU. Once it is determined, the number of data packets per HDL PDU for the current datagram delivery remains unchanged, ie every HDL PDU contains the same number of data packets until the entire datagram has been delivered (so: 3 x HDL3 PDUs, or 2 x HDL6 PDUs, or just 1 HDL12 PDU... btw more PDUs means the more turnaround time).

https://yadi.sk/d/wcvQBJfr3H75uc
https://yadi.sk/i/j0nqeWiC3H75x9