A 142-byte Data Link Protocol with fragmentation support

The signal captures used for this post were recorded a few days ago on 6369.0 kHz (USB) and kindly provided by my friend Kosmod; below is my analysis, which took inspiration from some observations just shared by Kosmod.

Notes:
* the following analysis remains provisional and subject to further revision;
* field designations are my own and are used for clarity and convenience of presentation;
* unless otherwise specified, all values enclosed in square brackets are in hexadecimal format.

HF Waveform Analysis
Despite the spectral appearance of the signals (Figure 1), the transmissions do not appear to be ARQ-based, as no return acknowledgments (ACKs) were observed in the demodulated bitstreams. This is further supported by the consistent fading profiles observed, which indicate that both short and long bursts likely share the same transmission path and originate from the same station. It is likely that this is a strictly unidirectional protocol. Physical layer employes MS-110A waveform, captures include various data rates (300, 600, 1200, and 2400 bps), all employing a Short Interleaver. 

Fig. 1 - part of 6369.0 KHz recordings

MS-110A demodulation of the bursts clearly indicates the use of the 8N1 asynchronous format, as shown in Figure 2.

Fig. 2 - 8N1 framing format in a demodulated bitstream

Protocol Headers Analysis
Following the removal of start/stop bits, the bitstreams are characterized by fixed-length frames with a 9-byte headers, all beginning with the same 16-bit ynchronization (SYNC) word 0xD000, likely with the least significant bit (LSB) transmitted first. Based on the observed bitstreams, byte following the SYNC (i.e., the 3rd byte) is interpreted as a Length Field for a total frame size of 142 bytes: the value 0x8C (140 decimal) representing the remaining payload (142 total bytes minus the 2 initial SYNC bytes). The reduced values in this byte, e.g. 0x6A, 0x68, 0x81, indicate a fragmented payload, typically occurring when the transmitted data does not fully occupy a standard "block". In these cases, the length field allows the receiver to correctly identify the end of valid data and ignore any subsequent padding.

Header alignment is achieved by locking the bitstream to the SYNC sequence and a 142 bytes (1136 bits) frame length, as illustrated by the HEX dumps in Figures 3a and 3b.

Fig. 3a - HEX dump of demodulated bitstreams

Fig. 3b - HEX dump of demodulated bitstreams

Note that, following the 9-byte header, the initial packet (index 0x00), and occasionally subsequent ones, begin with the fixed sequence [00 AA 79 50 D1 00 00 E9 00], which likely represents static payload values or a secondary synchronization pattern.

The proposed frame header structure is shown in the following Table I; it details the byte-level organization of the headers, assuming a Little-endian (LSB first) convention for multi-byte fields:

Table I - proposed frame header structure

The protocol utilizes a nested counting structure. Byte 5 functions as a Logical Block index, while Byte 4 acts as a Fragment index. Notably, every time Byte 5 increments, Byte 4 resets to its base value 0xD1. This behavior confirms that Byte 4 is not a global counter, but a local sequence identifier used to order individual fragments within each specific logical block.
The analysis of the Fragment ID field (Byte 4) suggests that the counter is limited to the lower nibble. The constant high-nibble value of 0xD (1101​) likely serves as a system flag, while the lower nibble provides the effective fragment index (0000 - 1111). This bitfield bifurcation explains why the byte appears to start at 0xD1 rather than 0x01. The lower-nibble implementation constrains the fragment index to a maximum value of 0xF​ (15 decimal).
The reset interval for the Logical Block index (e.g., per session, per 24-hour cycle, or per transmission burst) remains to be determined pending further signal acquisition.

SAR (Segmentation and Reassembly) Analysis
To ascertain the field functions and the underlying fragmentation hierarchy, an assessment of the headers from multiple consecutive bursts is required (see Figure 4). 

Fig. 4 - HEX dumps of multiple consecutive bursts for block 0x74

Burst #1
[D0 00 8C D1 74 04 00 00 00]
[D0 00 8C D1 74 04 00 01 00]
[D0 00 8C D1 74 04 00 02 00]
[D0 00 81 D1 74 04 00 03 00]
Burst #2
[D0 00 0C D2 74 04 00 03 00]
Burst #3
[D0 00 0D D3 74 04 00 04 00]
Burst #4
[D0 00 0D D4 74 04 00 04 00]
[D0 00 0D D4 74 04 00 04 00] 

 1    2   3    4   5   6  7   8   9 <----- bytes 

