(unid) synchronous transfer protocol over MS-110A & FED-1052 DLP

Durings the last few days I have monitored the frequency 7762.0 KHz/U and collected very interesting recordings of transmissions regarding a (possible) synchronous transfer protocol which sits at a higher layer than the datalink one. All transmissions use MS-110A as the HF waveform and most of them use FED-1052 App.B as Data Link Protocol (DLP)(1): Figure 1 is an example in this regard. Since the use of FED-1052 DLP, the HF waveform could likewise be FED-1052 serial (single-tone) given that the two waveforms are interoperable. Links are performed using 2G-ALE handshakes (MS-141A), logged callsigns are K01, k02, K03, K08, K13, and K14. 

Fig. 1

1. The demodulated bitstreams of the first four Tx segments ("A" in Figure 1) have a common 26-byte (10+16) length initial sequence which may be seen as consisting of the two Hex strings/sequences shown in Figure 2:

[16 16 16 16 16 16 16 16 16 16] [8E 5C 0B AA 97 30 56 E6 93 A2 B3 FB 6D 1A E2 01] 

Fig. 2 - initial Hex sequences

The two initial strings are followed by an apparently random 224-bit/28-byte sequence which is 3 times repeated: that sequence is unique for each Tx segment so that it could be an Initialization Vector (IV): the repetitions are indeed a good clue (Figure 3):

[54 6A 59 86 D8 0D 5E EE 94 AF B7 25 C1 DB 44 A8 BF 4B F9 DF AF F4 BF 1D 94 F9 6D 3F]

[FA D6 B4 C8 3D 50 BA 06 F1 E7 4C 22 02 A5 86 48 F9 6D AA 76 29 3C 0A E0 51 E8 61 FF] 

[58 FC 4A D4 09 C2 82 9B 75 93 16 2D 8A 11 B1 D3 8A DE F1 55 79 2E 52 E1 53 02 E2 B5]
[A7 55 A7 B1 8E E9 68 96 84 DF 57 FA AF A2 09 E9 EA DB D5 53 16 9F 20 E7 93 75 24 86]

Fig. 3 - 28 bytes sequences

The bitstreams end with a 20-byte string of 0x16, just the double of the length of the initial 0x16 sequence:

[16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16]

Fig. 3 - ending Hex sequences

Since these Tx segments are sent using the 2400bps/voice mode, the data blocks between the (presumed) IVs and and the ending sequences could consist of secure digital voice. The Shannon entropy value computed on data blocks (7.792888420337759) could suggest encrypted or compressed files. Just to be thorough, I thought about checking whether the repeated 28-bytes sequences were SHA-224 digests (64 rounds, by default) of the following data blocks, but the results did not confirm this hypothesis.

2. The bitstreams resulting after demodulating the other 12 Tx segments ("B" in Figure 1) are recognized as FED-1052 App. B "DLP Data Link Protocol" frames (also known as HF Data Link Protocol, HFDLP). Quoting FED-1052 standard #50.1.1.1 Frame sync pattern:  Each new transmission over the physical channel shall begin with a three byte (24-bit) frame synchronization pattern to identify the following traffic as DLP processed traffic. The frame synchronization sequence in hexadecimal format, shall be "5C5C5C". The sync pattern shall be transmitted such that the first eight bits in order of transmission are "00111010" (see Figure 4).

Fig. 4 - FED-1052 DLP sync patterns

Looking at the Source and Destination Address fields (2) in the hexdumps of Figure 5, it's possible to see the exchanges of DLP frames between the addresses 03 (0x3330, ASCII 30) and 01 (0x3130, ASCII 10): forward and reverse directions are due to the ARQ feature of DLP protocol. Notice that the DLP addresses 01 and 03 match the ALE callsigns K01 and K03 used during the link setup process (Figure 5).

Fig. 5 - DEF-1052 DLP frames exchanges

More precisely, each DLP transfer consists of 3 frames (Figure 6):  the first is a data frame (bytes block delimited by 0x16) while the 2nd and 3th are control frames.

Fig. 6

DLP data frames consist of 56-bytes "packages", thus the re-assembly process produces files that have lengths in multiples of 56 (112, 168, 224, ...). By the way, packages are the result of a "fragmentation" of messages received from the user (or from a higher-layer protocol).

The small files resulting after the re-assembly process (and the removal of FED-1052 DLP overhead) are not in clear-text... and here things get interesting. 

The files start with a common 18-byte (10+8) sequence which may be seen as consisting of two Hex strings:

[16 16 16 16 16 16 16 16 16 16] [DF 73 0D 1D 5B 22 53 81]

and term with the 20 bytes Hex sequence:

[16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16] 

Also in this case, the ending 0x16 sequence is the double of the length of the initial 0x16 sequence (Figure 7):

Fig. 7

The 0 value bytes are padding bytes added to the last package to obtain the 56-byte size: it can easily be verified for each packet by subtracting the "data" bytes from the "received" ones. Quoting FED-1052 standard #50.4.3.1.2: All data frames shall be of the same size [...] this implies that the last data frame of a message may need to be padded with fill bits. The receive terminal will use the transmit message size information to determine where the message is to be truncated in order to remove the fill bits from its output data stream. The 16-bit graphic rapresentations are shown in Figure 8.

Fig. 8

 

Data consist of a few bytes, I do not think they are compatible with digital voice or "informal messages", maybe they are numerical data even if some format does not emerge.

3. I know that 0x16 is the <SYN> "Synchronous Idle" (TC9) ASCII control character. It is used in synchronous transmission systems to provide a signal from which synchronous correction may be achieved between data terminal equipments, particularly when no other character is being transmitted. The SYNC char was also used in syncrhonous modems at start and end of info blocks. So, the initial sequences of SYNC make me think of a kind of "synchronous transfer protocol" sitting at higher-layer.
Moreover, from the bitstreams analysis, it seems to me that the protocol is used to send different type of data and in different modalities: some types of data (Tx segments "A" in Figure 1) are forwarded directly to the MS-110A/FS-1052 modem, other types of data (Tx segments "B" in Figure 1) are first managed by FED-1052 DLP and then forwarded to the MS-110A/FS-1052 modem. Maybe the two initial strings announce the type of the following data blocks, but it's only a my guess.

By the way, the long durations of the 2G-ALE scanning call provide some indications about the number of the available channels: assuming full compatibility(!) with MS-141, the collected scan lists should be >= 20 channels (3). User should be Dutch MIL... but it's not confirmed.

Fig. 9 - 2G-ALE MS-141 scan call

 

https://disk.yandex.com/d/CrXu2QY4-AP9vQ 

(1) The HFDLP is a selective repeat ARQ protocol with the ability to adaptively vary several parameters in response to changing channel conditions. A transmission usually consists of a data series, containing several data frames, or a single control frame. Every frame contains a CRC. Before data transfer commences, HFDLP terminals exchange control frames to negotiate the number of data bytes per data frame (56 to 1023), the number of data frames per data series (1 to 255), and a few other characteristics of the data transfer procedure.

(2) As per FED-1052 standard, Source Address and Destination Address fields are restricted to two bytes each, LSB first. 

(3) 188-141 A.5.5.3.1 "If the called station (JOE) is known to be listening on the chosen channel (not scanning), the calling station (SAM) shall transmit a single-channel call that contains only a leading call and a conclusion (see upper frame in figure A-29). Otherwise, it (SAM) shall send a longer calling cycle that precedes the leading call with a scanning call of sufficient length to capture the called station’s receiver as it scans (lower frame in figure A-29). The duration of this scanning call shall be 784ms for each channel that the called station is scanning.