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

fig. 1a - STANAG-4285 in half-duplex mode

fig. 1b - STANAG-4285 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 4285 75bps/Short for the ARQ messages and 4285 2400bps/Short for the file transfer (fig. 4)

fig. 4

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

fig.5

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

Looking at the ASCII view of these files (fig. 7) are visible some interesting clues as the "ARQ1 ARQ2 TESTER" label, 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. 8). 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.7

fig.8

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:
BID-950 
SELEX MDH
Implementing Full Duplex with Data Rate Adaption in STANAG-5066  
STANAG-5066 Annex C