a) It is highly probable that the 0xD0 byte within the synchronization word serves a dual purpose: providing physical layer alignment while simultaneously acting as a Start-of-Frame (SoF) marker for the first fragment. Under this model, the 0xD0 marker initiates the block transmission, with all subsequent fragments identified by the sequence in Byte 04 (0xD1,0xD2,0xD3, etc.).

b)The block size field (bytes 6–7) utilizes a Little-Endian (LSB first) unsigned integer format. A value of 0x0400 indicates a 0-indexed count, confirming a total of five packets (00 through 04) within the sequence. 

c) The Packet Index field (bytes 8–9) also utilizes a Little-Endian (LSB first) unsigned integer format, indicating the relative position of the packet within the current logical block.

d) Evidence of cross-burst fragmentation is found in packet 0x03:
- Burst #1: packet 0x03 was captured with a truncated payload length of 0x81 (129 decimal);
- Burst #2: the remainder of packet 0x03 was transmitted with a payload size of 0x0C (12 decimal).

e) The aggregate length (129+12=141 bytes) slightly exceeds the standard 140-byte frame payload capacity. This discrepancy suggests that packet 0x03 was too large for a single transport frame and was intentionally fragmented across two consecutive physical bursts, indexed as fragment IDs 0xD1 and 0xD2 respectively.

f) The fact that packet 0x04 is so small, 0x0D bytes in bursts 3-4, compared to the others 0x8C bytes, is sent last and is spread across two different fragments (and bursts) suggests it is a trailer or checksum packet for the entire block.

Sumarizing:
Burst #1, Logical Block 0x74 Fragment ID 0xD1: occupied by packets 00, 01, 02, and the first part of 0x03
Burst #2, Logical Block 0x74 Fragment ID 0xD2: reserved exclusively to finish the "overflow" of packet 0x03
Burst #3 & #4, Logical Block 0x74 Fragment IDs 0xD3 & 0xD4: dedicated to packet 4

The relationship between the different layers of the protocol is shown in Figure 5 (elements are not to scale). The diagram shows the decomposition of logical block 0x74 into its constituent fragments (0xD1–0xD4) and the subsequent packets (00–04). Note the one-to-one mapping between logical fragments and physical bursts.

Fig. 5 - different layers of the protocol, the diagram is conceptual and not to scale

The diagram shown  in Figure 6 illustrates the SAR (Segmentation And Reassembly) process, i.e., the relationship between the physical burst transmission and the logical packet reassembly, highlighting cases of fragmentation and sequence continuity (all values are in Hex).

Fig. 6 - Segmentation And Reassembly process of block 0x74 (5 packets)

Consistent results are achieved through the analysis of other bursts, such as those associated with the transmission of block 0x76 (Figs. 7,8).

Fig. 7 - HEX dumps of multiple consecutive bursts for block 0x76

Fig. 8 - Segmentation And Reassembly process of block 0x76 (9 packets)

Conclusions
This is highly likely a (unid) proprietary protocol; unfortunately, at the time of writing, there are no available hypotheses regarding the transmitter site, nor the potential end-user. The protocol employs non-uniform fragmentation, where the payload size per burst is inconsistent; packet captures indicate potential truncation or the presence of trailing zero-fill sequences to maintain frame alignment. The architecture utilizes a 142-byte fixed frame with a 9-byte header to manage data encapsulation. The data stream is structured into logical blocks, mapped to individual packets, and transported via physical bursts, a process orchestrated by the Block ID ➔ Fragment ID ➔ Packet Index hierarchy.
However, based on the recordings at my disposal, the protocol does not always follow a strictly linear progression as the one shown by the diagram above. In some instances, the data flow incorporates non-linear repetitions or sequence adjustments, although the reassembly process itself does not change, e.g.:
- packet re-injection: high-index packets are interrupted by the re-insertion of earlier packets;
- fragment reversion: the sequence occasionally "rewinds" to repeat the final fragments of a previous packet before continuing with the current one.
These events can manifest either as a direct repetition of previously transmitted data or as a continuation of a previous packet's fragment sequence. 

