Swedish STANAG-5066 client-application, a look at the DTS sublayer

(Just an update about the "Swedish Defence client-application for STANAG-5066" topic)
As said in the previous posts, the users employ the 3G-HF "Circuit Mode" service (STANAG-4538), data are transferred in non-ARQ mode using the STANAG-5066 stack and basic end-to-end transport protocols (UDOP/RCOP). Since the use of 3G-HF, the stations partecipating the netwok synchronously scan the assigned pool of frequencies and transmissions just happen when in need. 
I came across on a transmission, on 4742.0 KHz/USB, that exhibits two features never seen before in the previous transmissions (at least in my case):
● the used HF waveform is STANAG-4539 3200bps (usually they employ 188-110 1200bps along with S-5066 or alone in 8-bit text mode);
● the multiple occurrences of the ASCII string "WVKA" inside a message, which implies a look at the role of the Data Transfer Sublayer (DTS) of STANAG-5066.

Fig. 1 - Multiple occurrences of the string "WVKA", here in block 2 out-of 20

It's noteworthy that, actually, the occurrences are about the half since data are repeated!

Just a reminder for background: in case of a source message that is larger than the MTU (Maximum Transmission Unit) of the S-5066 subnetwork interface (usually <=2048 bytes), the client-application segments the message into n-blocks (A_PDUs) before its submission. The blocks are then encapsulated into the final C_PDUs, which in turn are segmented by the Data Transfer Sublayer (DTS) into smaller 200-byte D_PDUs (PDU stands for Protocol Data Unit).

Fig. 2 - progressive encapsulations and segmentation in S-5066 stack

It's possible to verify that in some circumstances - probably when UDOP protocol is used - segmenting a C_PDU results in duplicate D_PDUs (!), except the first and the last D_PDUs (read below). As clearly shown in Figure 3, the analyzed transmission just matches that case.

Fig. 3 - The duplicated D_PDUs in the block 2 out-of 20 (the same block of Figure 2)

This behavior is easily seen in many transmissions, whether they use S-4539 or 188-110A waveforms: note in Figure 4 that the first D_PDU is repeated only in the first C_PDU, while the last D_PDU is never repeated.

Fig. 4

Where do the duplicate D_PDUs come from? Inspecting the headers in Figure 5, it's possible to note that the "C_PDU Segment Offset" field contains the same value in the pairs of the duplicate D_PDUs. Given that the Segment Offset indicates the location of the first byte of the segment with respect to the start of the C_PDU, it means that the C_PDU (and thus the upper sublayers) does not contain duplicate data, otherwise the Segment Offset fields in the pairs of the duplicate D_PDUs would have contained different values! Thus, in my opinion, the duplicate D_PDUs are originated by the DTS sublayer. Notice that what we see in Figure 5 are the on-air bytes, thus after they have leaved the DTS (see the S-5066 stack in Figure 2).

Fig. 5 - headers of the D_PDUs (each row is a D_PDU, see Figure 2)

Segment Offset fields contains a 200 bytes step values, as expected:
0x0000 =    0
0x00C8 =  200
0x0190 =  400
0x0258 =  600
0x0320 =  800
0x03E8 = 1000
...

The receive node will re-assembly a C_PDU from its segments (the D_PDUs) after they have passed the CRC error-check and have no detectable errors: probably the redundancy is used in this regard. I did not find any reference in the S-5066 standard, at least the one at my disposal, and I tend to exclude possible errors of the S-4539 (or 188-110A) decoder since the same results were obtained using different decoders and different HF waveforms: so, at least in my opinion, the repetition of the D_PDUs could be a custom modification of the code of DTS  (switchable to maintain NATO compatibility) or a new feature added to a recent edition of S-5066. Definitely, even if the latency increases (such transmission mode takes about twice as much time, although they have moved on the 3200 bps of S-4539) the add of redundancy improves the general reliability of the system since S-5066 is used in non-ARQ mode.

As for the string "WVKA", only guesswork can be made: further recordings are in need. For now, I'm going to code a S-5066 dissector to facilitate the reading of the headers...

https://yadi.sk/d/9vqs2DfTOKN1sg
https://yadi.sk/d/s7oyiYaTt406vw