As said in the previous post, in all the monitored transmissions the chosen 3G-HF service is the Circuit Mode, and 1200bps 188-110A Serial is the used HF 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 use of 3G-HF means that the stations partecipating the netwok synchronously scan the assigned pool of frequencies; moreover, transmissions are not scheduled and looks like they happen just when in need.
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.
The use of 3G-HF means that the stations partecipating the netwok synchronously scan the assigned pool of frequencies; moreover, transmissions are not scheduled and looks like they happen just when in need.
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, a "wrapper" protocol
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 |
Let's have a look at ASCII rapresentations of a series of decoded transmissions (Fig. 2):
 | |
| Fig.2 |
Data are structured as a series of headers having the format {<length>,<content>}:
{5,HWK01}{3,PFY}{3,001}{3,001}{10,1570853327}{0}{143,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2096500086}{0}{625,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2097463403}{0}{937,...}{0}
...
...
A possible explanation could be:
{5,HWK01}{3,PFY}
source and destination IDs
{3,001}
number of the current data-block
{3,001}
total number of data-blocks
{10,1570853327}
most likely a timestamp
{0}
unknown. So far, never seen something different at this position, probably marks the start of a data block (SOF).
{143,data-block}
size length in bytes of the block, data.
{0}
unknown. So far, never seen something different at this position, probably marks the end of a data block (EOF).
{5,HWK01}{3,PFY}{3,001}{3,001}{10,1570853327}{0}{143,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2096500086}{0}{625,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2097463403}{0}{937,...}{0}
...
...
A possible explanation could be:
{5,HWK01}{3,PFY}
source and destination IDs
{3,001}
number of the current data-block
{3,001}
total number of data-blocks
{10,1570853327}
most likely a timestamp
{0}
unknown. So far, never seen something different at this position, probably marks the start of a data block (SOF).
{143,data-block}
size length in bytes of the block, data.
{0}
unknown. 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 a original/received file, computes their lengths and arrange them in the form {<length>,<content>} for its subsequent forward.
1.1 Source/Destination IDs
The attribute "length" is not fixed but depends on the length of ID. In the large majority of the cases traffic is originated from 006.046.000.zzz nodes (IDs: HWK01,ZMK002) and directed to 006.046.001.zzz 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 (006.046.001.006) to NZH21 (006.046.001.052).
It's interesting to note that in some transmissions the same ID "HWK01" appear in both the src and dest blocks (Fig. 3) but with different S-5066 addresses (anyway belonging to the same block 006.046.000.zzz): 006.046.000.102 and 006.046.000.028. 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.
It's interesting to note that in some transmissions the same ID "HWK01" appear in both the src and dest blocks (Fig. 3) but with different S-5066 addresses (anyway belonging to the same block 006.046.000.zzz): 006.046.000.102 and 006.046.000.028. 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.3 |
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:
http://saabgroup.com/Media/news-press/news/2015-11/saab-provides-service-life-extension-for-rbs-97-air-defence-system/
http://saabgroup.com/Media/news-press/news/2015-11/saab-provides-service-life-extension-for-rbs-97-air-defence-system/
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. 4).
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. 4).
 |
| Fig.4 |
1.3 Data Block, the "Z-strings"
As shown in Figure 5, 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.5 |
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. 6
 |
| Fig.6 |
Each data block exhibits a fixed 33-byte sequence that precedes a particular string that consists of the letter "Z" followed by four letters, all in uppercase format: we term these strings as "Z-strings". Adding the received UDOP/RDOP data blocks to form a single file, it's possible to point out the 33-byte sequences and the Z-strings: most likely they form the preamble of the data-blocks (Fig. 7).
 |
| Fig. 7 |
A complete discussion about the "Z-strings" can be read in the post related to the "8-bit text transmissions" from Swedish Army:
https://i56578-swl.blogspot.it/2017/11/swedish-army-8-bit-text-acp-127.html
As shown in Figure 8 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).
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 (prob. the complete call for BYN)
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 (probably the complete call for NZH)
VJL 006.046.001.054
https://i56578-swl.blogspot.it/2017/11/swedish-army-8-bit-text-acp-127.html
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 8 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.8 |
As shown in Fig. 9, 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 |
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:
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 lenghta of the Source/Destination IDs and the timestamp current format (from 7 to 10 bytes):
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 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 that the C_PDU is segmented into 200-byte 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.
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 that the C_PDU is segmented into 200-byte 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.
 |
| Fig.10 |
The used C_PDU-Segment size (200 bytes) is the one indicated 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).
STANAG-5066 Addresses heard so far:
[006.046.000.zzz] block |
| Fig.11 |
4. Networks, IDs
For what concerns the HF network, they have tens(!) of available frequencies, each may be used with RCOP or UDOP protocol.STANAG-5066 Addresses heard so far:
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 (prob. the complete call for BYN)
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 (probably the complete call for NZH)
VJL 006.046.001.054
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 |
No comments:
Post a Comment