Technical Comparisons and Alignment With Standards
- STANAG-4538 parallels: the architectural choices of this protocol, specifically the SAR mechanism and burst-oriented delivery, show significant functional parallels with the xDL protocols described by STANAG-4538. However, unlike the ARQ-based nature of xDL protocols, based on the captures at my disposal this protocol operates in a purely unidirectional mode, prioritizing redundancy over acknowledgments (1).
- STANAG-5066 & MS-110A correlation: the observed strategy also aligns closely with STANAG-5066 architectural principles. Similar to how STANAG-5066 segments data for transmission over MIL-STD-188-110A (MS-110A) modems, this protocol maps logical fragments directly to physical bursts. This is particularly evident in its configuration, where the absence of a return channel mirrors the high-reliability tactical stacks used in HF communications to ensure data persistence through noise (2).

Coming Up
While the proposed structure provides a good framework for understanding the protocol's behavior, additional captures are required to better define it. However, to avoid overcomplicating this discussion, detailed analyses of non-linear SAR and reassembled packets/blocks will be addressed in a forthcoming dedicated post.

As a side note, a special mention to Kosmod who is a great signals hunter... and a good provider :)

https://disk.yandex.com/d/TfhM9dfTb-ECww

(1) STANAG-4538 (3G), defined as an "all-in-one" monolithic protocol, integrates link setup (FLSU) and data transport (xDL) within a single ecosystem, utilizing its own proprietary waveforms specifically optimized for symbiotic operation between the modem and the data link layer.

(2) STANAG-5066 (2G) operates as a layered Data Link protocol. It serves as an interface between applications and the physical layer. Unlike STANAG-4538, it does not possess a dedicated waveform family; instead, it leverages standard external waveforms such as MIL-STD-188-110 (A/B/C/D) or STANAG-4539 to "feed" the underlying physical modem.

256-bit IVs & 0xD1E221E1 sequence

Just a quick note to observe that bitstreams using (alleged) 256-bit Initialization Vectors (IV) encryption have the same 32-bit/4-byte sequence repeated three times. For example, in the bitstream in Figure 1 (MS-110A transmission) you can clearly see the 256-bit IV sequences, each repeated eight times. 

Fig. 1

But if you reshape the same bitstream into columns of 32 bits the same 32-bit sequence 0xD1E221E1 emerges (Figure 2).

Fig. 2

I have previously encountered bitstreams with 256-bit IVs [1] but at that time I had not investigated further, focusing only on those sequences. As a counter-proof, I took back and analyzed those signals and - surprise - they also all present the same sequence 0xD1E221E1 after the IVs (Figure 3).

Fig. 3

It should also be said that I have also encountered the sequence 0xD1E221E1 three times previously [2] but, when I re-analyzed those transmissions, the 256-bit IVs were not found (Figure 4).

 

Fig. 4

Both for the position of the 4-byte string 0xD1E221E1 (after or WITHOUT the alleged IVs) and for its presence in different streams it is difficult to say whether it identifies a sync string for a cipher device or whether it identifies a particular datalink protocol. However, in all cases I could analyze, STANAG-4538 (3G-HF) "circuit mode service" is used along with MS-110A as the traffic waveform.

Comments and suggestions on this matter are welcome!

 

https://disk.yandex.com/d/DxsFHMYcLIw4cA 

[1] https://i56578-swl.blogspot.com/2020/09/s-4538110a-transmissions-using-unid-256.html
[2] http://i56578-swl.blogspot.com/search/label/P%3D32

about the unid 32-bit protocol used in S-4538 + MS-110A transfers

This is the third time I have encountered these transmissions [1] and, given the good number of recordings made over a few days on the frequency 6964.5 KHz/USB, it is now possible to draw a more definitive "picture".

Transmissions normally occur each 5 minutes and last 1.5 - 2 minutes average. STANAG-4538 (3G-HF) "circuit mode service" is used, where MS-110A (usually in 75bps/Long Interleaver mode) is the used traffic waveform; sometimes a transmission may consist of two or more distinct data transfer sessions (Figure 1).

