unid STANAG-5066 RCOP/UDOP client, Swedish Army (update-3,4)

wrapper protocol MTU and data-block length 
As shown in Figure 1, if the length of the data-block is longer than the max allowed value (1977 bytes in this case) it is segmented into smaller blocks. The timestamp header in the segmented block remains unchanged while the current data-block number and the data-block length are updated. The data-blocks are not filled if their length is smaller then the maximum allowed value. [1]

Fig. 1

Moreover, the maximum lenght of the data-block changes according to the length of the Source/Dest IDs, as shown in Fig. 2

Fig. 2

Now let's have a look at a D_PDU which transports the wrapper protocol. The S-5066 D_PDUs are visible once removed the 188-110A overhead and synched the bitstream on the sequence 0xEB90 (all D_PDUs, regardless of type, begin with the same 16-bit synchronisation sequence).
As shown in Fig. 3, the Application Data, ie the data coming from the S-5066 client application (our wrapper protocol), begin just after the Application Identifier field of the UDOP/RCOP U_PDU. It's worth noting that  the Apllication Identifier is "0x8008", that just belongs to the values which are available for user-defined applications (S-5066 Annex F, table F5).

Fig. 3

So far I found the same 4-byte sequence "00 00 00 01" for both RCOP and UDOP protocols and, in my opinion, it is a sort of identifier of the wrapper protocol PDU (Fig. 4)

Fig. 4

Given the initial 4-byte "identifier" and the lengths of all the headers, the Maximun Transmission Unit (MTU) of wrapper protocol is equal to 2039 bytes for both RCOP and UDOP protocols:

ID{5,HWK01}{5,HWK01}{3,001}{3,002}{10,2367731361}{0}{1975,......}{0}
4 + 56 + 1975 + 4 = 2039 bytes

ID{5,HWK01}{3,VJL}{3,001}{3,002}{10,2223461543}{0}{1977,......}{0}
4 + 54 + 1977 + 4 = 2039 bytes

As for above, the maximum lenght of the data-block must vary according to the lenght of the sender/destination IDs and the used timestamp format (9 or 10 digits):

*10-digit timestamp {10,2367731361} (15-byte length)
1975 bytes (Dest ID = 5 bytes)
1977 bytes (Dest ID = 3 bytes)

*9-digit timestamp {9,nnnnnnnnn} (13-byte length)
1977 bytes (Dest ID = 5 bytes)
1979 bytes (Dest ID = 3 bytes)

It's interesting to note in Fig.5 that in case of use of UDOP protocol each D_PDU is transmitted twice unless the last. This makes sense to improve the reliability, since the nature of UDOP protocol itself (a basic connection-less protocol) and the use of S-5066 non-ARQ service.
Also note in Fig.5 that the C_PDU is segmented into 200-byte size C_PDU segments (each segment will be encapsulated in one D_PDU !): as you see, the overhead bytes added by C, S and U sublayers are present only in the first segment (although it's repeated).

Fig. 5

Curiosly, the used C_PDU-Segment size (200 bytes) is the same than the one used in the segmentation examples depicted in STANAG-5066 C.4.2 Edition 3, in our case the max size of C_PDU is 2051 bytes (Fig. 6).

Fig. 6

Since the Maximum C_PDU-Segment size within a D_PDU is a configurable parameter, the choice of a 200-byte size and the "double send" of the UDOP D_PDUs are probably a STANAG-5066 configuration implemented to support the wrapper protocol client. 

data block

Adding the data blocks to form a single file show a repeated 33-byte length pattern which precedes the "magic string", probably  a  common heading to all the messages (Fig. 7). As well as for the "magic string", it's difficult to say the scope of these sequences: indeed, further analysis will focus on the data block trying to get some meaningful. Recordings, help and tips are welcome!

Fig.7

Some interesting observations from the recent catches.

1. I had the chance to copy a transmission on 5206.3 KHz followed by an identical one on 5059.4 KHz after few seconds (Fig. 8). This is quite easy to accomplish since they use S-4538 FLSU for link setup, so the stations of the network are synched and scan the same pool of frequencies at same times. Repetitions increase the reliability of the system but do not know if it was just a planned episode or a routine scenario (more powerful monitoring tools would help...)

Fig.8

2. Usually transmissions are originated from nodes belonging to 006.046.000.zzz block (mostly HWK01) and directed to nodes of the 006.046.001.zzz block. This time I copied a trasmission inside the 006.046.001.zzz block (never copied so far), namely from BYN21 (006.046.001.006) to NZH21 (006.046.001.052).
As above: episode or a normal way to operate?

Fig.9

3. Luckily I copied some transmissions probably just few minutes after the start of a new epoch time of the timestamp clock and thus with a timestamp exhibiting a length of 7, 8 and then 9 bytes (Fig. 10). This is a full automated system working in a FIFO logic, ie the messages are wrapped and forwarded in the same order they arrive  (first came first served).  As well as for the IDs, the wrapper does not use a fixed length for the timestamp: it simply catches the value, computes its length and arrange them in the form {<length>,<content>}. This clarifies why so far I found transmissions with 9 and 10 bytes lengths.
As already debated, the variable lengths of IDs and timestamp affect the length of the data block since it shall be computed to fit the max transmission unit of the protocol (2039 bytes). 

Fig.10

STANAG-5066 Addresses and "Magic Strings"
heard so far:

[006.046.000.zzz] block
HWK01   006.046.000.028, 006.046.000.102
ZMK002  006.046.000.037
OYO01   006.046.000.101 *

[006.046.001.zzz] block
FRJ    006.046.001.001 *
BYN21  006.046.001.006 *
DWY    006.046.001.009
PFY    006.046.001.010
ZHO    006.046.001.028
RJY    006.046.001.029
GZL    006.046.001.030
HEH    006.046.001.034
HEH002     --"--
CAU    006.046.001.046
NZH21  006.046.001.052 *
VJL    006.046.001.054

ZAPCA
ZAPCG
ZAPCK
ZAPCH *
ZNTCH *
ZRTBC
ZRTBD
ZXPBC
ZXPBD
ZXPBG
ZXPCK
ZXPDA *
ZXPDK *

* new ones