a STANAG-5066 (off-line) dissector

 

S5066 dissector (free software licensed under the GNU General Public License - GPL) is a GNU Octave coded tool that accepts as input a filename.txt file containing a stream of ASCII 0's and 1's (no space between) and, accordingly the input arguments, prints out:
a. filename_out file containing the decoded headers of the STANAG-5066 stack (DTS, CAS, SIS)
b. filename_addr file containing the changes of the traffic flow direction  (change of the source and destination node address)
c. filename_<n> files containing the user-data in ASCII-bits or ASCII-chars format
The output of the decoded headers is also shown on the Octave Command Window (the Command Window anyway does not allow you to browse the whole output).
The STANAG-5066 stack is scanned bottom up (starting from DTS layer)  as if the bistream were being parsed by a receiving node; since the dissector goes back up to the user data, it also shows some informations about the User-to-User Protocol as well as the Client Application type (BFTP, TTHMS, FRAP,...) and the basic transport protocol (RCOP/UDOP).
The input ASCII file being analyzed may be produced by a modem or a decoder (such as sorcerer, k500,...) which have the task of removing the HF waveform overhead (110A, S-4285, S_4539, ...), therefore this dissector is an "off-line" tool: a real-time version needs much more work (and code) other than a pc with the synchronous interface (users' standard pc are equipped with async interfaces).
The dissector is primarily thinked to work on (decoded) on-air symbols, hence its goodness will depend either on the quality of the signal and the precision of the modem/decoder. This is a beta and anyway STANAG-5066 Edition 3 compliant version: bug-fix (and maybe Edition 4 compliant) releases will follow.

Requirements:
1) GNU Octave >= 6.1 (see this post for Octave installation)
2) the input file should contain only '0's and '1's, ie no spaces or some other separator char between the values; preferably without LF/CR: in that case the software will reshape the contents and warn the user with the message "reshaping file, wait..."

Usage:
S5066(fn,i,f,cout,t)
  fn = filename containing a stream of ASCII 0's and 1's
 i,f = range of frames to be processed (i=0 first, f=0 last)
       0,n [1 - n]
       n,0 [n - last]
       n,m [n - m]
       n,n [only n-th frame]
cout = 0 do not extract user data (do not reassembly C_PDUs)
     = 1 extracts the user data in ASCII-bits format (0's and 1's)
     = 2 extracts the user data in ASCII-char format
   t = 1 tracks the changes of the flow direction (0 = no action)

Usage examples (notice that at each run the previous output files are overwritten):
S5066 ("test.txt",0,0,0,0)
process all the frames of the file and prints out the file:
- test_out.txt

S5066 ("test.txt",0,0,2,1)
process all the frames of the file and prints out the files
-  test_out.txt
-  test_addr.txt
- test_<n>.txt files containing the user data (as many files as the reassembled C_PDUs); since the parameter cout has the value 2, the user data files are in ASCII-char format (Extended ASCII code is used, a proper editor is recommended) 

A short report is printed at the end of the headers file along with the "elapsed time"; by the way, the time taken depends on several elements:
- the need to reshape the input file
- if user data extraction is required and its format (bit/char)
- the number of frames to be processed (length of the input file)
- type of data transfer
and - obviously - on the performances of your pc. Below an example of two reports the same input file (s23.txt, 1Mb length) with and w/out reshaping:

Installation
Download S-5066.ZIP and expand it in your Octave directory, usually c/users/<your_name>/octave. Will be created the S-5066 directory containing the files "README.txt" and "test.txt" along with the subdirectory /m which contains the Octave scripts.

Change the working directory to .../octave/S-5066 and run the command addpath ("./m") so that Octave will know where to look for .m files: as usual, the /m subdirectory 