Links are established using the FLSU (Fast Link SetUp) Asynchronous scanning call, using BW5 and an "optimized" waveform which provides no repetition of the initial TLC section (used for transmitter level control and receiver AGC settling). Such a scanning call is exactly described in paragraph C.5.2.4.5.2 of  MIL 188-141B Appendix C: "The LE_Scanning_Call PDU shall be sent repeatedly to capture scanning receivers [...] During a scanning call, only the first LE_Scanning_Call PDU shall include TLC. All succeeding LE_Scanning_Call PDUs and the LE_Call PDU shall omit TLC, and include only the BW0 preamble and data portions" (1)(2). So, we look at a STANAG-4538 FLSU Async call (since the use of BW5 waveform) which is 188-141B compliant for what regards its formation (since the omission of  the TLC sections): ie, a sort of  188-141B/STANAG-4538 mixed implementation most likely implemented by L3Harris [2][3]. That "formation" of the Async call clarifies why decoders recognize only the "first" BW5 PDU. 

Fig. 1

Looking at the asynchronous scan calls, at first glance it seems that Linking Protection (LP) is not used: in fact, as you can see, the decoded strings are identical. This should not happen since when operating in encrypt mode, the LP algorithm takes as inputs the PDU to be scrambled, a key variable, and a “seed” that contains Time of Day (TOD) and the frequency that carries the protected transmission.

2024-08-21T09_54_32Z BW-5 00111001010000100011011001001010011110001000011010
2024-08-21T09_56_17Z BW-5 00111001010000100011011001001010011110001000011010
2024-08-21T10_01_54Z BW-5 00111001010000100011011001001010011110001000011010

2024-08-22T07_46_52Z BW-5 00010110100000110011111110111010101110111100000110
2024-08-22T07_51_52Z BW-5 00010110100000110011111110111010101110111100000110

Anyway, it's to note that when the protection against spoofing offered by LP is not required, LP may be used without a key variable or seed to provide only scrambling based on the network number as described in STANAG-4538 4.1.2 (in this regard, note that the scanning calls of 2024-08-22, for example, do not have the expected value "001" in the first three bits). 

The analysis of the MS-110A decoded bitstreams show initial 100 bytes length headers which have some parts common to all the bitstreams, the header "format" is more evident after the removal of the initial "10"s sequence (Figures 2,3).

Fig. 2

Fig. 3

In my opinion, headers are made up of the following structure (Figure 4):

1) common initial sequence

1100000100011100101001 (maybe 001100000100011100101001, 0x0CE294)

2) common 193 bits length "01"s sequence, (phasing?). Boundaries are marked by two consecutive logical "1"

3) common 160 bits / 20 bytes length sequence (sync sequence for the receive crypto device?)

10001011010001111000010010000111
01111011101101001011100010000111
01000100011110000100100001110111
10111011010010111000101101110100
01000111100001001000011101111011

4) 256 bits / 32 bytes length sequence which is different in every bitstream (Initialization Vector?)

5) common 5×32 bits / 4 bytes repeated sequence (frame sync?). Note that the sequence can't be an Initialization Vector since it's always the same in every bitstream.

10001011010001111000010010000111
10001011010001111000010010000111
10001011010001111000010010000111
10001011010001111000010010000111
10001011010001111000010010000111

Also note that the 4 bytes repeated sequence is used in the first 4 bytes of the 160 bits sequence.

Fig. 4 - the common blocks in the headers of the bitstreams

According to the results of the "Shannon Entropy" and "Statistical" tests, the ansferred data are most probably encrypted (Figure 5).
The measure of the Shannon Entropy can be used, in a broad sense, to detect whether data is likely to be structured or unstructured. 8 is the maximum, representing highly unstructured, 'random' data. Properly encrypted or compressed data should have an entropy of over 7.5 The statistical test below determines the randomness, the number of single bits in the stream is counted, then the double bits, then the triple bits and so on to the end. The result is a graph: if the information is not systematic, the adjacent columns should be half the size of the previous ones. Both the test shows good encryption quality.

Fig. 5 - Shannon Entropy and Statistical tests on the data portions

The transmissions are fairly receivable only in the northern regions of Europe, likely a low power transmitter is used or a local/domestic area shall be served. Just about the site of the transmitter,  all my direction finding attempts point to a quite large area in Norway (Figure 6): maybe a Royal Norwegian Navy Tx? Anyway, it's to notice that the DF results "suffer" from the lack of detection points west of Norway.

Fig. 6 - Direction finding attempts (TDoA algorithm)

