1 September 2016

BRASS/MRL file transfer with STANAG-5066 and STANAG-4285

fig. 1a - STANAG-5066 in half-duplex mode
fig. 1b - STANAG-5066 in full-duplex mode
I recently had the chance to analyze some interesting recordings from a two nodes BRASS-MRL test (MRL, or Maritime Rear Link, is a special Ship/Shore link using a separately allocated HF frequency and with messages flowing in both directions).  
Both the link-ends are equipped with Thales HDM-03 HR modems  and  BID-950 as crypto devices. The used HF waveform, as usual in current BRASS deployments, is STANAG-4285, although in some publications it's also reported as "S-4285C" where the ending "C" stands for  "coded", hence the use of FEC and interleavig (Annex E of S-4528). At the data-link layer, the STANAG-5066 interfaces and functionalities are provided by the Selex MDH package.
The recordings are two tracks "stereo" and  pertain half-duplex and full-duplex transmissions [1]
[2], encrypted and plain-text mode. In the latter, BID-950 are electrically disconnected from the red/black circuits so are not traversed by the data flow: I focused only on these recordings. 

I started by separating the full-duplex stereo track into two mono channels (thanks to the sw package "Audacity") and then analyzed one of these (the track related to the "slave" transmissions): the 106.66ms ACF value and the 256 symbol frame structure meet the expected values for the S-4285 waveform (figs 2,3).

fig. 2
fig. 3
Since the lack of the auto-baud functionality, messages about data rate exchange must be transmitted and in this case the DRA mode (Data Rate Adaptive) must be also activated to manage the underlaying (adaptive) modems. In this case DRA is not activated and the right settings for decoding the S-5066 ARQ transmissions are 75bps/Short for the ARQ messages and 2400bps/Short for the file transfer (fig. 4)

fig. 4
The bitstream after the S-4285 removal has been obtained using the ASCII-bit output of a S-4285 decoder; it's worth noting a curious and unusual 32-bit string (white circled in fig. 5) that appears in all transfer frames, either plain and encrypted, full and half-duplex. We'll discuss later about that string.

fig. 5
Protocol S-5066 has been detected by processing the datalink bitstream with the protocol analyzer module (fig. 6)

fig. 6
According to fig. 1a, the file is sent as two "chunks": indeed, after S-5066 removal, we get two extracted files 000_out and 001_out (will be reassembled by the S-5066 package running at the receive side).
fig. 7
Looking at the ASCII view of these files (fig. 8) are visible some interesting clues as the "ARQ1 ARQ2 TESTER" label (possibly the name of the S-5066 session?), the file name, and the indication "S5066 GUI" that is placed at the start and the end of the file. 
As said, the package SELEX MDH is used in these tests and indeed S5066 GUI is just the name of one of its functions (fig. 9). This could also explain why the contents of the files are not intellegible: according to their public documentation (see links) it seems that a proprietary packet format is used, with CRC and other solutions to make the on-air transfer more robust.

fig. 8

fig. 9

But what about the 32-bit string which is visible in all the bitstreams obtained from S-4285 decoders?
Since we are looking at the decoded bitstreams, that string is surely inside the data blocks. If it would be part of S-5066, or part of the transferred file, then it would be seen as encrypted, but it isn't; moreover, it can't be a DRA command/control string since this control is performed over a dedicated serial line.  
The samples are recordered at point "B" of the chain in fig. 10 and analyzed at point "C" i.e. after the S-4285 protocol removal performed by generic decoders.

This leads to think to two possible reasons: 

- the string is added by the tx modem (but why?)
- possibly some limitations/restrictions of the decoders that I used

So, looking at fig. 10, what will be the results if we could sniff the data at point "D", i.e. after they have been filtered by a real professional modem ? 
After piping one of the two full-duplex signals to a professional modem I could capture and analyze the serial data at its output (fig. 11). 

fig. 11

The obtained results match the expected ones and show two of the typical D_PDUs used by the Data Transfer Sublayer of S-5066: the link request, D_PDU type 8, and the file transfer, D_PDU type 0  (fig. 12).

fig. 12
There is no evidence of that 32-bit string and, moreover, the bistream obtained after the hex-to-binary conversion is more compact than the bistream got from generic decoders (fig.123). By the way, since I'm installing a GEC-Marconi "ARM-9401" modem this post will have possibly a continuation.

fig. 13
Summarizing, S-5066 is a pure datalink protocol and it doesn't define ALE (Automatic Link Establishment) as S-4538 does. Either, a fixed frequency must be agreed upon, or it is possible to run S-5066 in conjunction with an external 2G-ALE system. As seen, in these test recordings there are no ALE sessions and once the frequency has been agreed by the peers (or known from CARBs broadcasts) the master initiates a link request and after the acknowledgment sent by the slave, the file transfer/exchange may start.

I want to thanks my friend Marco for the help with professional modem and for the screenshot of the "MDH Control Centre" sw package.

[1] half-duplex recordings 
A system anomaly is clearly evident in fig. 1a, after all ...these are just test transmissions.

You may see that the master start to transmit the second frame before to receive the first ACK sent by the slave. This should never happen since in the absence of ACK, and after a certain timeout, the master should close the link ("breaking" state).
Moreover, a collision happens since the two peers transmit at the same time (half-duplex violation). In this case the Data Carrier Detect (DCD) should be activated so that when it goes "high" it means that the channel is busy and, in this case, the slave must be silent just to avoid collisions.

[2] full-duplex recordings
Looking at the full-duplex tracks, after the peers linked they go in full-duplex split-frequency operation and then work in two different (formerly agreed) frequencies: this is not evident in fig. 1b since software Audacity represents the tracks in the time domain.

Full-duplex operations are described in the Annex C of STANAG-5066 profile (see the links above).

Useful Links:
Implementing Full Duplex with Data Rate Adaption in STANAG-5066  
STANAG-5066 Annex C 

No comments:

Post a Comment