then you can run and try S5066 using the input arguments that you prefer. The test.txt file contains a STANAG-5066 bitstream relating to a real on-air transmission: ie it does not have  a "perfect" protocol layout as if it were captured at the output of a STANAG-5066 server. I also want to remember that S5066 is a passive dissector only and does not simulate a receive node (it does not implement timings, receive windows, and other stuff).
Below some commented examples of output files (headers files): their study may offer some useful insigths to understand how STANAG-5066 works. 

Figure 1 is related to the simple ARQ service (type 0 D_PDU), the frames from 141 to 152 allow to follow the transfer of a segmented C_PDU.

 

Figure 1

A) The C_PDU START flag of the frame #142 is set to indicate the start of a newly segmented C_PDU; the C_PDU segment contained within this D_PDU is the first segment of the C_PDU; the C_PDU END flag is clear. In frame #152 the C_PDU START is clear and the C_PDU END flag is set to indicate the end of a segmented C_PDU.

 

B) The first segment is conveyed by the D_PDU with sequence number #22, the last segment by the D_PDU with sequence number #32, ie eleven D_PDUs. As expected from the encapsulation (each sublayer adds its header), only the D_PDU with the initial C_PDU segment (sequence number #22) is followed by the other sublayer headers (CAS, SIS, and user protocol) while the following D_PDUs contain only a C_PDU segment.

C) The EOT (End Of Transmission) field provides an approximation of the time remaining in the current transmission interval from the beginning of the current D_PDU. More precisely, the number in this field is a binary number expressing the number of half (1/2) second intervals, thus the flow controll allows a maximum transmission interval of about 2 minutes.

 

D) As you can see in the size of segmented C_PDU field, each segment has a size of 200 bytes, except the last segment which is 26 bytes length. The whole C_PDU is then composed of (200x10)+46 = 2046 bytes; adding the headers of the (11) D_PDUS needed to convey the segments we get a total of 2246 Bytes. Since that the needed transmission time is about 15 seconds (difference of the EOT fields), the transfer speed is 1200 bps.

If all D_PDUs between and including the C_PDU START and C_PDU END (frames from 142 to 152) are received completely error free the link layer will assemble the C_PDU segments and deliver the result to the higher sublayers.

 

C_PDU Re-assembly for ARQ Delivery Services

 

Figure 2 is related to the NON-ARQ service (type 7 D_PDU), the frames 1-6 allow to follow the transfer of a segmented C_PDU.

 

Figure 2

 

A) Instead of the start/end flags mechanism seen in ARQ service, the NON-ARQ service signals the start and the end of a segmented C_PDU by means of the C_PDU segment offset field and the (unsegmented) C_PDU size field; the D_PDU with the C_PDU segment offset = 0 indicates the first segment (ie the the start of a newly segmented C_PDU). The end of a segmented C_PDU is reached when the sum of the received segments sizes is equal to the C_PDU size field (ie 1078 in this example). Notice also that all D_PDUs containing segments from the same C_PDU have the same C_PDU ID number (in this case 2570).

B) The EOT field has obviously the same meaning seen in the ARQ service example (time remaining in the current transmission interval).

Each segment has a length of 200 bytes, except the last which is 78 bytes length. The whole C_PDU consists of 1078 bytes; adding the headers of the (6) D_PDUS needed to convey the segments we get a total of 1222 Bytes. Since that the needed transmission time is about 6 seconds (difference of the EOT fields), the transfer speed is 1600 bps.
The re-assembly process for Non-ARQ C_PDUs uses the C_PDU ID Number, Segment-Offset field, C_PDU-Segment-Size field, and C_PDU-Size field to determine when all segments of a C_PDU have been received.The segments that are reassembled are expected to have passed the CRC error-check and have no detectable errors.

 

C_PDU Re-assembly for NON-ARQ Delivery Services

Figure 3 is related to the tracking of the traffic flow direction, still in experimental version. That feature coud be useful in case of a recording of a ARQ-type session which comprises both data and ACKs sendings. At present, it simply records the changes of the SENDER/DESTINATION address along with the D_PDU type and frame number. 

 

Figure 3