Monitoring & recordings thanks to the remote KiwiSDRs SM0KOT (Sweden) and OZ1AEF (Denmark) [4][5]. 

https://disk.yandex.com/d/AcwncUTKxXlQ_A (decoded bitstreams)

(1) MIL 188-141B refers to BW0 as the waveform to convey "LE_Scanning_Call PDU" and "LE_Call PDU" (LE stands for Link Establishment): FLSU, and consequently the BW5 waveform, were not yet defined at that time.

(2) 188-141B (released on March 1999!) was superseded by 188-141C (December 2011), in its turn superseded by 188-141D (December 2017): the last two standards no longer have the Appendix C but only some short paragraphs, among them the #C.6 says "The specifications previously contained in this appendix have been replaced with reference to the essentially identical NATO STANAG 4538".

[1] http://i56578-swl.blogspot.com/search/label/P%3D32
[2] http://i56578-swl.blogspot.com/2022/10/harris-3g-ale-flsu-async-call.html
[3] http://i56578-swl.blogspot.com/2022/10/harris-3g-ale-flsu-async-call-2.html
[4] http://aspliden.kostet.se:8074/
[5] http://85.191.35.22:8073/

 

a STANAG-4285 autobaud waveform?

Interesting STANAG-4285 transmission heard on 14000 KHz/USB and sent me by my friend GrandBleu from radiofrecuencias.es (Figure 1)

Fig. 1 - STANAG-4285 segments

The 35 sec segments seem a modified S-4285 waveform since they begin with a block, that I here refer to as "header", and which is not referenced in the standard. The header has a duration of 116ms and is modulated using PSK2, as you may see in Figure 2.

Fig. 2 - PSK2 modulation detected in the initial "header"

I used the SA phase detector and its relative bitmap in order to "browse" the signal and to better indagate the header. Looking at Figure 3 you may see a 13.333ms repeated pattern: well, 13.333ms @ 2400 symbols/sec makes a duration of 32 symbols (31,999) or 32 bits, since the header is PSK2 modulated (ie 1 bit = 1 symbol).

Fig. 3 - 32-bits repeated pattern in the header of the heard S-4285 waveform

Consequently, I tried a PSK2 demodulation of the headers of some segments and after their differential decodings I obtained  bitstreams which exhibit a well-defined structure consisting of initial and final "01"s sequences and characterized by a 32 bits sequence which is six times repeated immediately before of the final "01"s sequence and that exactly matches the pattern seen in the bitmap of Figure 3.

[10100001001111001111100011011110]

Fig. 4 - differential PSK2 decoding of a header

The same 32-bit sequence was found in all the headers I demodulated (just 3 of them are shown in Figure 5), even if it didn't appear in the same order I wrote it: one must consider the characteristcs of the SA's generic (!) PSK-n demodulator .

Fig. 5

I don't think this so-called header is actually a “transmit level control” (TLC) block. Indeed, no information is carried by the TLC since it's a sequence of symbols intended solely for the purpose of establishing the radio TGC (transmit gain control), ALC (automatic level control) and AGC (automatic gain control) before the actual preamble is sent/received. In my opinion this S-4285 waveform feature an “autobaud” facility (1) which is coded in the initial header (perhaps a Walsh coded sequence?). As shown in Figure 5, the autobauding information would consist of 6 frames, each with a duration of 13.3 ms and a length of 32 bits (total length of 192 bits), and precedes the S-4285's usual synchronization preamble.

And let's get to the data blocks. To identify which sub-mode is used I chose from time to time the various options made available by a S-4285 decoder (k500) until I found the option that had 100% confidence and 0 errors: that is, 300bps and zero length interleaving.  As a test, I used a second S-4285 decoder and always got the same result even if the resulting bitstreams didn't seem structured. Although these decoders indicated 100% confidence and 0 errors (corrections), curiously they did not detect/show the 32-bit words used for signaling the Start Of Message (SOM = 0x03873C3C MSB first) and End Of Message (EOM = 0x4B65A5B2 MSB first): could it be sign of a "fake" decoding? Finally, I used a third, more sophisticated, decoder configuring it in "auto-detect" mode: this third test also confirmed the 300bps/N sub-mode but with the reporting of corrections and a resulting bitstream with a 40-bit/5-byte period that has - in my opinion - a bit more sense.
The 40-bit length period is due to the presence of a sequence that is four times repeated near the end of all the decoded segments (Figure 6). Note that the same considerations made above apply to the sequence in question.

