Durings the last fewer 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 usage MS-110A as the HF waveform and most of them usage FED-1052 App.B as Data Link Protocol (DLP)(1): Figure 1 is an example in this regard. Since the usage of FED-1052 DLP, the HF waveform could likewise be FED-1052 serial (single-tone) given that the 2 waveforms are interoperable. Links are performed utilizing 2G-ALE handshakes (MS-141A), logged callsigns are K01, k02, K03, K08, K13, and K14.
 |
| Fig. 1
|
1. The demodulated bitstreams of the first 4 Tx segments ("A" in Figure 1) have a common 26-byte (10+16) dimension first series which may be seen as consisting of the 2 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 - first Hex sequences |
[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 dimension of the first 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 utilizing the 2400bps/voice mode, the data blocks between the (presumed) IVs and and the ending sequences could consist of safe digital voice. The Shannon entropy value computed on data blocks (7.792888420337759) could propose 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 another 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 fresh transmission over the physical channel shall begin with a 3 byte (24-bit) frame synchronization pattern to identify the following traffic as DLP processed traffic. The frame synchronization series in hexadecimal format, shall be "5C5C5C". The sync pattern shall be transmitted specified that the first 8 bits in order of transmission are "00111010" (see Figure 4).
 |
| Fig. 4 - FED-1052 DLP sync patterns |
Looking at the origin 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. announcement that the DLP addresses 01 and 03 match the ALE callsigns K01 and K03 utilized 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 simply 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 consequence of a "fragmentation" of messages received from the user (or from a higher-layer protocol).
The tiny 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) series which may be seen as consisting of 2 Hex strings:
[16 16 16 16 16 16 16 16 16 16] [DF 73 0D 1D 5B 22 53 81]
and word 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 series is the double of the dimension of the first 0x16 series (Figure 7):
 |
| Fig. 7 |
The 0 value bytes are padding bytes added to the last package to get the 56-byte size: it can easy 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 request to be padded with fill bits. The receive terminal will usage the transmit message size information to find 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 |
Moreover, from the bitstreams analysis, it seems to me that the protocol is utilized to send different kind of data and in different modalities: any types of data (Tx segments "A" in Figure 1) are forwarded straight to the MS-110A/FS-1052 modem, another 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. possibly the 2 first strings announce the kind of the following data blocks, but it's only a my guess.
By the way, the long durations of the 2G-ALE scanning call supply any 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 simply a selective repeat ARQ protocol with the ability to adaptively vary respective parameters in consequence to changing channel conditions. A transmission usually consists of a data series, containing respective data frames, or a single control frame. all frame contains a CRC. Before data transfer commences, HFDLP terminals exchange control frames to negociate the number of data bytes per data frame (56 to 1023), the number of data frames per data series (1 to 255), and a fewer another characteristics of the data transfer procedure.
(2) As per FED-1052 standard, origin Address and Destination Address fields are restricted to 2 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 advanced frame in figure A-29). Otherwise, it (SAM) shall send a longer calling cycle that precedes the leading call with a scanning call of adequate dimension 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.