Although the dissector does not care the user data, it also provides a raw(!) extraction and reassembly of the C_PDU segments.

 

 

Some features as the tracking of the traffic flow direction, controls/checks of inconsistencies and some other ones as the CRC check and C_PDUS segments reassembly, will be implemented in next releases.

Comments, suggestions and bugs reports are welcome!

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

(Just an update about the "Swedish Army 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 

XMPP over HF radio using STANAG-5066

(updated)

Interesting transmissions spotted on 4381.0 KHz and 4833.5 KHz (all usb) consisting of MIL 188-110A Serial HF waveform (fixed 600bps/S) and 6-bit code clear text (6x28) & STANAG-5066 as bearer for XMPP Multi-User Chat (MUC)  messages.

XMPP, the Internet Standard eXtensible Messaging and Presence Protocol, is the open standard for Instant Messaging (IM), Group Chat and Presence services. XMPP is widely used for military deployments, where operation over constrained and degraded networks is often essential, particularly for tactical operation. 

Multi-User Chat (MUC) is a central service for military communication. If data is being provided, it makes sense to share it so that all interested parties can see it. For example, it will enable external strategists or lawyers to observe communication in real time, and provide input as appropriate. It often makes sense to share information in the field, for example a group of ships jointly working out who will target what and how. MUC is an important operational capability. 

In XMPP a client connects locally to its server, and then there are direct server to server connections (S2S) to support communication with clients on other servers. The mapping of XEP-0361 (Zero Handshake Server to Server Protocol) onto STANAG-5066 is standardized in "XEP-0365: Server to Server communication over STANAG-5066 ARQ”. XEP-0365 is mapped onto the S5066 SIS and transferred using RCOP protocol.

The 6-bit text and S5066 bitstream (Fig. 1) is obtained after demodulating the 188-110A Serial waveform:

 

Fig. 1

S5066 peers have the addresses 010.050.066.001 and 010.050.066.003 (odd) in 4381.0 KHz channel; the addresses 010.050.066.002 and 010.050.066.004 (even) are used in the 4833.5 KHz channel. These are probably "exercise" addresses since the block 10.50 is allocated to Uganda. 

These transmissions have been monitored for about one day so I could collect hundreds of messages, only some of them are shown below as examples: you can see groupchat messages, Instant Messaging (private messages) and Presence/IQ messages. My friend and colleague Guido @decodesignals logged same transmissions (and same addresses) on 4613.0 Hz, in his catches the S4539 4800bps is used as the HF waveform.

<message
    from='latency.ground@ground.net/2aad61419fb06287'
    to='latency.p8-one@p8-one.net'>
    <body>
    (a3d5bb51-70c3-4152-9a29-ab7cddbb47a3; 20181207T224101.034169)
    Test Message H - Private Message From GROUND Latency Acct
    </body>
    <securitylabel xmlns="urn:xmpp:sec-label:0">
    <displaymarking bgcolor="green">UNCLASSIFIED</displaymarking>
    <label/></securitylabel>
</message>

<message
    from='mission-one@chat.ground.net/LATENCY_GROUND'
    to='mission-one@chat.p8-one.net'
    type='groupchat' id='fmucinte54838a0b2804718'>
    <fmuc xmlns='http://isode.com/protocol/fmuc'
    from='latency.ground@ground.net/8f9f7ba5ca23d374'
    sync_stamp='2018-12-07T22:44:52Z'/>
    <body>
    (29f06ec4-a4a9-4849-bd46-42c54efa42ea; 20181207T224452.309137)
    Test Message T - MUC From GROUND Latency Acct
    </body>
    <securitylabel xmlns="urn:xmpp:sec-label:0">
    <displaymarking bgcolor="green">UNCLASSIFIED</displaymarking>
    <label/>
    </securitylabel>
</message>

<iq
    from='mission-one@chat.ground.net/LATENCY_GROUND'
    to='mission-one@chat.p8-one.net/Supervisor Air'
    type='get' id='d98686c2-d66f-4bdc-9b4e-ceb9911c834e'>
    <query node='http://swift.im#3ScHZH4hKmksks0e7RG8B4cjaT8='
    xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<presence
    from='mission-one@chat.ground.net/LATENCY_GROUND'
    to='mission-one@chat.p8-one.net/LATENCY_GROUND'
    id='fmucint0e52f98befac3522'>
    <fmuc xmlns='http://isode.com/protocol/fmuc'
    from='latency.ground@ground.net/8f9f7ba5ca23d374'/>
    <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence
    from='mission-one@chat.p8-one.net/LATENCY_AIR'
    to='mission-one@chat.ground.net/LATENCY_AIR'
    id='fmucint0572337e8aafbad5'>
    <fmuc xmlns='http://isode.com/protocol/fmuc'
    from='latency.p8-one@p8-one.net/f5ac7b83c2cc6951'/>
    <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

A bit of intelligence gathering can be done by the reading of the messages and from TDoA.

Direction finding  is not easy since the transmissions originate from two different sites, however the results obtained indicate UK as the area of operations (Fig. 2): maybe UK MoD?

Fig. 2 - TDoA result

The namespace attribute fmuc xmlns='http://isode.com/protocol/fmuc can be a clue of the use of the M-Link software developed by Isode for XMPP [1]. By the way, reading some Isode documentation available in the web you can see odd 10.x.y.w S5066 addresses like the ones used in the heard transmissions (Fig. 3)

Fig. 3 - from XMPP5066EVAL.pdf by Isode

Servers names and nodes names as: mission-one@chat.ground.net/LATENCY_GROUND and mission-one@chat.ground.net/LATENCY_AIR, as well as the Test Message format suggest a test phase aimed to measure the latency of air and ground links. Note also that the tests are performed using different HF waveforms: MIL 188-110A Serial 600bps and STANAG-4539 4800bps.

That being said, probaby these are UK MoD test transmissions concerning (Isode) XMPP over HF radio but it's only my guess. Ropey @Topol_MSS27 suggests that "maybe P8 (chat.p8-one.net) is a clue and references new ops for upcoming P-8A's due to join RAF from Nov next year" [2].

12 December update
My friend Martin G8JNJ, owner of the http://southwest.ddns.net:8073/ KiwiSDR, reports he heard synch'ed transmissions on 4381.0 KHz and 5505.0 KHz too, all usb. His TDoA runs point to Inskip (Former RNAS Inskip), a transmitting site of UK DHFCS located in Lancashire, North England: it confirms my TDoA and is a further clue in favor of RAF operations.

https://yadi.sk/d/q152AVjeZIsiPA

https://yadi.sk/d/5w-_wB8SZJnIKg

[1] https://www.isode.com/whitepapers/low-bandwidth-xmpp.html 

(a lot of documentation is publicy available in the web about ISODE XMPP, google is your friend) 
[2] https://www.raf.mod.uk/aircraft/p-8a/ 

IP over HF via STANAG-5066 RCOP, MIL 188-110A as HF waveform

Interesting transmissions spotted on 9105.0 KHz/usb at 1240z, user/locations are unid, maybe form US-Mil stations? The transfer concerns IP-over-HF (IPoHF) via STANAG-5066 RCOP protocol [1]: 1380 bytes IP packets are exchanged in directions 192.168.2.48 -> 192.168.12.48 and 192.168.1.48 -> 192.168.14.48 , ESP (IPSec) secure protocol is used.  MIL-STD 188-110A Serial is used as the HF waveform. STANAG-5066 Addresses (001.003.003.103 001.001.001.101) belong to US-DoD. Similar transmissions was heard on 8th October on 13378.0 KHz/usb using 188-110A and S4539 QAM-64 as HF bearers (discussed here) maybe the user is the same.

The sequence of the figures illustrates the various steps that have been performed in the analysis of the signal.

Fig. 1 - 188-110A on-air symbols

Fig. 2 - STANAG-5066 bitstream after the removal of 188-110A overhead

Fig. 3 - hex-dump after the removal of STANAG-5066

The hex-dump file resulting after the removal of STANAG-5066 PDUs encapsulations has been processed using "wireshark" software: IPv4 addresses and headers as well as IPSec encapsulation are clearly visible.

Fig. 4 -

https://yadi.sk/d/wuBIWQ_HSwVRMA
https://yadi.sk/i/6p-izzJatalVwg
https://yadi.sk/i/ulK473q0E2rCNw

[1] https://www.isode.com/whitepapers/ip-over-stanag-5066.html

https://yadi.sk/i/6p-izzJatalVwg

STANAG-5066 Annex G, the ancestor to US MIL STD 188-110B and STANAG-4539

The other day I was still trying to figure out something from the S4539 8-ary burst transmissions, posted here, using Harris RF-5710A HF modem. Turning between the various operating modes provided I came across what at first glance seemed a strange waveform: i.e. 5066-G. As far as I know, STANAG-5066 is a protocol standard that does not define waveforms, so I went into detail to see what the hell it is.
STANAG-5066 Annex G presents guidelines and requirements for the use of the STANAG 5066 protocol profile with modems and waveforms at rates above 2400bps. Early draft versions of STANAG 5066 Annex G included a detailed specification for high-speed single-tone waveform and convolutional forward-error-correction coding with data rates up to 9600 bps, and this formed the basis for more than one vendor implementation of a commercial product.
Quoting Edition 3 #G.3.0 Implementation Guidance for STANAG 5066 Operation at Higher Rates : "It is clear that higher throughput will be available for the HF long-haul channel in near future (i.e, post 2000). What is not clear is the final form of the waveform standard or standards that will provide these data rates". Notice that the Edition 3 was promulgated on 30 march 2015 and the Annex G is still "information only", ie it is still not mandatory for the purposes of the communication minimum requirements.

Now look at the words "...in near future (i.e, post 2000)": clearly, Annex G has remained unchanged from the first editions of STANAG-5066 (dated before year 2000). Most likely the NATO groups responsible for the standardization preferred a separate STANAG to define the new waveforms since 5066 is a protocol standard, so Annex G is "frozen" and stands like a kind of ancestor to MIL 188-110B and STANAG-4539 (3200 to 12800 bps): these new waveforms used constellations and much of the waveform structure developed for Annex G and added further enhancements. 
Harris developed its implementation of 5066-G, you may find it among the operational modes of their RF-5710A HF modem:

The STANAG-5066 Annex G waveforms provide the highest possible data rates over conventional 3KHz HF channels. A single 1800 Hz sub-carrier is modulated at a constant rate of 2400 symbols per second. the type of modulation varies from QAM-64 to PSK-4 according to the data rate selected. Known data symbols are periodically inserted in the transmitted signal to allow fro adaptive channel equalization at the receiver. Convolutional coding FEC and Viterbi decoding are combine with interleaving to enhance the performance of the receive modem on fading HF channels. Data rates from 3200 bps to 9600 bps are supported together with long, double long, short, and zero interleaving options. An additional 12800 bps uncoded waveform is supported for line-of-sight applications. Automatic detection of the data rate and interleaver setting are provided in the receive mode.

By the way, I tried to demodulate the S4539 8-ary bursts using the 5066-G mode , despite obsolete. Surprisingly, the modem is responsive and distinguishes four different waveforms: 4800L (PSK-8), 8000L bps (QAM-32), 9600L and 12800 bps uncoded (QAM-64), the last two are detected less frequently (Fig. 1). It should be noted that when the same transmission is demodulated using 4539 or 110B you always get the same waveform 12800U.

Fig. 1

Annex G: Use of Waveforms at Data Rates Above 2400 bps (V1.2) 

S5066 data transfer, scaling from 3200bps (QPSK/PSK8 on-air) up to 9600bps (QAM64)

8th October update: using "Wireshark" software to detect IP packets (IP over HF)

13378.0 KHz/USB, 0848z: S5066 data transfer using HF waveforms 110A & S4539 which scale from 3200bps (QPSK/PSK-8 on air) up to 9600bps (QAM-64); unid user/location. Notice in Figure 1 that QAM-32 constellation use multiple PSK rings to maintain good peak-to-average ratios, and the QAM-64 constellation is a variation of the standard square QAM constellation, which has been modified to improve the peak-to-average ratio.

Fig. 1 . HF waveforms constellations

The typical 1776 bits structure of S5066 is obtained after the removal of the HF waveforms overhead, in Figure 2 the bitstream is synchronized on the sync sequence 0x90EB. 

Fig. 2 - STANAG-5066 bitstream synched on 0X90EB

Looking at the 16-byte headers of the Data Transfer Protocol Data Units (D_PDU), we see that #0 (Data only)  is the used D_PDU type: this type is used for simplex data transfer of segmented C_PDUs with a Selective Repeat-Request (SRQ) service protocol. The peers in the link have the S5066 addresses: 001.005.005.105 and 001.001.001.101.

0x90EB D_PDU sync sequence
04 D_PDU type
10 50 56 91 01 01 65 source & destination address

90 EB 04 F6 3C E9 10 50 56 91 01 01 65 48 BA 85 ...
90 EB 04 F6 3B E9 10 50 56 91 01 01 65 08 C8 87 ...
90 EB 04 F6 3A E9 10 50 56 91 01 01 65 08 C8 88 ...
90 EB 04 F6 39 E9 10 50 56 91 01 01 65 08 C8 89 ...
90 EB 04 F6 39 E9 10 50 56 91 01 01 65 08 C8 8A ...
90 EB 04 F6 38 E9 10 50 56 91 01 01 65 08 C8 8B ...
90 EB 04 F6 37 E9 10 50 56 91 01 01 65 48 BA 8C ...
90 EB 04 F6 36 E9 10 50 56 91 01 01 65 08 C8 8E ...
90 EB 04 F6 35 E9 10 50 56 91 01 01 65 08 C8 8F ...
90 EB 04 F6 34 E9 10 50 56 91 01 01 65 08 C8 90 ...

The  D_PDUs payloads originate a group of files which have the same 38 bytes length initial structure consisting of a 33-byte pattern followed by a progressive 0xnn number and four 0x00 bytes:

00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 18 00 00 00 00 4F ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 19 00 00 00 00 5A ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 1A 00 00 00 00 CC ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 1B 00 00 00 00 53  ...
 
In my opinion the first six bytes are the headers of C (Channel Access Sublayer) and S (Subnetwork Interface Sublayer) Protocol Data Units: 

00 07 99 42 EF 44

00 C_PDU type (0 = data) 
07 S_PDU type (0 = data)
99 S_PDU source & destination SAP IDs (1001 & 1001)
42 EF 44 S_PDU control and TDD fields

and the remaining 32 bytes, from 0x45 to 0x4F, could be the headers of the User Protocol data Units (U_PDUs) incoming from the client/application upper layer (Figure 3). Since the presence of a progressive number (0x18, 0x19,0x1A,...) it could be that the client message has been segmented into smaller U_PDUs before the subnet interface, but it's only a my guess.

Fig.3 - sublayers within STANAG-5066

SAP_ID stands for Service Access Point Identifier, it's a number in the range 0-15 and is equivalent to the “port” of the TCP protocol. In this case - according to S5066, the used Service Access Point should be the IP port (1001).

My friend and colleague j. sent me an email with his comments about this signal "I also analysed the last S5066 signal you posted on your page. It finally contains IP data packets (local addresses are 192.168.1.48 ->192.168.14.48) in the direction 1.1.1.101 -> 1.5.5.105. The used protocol is ESP (IPSec). The other direction confirms the data using RCOP"
Well, it's possible to prepare an hex dump file by removing the  C & S headers (0x 00 07 99 42 EF 44) :

00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 18 00 00 00 00 4F ...

and then process the obtained file using "wireshark" software. The results show the IP packet originally submitted to S5066 and thus to the HF network, i.e. IP over HF [1]

[1] https://www.isode.com/.../ip-over-stanag-5066.html
https://yadi.sk/d/ZFTNRhiPkoT1HQ
 

Maritime Interdiction Operations (MIOs) in Med'sea, a joint exercise?

The heard communications concern a Maritime Interdiction Operation (MIO) in Mediterranean sea and involve 2 vessels and one ashore station which acts as the net-control station by coordinating all the activities. It is not clear if  the heard activity is part of a routine patrol or rather a naval joint exercise. The ALE IDs used in communications (ie "CMOC", that could stands for Combined Maritime Operation Center), some terms in the messages (such as PUBEX, EVOLEX) and the "special" email domain name (here not reported for confidentiality) make me think to a MIO joint exercise. By the way, I did not find any related news in some specialized websites neither in press-agency sites.
The activity was heard on 7 and 8 MHz bands, expecially on 27 October. Communications  make use of 188-141 2G ALE for link setup while the messages are sent using a battle force email system based on STANAG-5066 HBFTP protocol. STANAG-4539/MS-110A are used as bearer HF waveforms, mostly QAM-64 9600bps and PSK-8 1200bps modulations (Figs 1,2). The STANAG-5066 addresses of the network nodes belong to the dummy block 10.000.000.zzz  which is not assigned to a country.

The language used for working out operational documents and for communications is English and French, this could be another hint in favour of a joint exercise.

Fig. 1 - STANAG-4539 transfer using QAM-64

Fig. 2 - STANAG-5066 stream

In addition to text or routine messages such as request to compress photos ("compresser la photo svp"), link informations ("liaison XXX to YYY par HF est nulle") or some ehortations ("veilles respecter le battle rythme et nous transmettre la situation RMP TN/DZ et vos position 12h00"), I saw some operational messages that are worth seeing. Although it could be a joint exercise, I avoid to go into details and some parts of these messages, as well as callsigns, are obscured or omitted for reasons of confidentiality of sensitive information. 

The firts two messages are related to the operation (tactical instructions?) and to the use of the MIO Board.

Fig. 3

Fig. 4

In Fig.5,  looks like they send informal ACP-like messages using email: note the from CMOC (Combined Maritime Operations Center?) to OTC (Operational Training Center?) header

Fig. 5

The operation was successull since the report on the interception of a boat of narcotrafficants (Fig. 6). Drug smugglers have thrown the material off at sea but it has been recovered by the navy sailors. Note how such reports are rigidly formatted in sections (termed "alfa", "bravo", "charlie") and sub-sections.

Fig. 6

Note also that in some messages, likely the more important ones, they make use of return receipts, as indicated by the MDN (Message Disposition Notification) tags in the email shown in Fig. 7 (turnaround time of 31 secs.). I saw MDNs in both English and French language.

Fig. 7

Many joint exercises (Phoenix Express, Morjane, Osis, MEDEX,...) take place every year in Souther Med'sea, so what I heard could be an ad-hoc scenario just established for this exercise.

update: 31 October 2017

...as expected:
http://en.aps.dz/algeria/20899-naval-force... 

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

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.

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).

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.

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): 

http://www.wikiwand.com/en/Air_Defence_Regiment_(Sweden)

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/

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).

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

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):

*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.

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).

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:

[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 (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

 

[1] https://books.google.it/books?id=ylh8AgAAQBAJ&lpg=PA78&ots=0H2YO-Mnvk&dq=KV90%20Sweden%20Army&hl=it&pg=PA78#v=onepage&q&f=true

[2] http://www.hfindustry.com/meetings_presentations/presentation_materials/2010_feb_hfia/presentations/HF2000_HFIA_2010.pdf