[1101101000100111101001111111000111100101]

At first glance it could be an EOM/EOT signal but the bitstream should come from a higher level protocol (datalink layer) i.e. after the removal of the S-4285 overhead and therefore should have a different function.

Fig. 6 - a data blocks bitstream

That datalink protocol (if any ) is at present unknown to me.

Back to the initial headers, I remembered having seen something similar a while back while I was analyzing Harris' serial PSK8 waveforms [1] and by demodulating their initial headers I found a correspondence between those headers and the one analyzed here: that is, a sequence of 32 bits of length which is repeated six times between sequences of initial and final "01"s (Figs. 7,8)

Fig.7

Fig.8

From the above it seems that L3Harris (and perhaps not only them) have added the "autobaud" function to some waveforms such as STANAG-4285, obviously it is only my hypothesis which has no direct or indirect confirmation: your comments and other submissions will be as usual welcome and may assist in resolving this matter.

https://drive.google.com/file/d/1WD9gBFzbGnmMdBFITTOYFf5AOTWCij4y/view?usp=sharing

(1) the “autobaud” facility enables the receiver modem to automatically adapt the transmitter’s data rate and interleaver configuration without operator intervention

[1] http://i56578-swl.blogspot.com/2021/11/harris-psk8-2400-bd-digital-voice.htm

unid datalink protocol(s) over a PSK8 ST and STANAG-4539 (2)

I had the opportunity to record other transmissions on 3712.70 KHz/USB and - also following the comment of my friend KarapuZ - I can state with reasonable certainty that the waveforms analyzed in the previous post [1] come from Thales equipment. 
As mentioned, both Thales and L3Harris use the GMSK-MFSK8 waveform to handle HF links but the L3Harris bitmap/bitstream have a very recognizable pattern that is not present in the bursts recorded today (Figs 1,2): therefore, the GMSK-MFSK-8 signal is the Thales Systeme-3000 "Skymaster ALE", used in TRC-3500 and TRC-3600/TRC-3700 series radios (HF 3000 family).

Fig. 1 - Thales Systeme-3000 GMFKS+MFSK8

Fig. 2 - Thales Systeme-3000 GMFKS: bitstream after differential decoding and 50ms bitmap

As you see in Figure 2, I used the OQPSK "view" to demodulate the preamble of the Skyaster ALE signal: however, the differential decoding clearly show a 2-state keying (precisely GMFSK) that can be demodulated also using the "classic" FSK approach (Figure 3).

Fig. 3 - use of the SA MFSK dem

For what concerns the two PSK8 Serial Tone waveforms A & B [1], they also could be proprietary ones (Thales); indeed, quoting TRC-3600 datasheet: "Thanks to its digital advanced technology, the TRC 3600 offers new embedded services: secure high data rate and digital voice transmissions. It integrates a high data rate, multiwaveform, single tone modem (from 75 to 5400 bps) and a vocoder (800 - 2400 bps) associated to a high security digital COMSEC chip". 

The data link protocol could be the digital voice vocoder (new MELP/LPC10), given the similarity of the bitstream with its L3Harris analogue, but that is just an unconfirmed hypothesis of mine.

Fig. 4 - bitmaps of the two PSK8 ST waveforms

 

 https://disk.yandex.com/d/6NK6xYRAWzjzEw

 [1] http://i56578-swl.blogspot.com/2024/04/unid-datalink-protocols-over-psk8-st.html

unid datalink protocol(s) over a PSK8 ST and STANAG-4539 (Thales? L3Harris?)

A few days ago I came across some transmissions that caught my attention for at least three good reasons:
1. the frequency used, i.e. 7312.7 KHz/USB, within the 42 meter broadcast band;
2. the use of different traffic waveforms, ie PSK8 serial Tone and STANAG-4539, in ARQ and non-ARQ modes. The ARQ mode is easily recognizable by the difference between the frequencies of the subcarriers (around 50Hz) of data and ACK segments (1);  

Fig. 1 - different traffic waveforms

