11 October 2017

unid STANAG-5066 RCOP/UDOP client, Swedish Army "C2" integrator? (tentative)

last update: 11 October 2017

As said in the previous post, in all the monitored transmissions the chosen 3G-HF service is the Circuit Mode, and 1200 bps MIL 188-110A is the used traffic waveform. Data are transferred by STANAG-5066 D_PDUs and both the RCOP (Reliable Connection Oriented Protocol) and UDOP (Unreliable Datagram Oriented Protocol) are used as basic end-to-end transport protocols. 
The analysis of the S-5066 PDUs help to identify the user of the system: indeed, all the S-5066 Addresses belong to the 006.046.yyy.zzz block which is allocate to Sweden, most likely the user is the Swedish Armed Forces (Swedish: Försvarsmakten). So far the client protocol has not been identified.
Me and S4538 (the nickname of a friend of mine) analyze these transmissions since several moths and this post show the results of the investigations: some aspects are confirmed while some other are tentatives.

1. Protocol Units

Figure 1 shows two bitstreams after MS-110A removal and after synced on 0xEB90 (S-5066 D_PDU synchronisation sequence): in this cases all the D_PDUs are of type 7 (non-ARQ delivery) and 0 (Simplex data transfer) and carry UDOP and RCOP protocol.

Fig. 1
It's interesting to note in Fig. 2 the initial same structures which are present in all the recordered copies, in both RCOP and UDOP cases, after the removal of the DTS overhead (D_PDU encapsulations):
Fig. 2
 Let's have a look at ASCII rapresentations of a series of decoded transmissions (Fig. 3):

Fig. 3
Data are structured as a series of headers having the format {<length>,<content>}:


A possible explanation could be:

source and destination IDs

number of the current data-block 

total number of data-blocks

most likely a timestamp

unknown. So far, never seen something different at this position, probably marks the start of a data block (SOF).

number of bytes followed by data.

So far, never seen something different at this position, probably marks the end of a data block (EOF).

The particular format of the headers {<length>,<content>}, the iteration of the transmissions and their duration, lead to think to a wrapper protocol: it simply catches the requested values from the original file, computes their lengths and arrange them in the form {<length>,<content>}.

1.1 Source/Destination IDs

The attribute "length" is not fixed but depends on the length of ID. 
In the vast majority of the cases traffic is originated from 006.046.000.zzz block nodes (IDs: HWK01,ZMK002) and directed to 006.046.001.zzz block nodes. Very few traffic in the reverse direction. Maybe the 006.046.000.zzz block is assigned to a command/regional subnet. So far, only one transmission between 006.046.001.zzz block nodes has been copyied, namely from BYN21 ( to NZH21 (
It's interesting to note that in some transmissions the same ID "HWK01" appear in both the
src and dest blocks (Fig. 1) but with different S-5066 addresses (anyway belonging to the same block 006.046.000.zzz): and Perhaps there are two possible reasons:
a) the ID HWK01 acts like a sort of global-ID with different users/services, each with a distinct S-5066 Address;
b) these physical instances. Indeed, as shown in [2], they have separated Rx and Tx stations. Maybe this is a information transfer from one Tx to its corresponding Rx station which logically share the same ID.

Fig. 1
For what concerns the identifications, I could find a possible clue about "HWK01". Sweden Air Defense Regiment has two air defence battalions equipped with Robotsystem 70 (RBS 70) and Robotsystem 97 (RBS 97): 
Recently, defence and security company SAAB has signed a contract with the Swedish Defence Materiel Administration (FMV) for a service life extension of the RBS 97 air defence missile system, this order ensures the continuing effectiveness of a missile system that is the backbone of Sweden's two air defence battalions:
The RBS 97 is a surface-to-air missile system that is better known as "HAWK", then  it could be that HWK01 = HAWK 01 = Air Defence Battalion 1.

1.2 Timestamp

For what concerns the timestamp header, it seems related to the timestamp of the "wrapped" file, perhaps when it has been received: I think it's a unmanned 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 and its length  varies from a 7 to 10 bytes. By examining consecutive transmissions, the granularity of the clock is 1 msec, a new Epoch Time starts when the timestamp reaches its maximun value (9999999999).
I copied some transmissions probably just few minutes after the start of a new epoch time and thus a timestamp with increasing length of 7, 8 and 9 bytes (Fig. 2).

Fig. 2

1.3 Data Block, the "magic string"

As shown in Figure 3, 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.

Fig. 3
It must be noted that the maximum lenght of the data-block changes according to the length of the Source/Destinations IDs and the length of the timestamp, as shown in Fig. 4

Fig. 4
Each data block exhibits a fixed 33-byte pattern that precedes a string that consists of the letter "Z" followed by four letters, all in uppercase format: we term this string as the "magic string". Adding the received UDOP/RDOP data blocks to form a single file, it's possible to point out the repeated 33-byte pattern which precedes the magic string, probably  a  common heading to all the messages (Fig. 5). 

Fig. 5

2. Application Identifier "0x8008"

In order to identify the application that is responsible for the wrapper protocol we have to look at a generic D_PDU which transports the protocol data (the S-5066 D_PDUs are visible once removed the 188-110A overhead and synched the bitstream on the sequence 0xEB90).
As shown in Figure 6 the Application Identifier related to the wrapper protocol is "0x8008", that just belongs to the values which are available for user-defined applications (S-5066 Annex F, table F5).

Fig. 6

Probably the wrapper acts as a "bridge" to passing data between T-MMH systems (eg X.400 and ACP127 networks, although STANAG-4006 performs that task) or between C2 systems.

Fig. 7
By the way, quoting from [1] "The Swedish Army uses C2 systems that are not interoperable and data must be manually transferred between them. Sweden began to integrate all the service's C2 systems, at all levels, in 2005 under the name SWECCIS. [...] Swedish Armed Forces HQ tasked FOA, FMV and FHS to propose a vision for a mobile military joint C2 system for 2010, this project has been expanded to include civilian C2 elements [...] the goal is a single C2 environment...".
Other possible clues came from the HF2000 presentation slides at HFIA Meeting [2].

Fig. 8
As shown in Fig. 6, the Application Data, ie the data coming from the S-5066 client application,  begin just after the Application Identifier field of the UDOP/RCOP U_PDU. 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 for the wrapper protocol PDU (Fig. 9)

Fig. 9


3. Protocol MTU

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

4 + 56 + 1975 + 4 = 2039 bytes

4 + 54 + 1977 + 4 = 2039 bytes

As for above, the maximum lenght of the data-block must vary according to the lenghta of the Source/Destination IDs and the timestamp current format (from 7 to 10 bytes):
*10-byte timestamp {10,nnnnnnnnnn} (15-byte length)
1975 bytes (Dest ID = 5 bytes)
1977 bytes (Dest ID = 3 bytes)

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

and so on for 8 and 9 bytes timestamp formats.

It's interesting to note in Fig.10 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.10 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. 10
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. 11).

Fig. 11

4. Networks, IDs and Magic Strings

For what concerns the HF network, they have tens(!) of channels, each may be used with RCOP or UDOP protocol.
STANAG-5066 Addresses and "Magic Strings" heard so far:

[006.046.000.zzz] block

[006.046.001.zzz] block
BYN21 (prob. the complete call for BYN)
HEH002     --"--
NZH21 (probably the complete call for NZH)


5. Retransmissions?

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. 12). This is quite easy to accomplish since they use S-4538 FLSU for link setup thus 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 in such cases).

Fig. 12

 (to be continued)


No comments:

Post a Comment