3. the use of a waveform composed of GMFSK-2000Bd + MFSK8 for the link setup procedure (Figure 2): as far as I know, this particular waveform is used by both Thales and Harris. Notice that the MFSK8 part is 188-141A compatible (125Bd & 250Hz separation between the 8 tones) but use a diferrent tone library.

Fig. 2 - GMFSK + MSK8 link setup waveform

I had already met such transmissions, noting how the system was able to simultaneously demodulate 2/3 waveforms (or more if we consider the ALE exchanges) even during the same logical link. In these recordings a single waveform (PSK8 ST or S-4539) is mostly used and I took advantage of this to study the characteristics of the used datalink protocol; a protocol which - in my opinion and according to my analysis - turns out to be proprietary and quite complex.

PSK8 Serial Tone
Figure 3 shows the 8-ary constellation (states and transitions) as well as the rasters of the two PSK8 modulated waveforms A and B. In the phase states, and especially looking at the transitions, one can easily notice the presence of a PSK2 modulation which is certainly used for the synchronization sequences visible in the bitmaps below. As usual, the resulting PSK2 symbols are then mapped and scrambled to appear, on-air, as a PSK8 costellation. Bot the the waveforms have an ACF of 106.6 ms that makes a 256 PSK8 symbols frame at the modulation rate of 2400Bd. However, although of the same length, two different framings are adopted, in particular the Type B waveform uses a framing similar in composition to that of STANAG-4285. 

 

Fig. 3 - constellation and bitmaps of the PSK8 Serial Tone waveform

It is important to note both in the bitmaps of Figure 3 and in the demodulated bistream of Figure 4 (related to the Type A waveform) the presence of "regular" and similar patterns, as well as the "invariance" of the symbols of the synchronization sequences. In my opinion such patterns and sequences could indicate the use of a uncoded mode and even no interleaving (or 1 frame length interleaver), furthermore the length of the scrambler should coincide with that of the frame (256 symbols) or at least it should be initialized at the beginning of each frame (2).

Fig. 4 - PSK8 ST type "A" waveform: demodulated bitstream

Examining the symbols of the synchronization sequences offers further food for thought. In Type A waveform, the use of PSK2 modulation is confirmed by the 2-state transitions in the sync sequence, the latter consisting of a pseudorandom sequence of 31 symbols that is repeated twice for a total of 62 symbols (Figure 5).

 

Fig. 5 - sync sequence symbols, PSK8 type "A" waveform

Two state-transitions are also visible in the sync sequence of Type B waveform (Figure 6). Given its similarity to the S-4285 framing, the synchronization sequence consists of 80 symbols and it too is a pseudorandom sequence of length 31, which is repeated periodically within the 80-symbol window (2 periods of length 31 plus the first 18 symbols of another period).

Fig. 6 - sync sequence symbols, PSK8 type "B" waveform

The most interesting thing, apart from the state values which may be due to both the scrambler and the the possible phase-offset errors of the SA PSK demodulator (3), is that both the two Types of waveforms use the same 31-symbol sync sequence: indeed, as can be seen in Figure 7, the 2-state transitions are the same. Perhaps the length of the sync sequence is used by the receiving modem to figure out which of the two waveforms is incoming, but it's just a my guess.

Fig. 7 - sync sequence symbols, PSK8 type "B" and "A" waveforms

Since the Type B waveform has the same framing as S-4285, an S-4285 decoder recognizes the Type B waveform samples (100% confidence) but since the synchronization sequences are different (see the 2-state transitions in Figure 8) it does not successfully engage any sub-modes.

 

Fig. 8 - comparison between sync sequences of PSK8 Type "B"  and STANAG-4285

STANAG-4539
As per STANAG-4539, both the QAM16 and PSK8 waveforms have the same 287-symbol framing (119.6ms ACF, 2400Bd) although the user data rate is different: 6400bps and 3200bps respectively for QAM16 and PSK8.

Fig. 9 - constellations and bitmaps of STANAG-4539 QAM16 and PSK8 waveforms

If in the case of PSK8 ST it was only possible to analyze the symbols after demodulation, in the case of STANAG-4539 it is possible to decode the signals and then analyze the composition of the upper layer datalink protocol(s).
Figure 10 shows a detail of a bitstream obtained after removing the S-4539 QAM16 overhead and consists of 96-byte (768 bits) Protocol Data Units (PDUs), each PDU consisting of 3 bytes header followed by 93 bytes of data:
1st byte: a ID/value field, in this sample: 0x09 (LSB first)
2nd byte: down-counter field (LSB first)
3rd byte: up-counter field (LSB first)
As one can see looking at the values of the two counters in Figure 10, the sample consists of 55 PDUs, numbered from 0 (00000000) to 54 (00110110).

Fig. 10 - headers and part fo bitstream after S-4539 QAM16 decoding

 

The same fields' structure can be found in the PDUs extracted from a sample of STANAG-4539 PSK8 (Figure 11). Since the half of the user data rate (3200bps Vs 6400bps), each PDU consists of 48 bytes: 3 bytes for the header fields followed by 45 bytes of data. It's interesting to see that a change in the first field (from 01001000 (36) to 00001000 (8)) occurs when the down-counter field restarts its value after reaching the 0: curiously, the up-counter does not "reset" but continues its counting.
It's worth noting that that patterns highlighted in the bitstream of Figure 4 (and the bitmaps of Figure 3) are most likely the two counter fields of Figure 11: if so, both tPSK8 ST and S-4539 traffic waveform transport the same datalink PDUs.

 

Fig. 11 - headers and part fo bitstream after S-4539 PSK8 decoding

 

Even more interesting. After removing the 3 bytes of the headers, I reshaped the stream into a 128 bit scheme (16 bytes), i.e. to the most probable value of its period, and I noticed the repetition of the string 0x3CF04F; so I synced the stream on this value (Figure 12), fixing a minimum length of 128 bits. The result highlights the presence of 45 PDUs of a "secondary" datalink protocol where each PDU has an header consisting of 4 bytes and a minimum length of 16 bytes (128 bits), the maximum is over 600 bytes (I was not able to establish it accurately):
bytes 1-3: a ID/value field, [001111001111000001001111] 0x3CF04 (LSB first)
4th byte: up-counter field (LSB first)

 

Fig. 12 - the emerging "secondary" datalink protocol PDUs

This may be a hasty statement, but it seems that the "secondary" datalink protocol PDUs > 16 bytes length are fragmented into small segments and then incapsulated into the 45/95 bytes payload of the "primary" datalink protocol PDUs. By the way, at least in these samples, the "secondary" PDUs have been found only in the primary PDUs which have the first byte of the hedaer equal to 0x48, maybe just a mere coincidence (Figure 13,14).

Fig. 13

Fig. 14

comments
Since the lack of clear-text callsigns it's impossible to id the user, we may speculate just some guess about the manufacturer of the used devices:

 

- as far as I know both Thales and L3Harris make use of the GMSK-MFSK8 waveform to manage HF links: unfortunately the GMFSK signals portions are too short to allow the analysis of the bitmaps (L3Harris GMFSK has a well recognizable pattern [1]);

L3Harris typical pattern in GMFSK-MFSK8 signals

- the patterns highlighted in Figures 3,4 are very similar to the ones visible in the demodulated bitmaps of PSK8 Voice Digital waveform (L3Harris VD mode) [2];

L3Harris VD mode bitstream

- from Harris RF-5800 datasheet "L3Harris VD mode also allows data to be sent...both data and voice are secured with Citadel encryption" [2]: well, I did not find the Citadel characteristic pattern within the decoded bitstream, even if they could be plain-text transmissions.

 

So: Thales? L3Harris? either of them? ...hints and comments are welcome.

(to be continued)

 

https://disk.yandex.com/d/tMk8PwVw1gu8dg 

 

(1)50Hz difference between 1800Hz sub-carriers

 

(2) FEC encoding and interleaving should provide time separation between contiguous values.

(3) SA is a signal analyzer and not a decoder, therefore its phase-plane demodulator does not sync  any particular protocol, as it happens for example in STANAG-4285 "suited" decoders. Working with phase keyed signals, the SA phane-plane demodulator produces right interpretations and views (number of phases, angles, modulation speed, carrier frequency,...) but it may return wrong demodulated streams due to the possible phase-offset errors.

 

[1] http://i56578-swl.blogspot.com/2015/06/harris-selective-call-msk-2000bd1000.html
[2] http://i56578-swl.blogspot.com/2021/11/harris-rf-5800-digital-voice-psk8.html

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