CIS MFSK-33 (here:15+∅+17), likely a "Serdolik" multimode waveform

Fig. 1 - "Serdolik" multimode waveform

The MFSK segments have the usual 40Bd and 40Hz (channels separation) values which are typical of the Serdolik waveforms family: a long-range radio system used by the Russian and CIS countries Diplomatic Service, possibly Serdolik V2. It's worth noting in Figure 2 - at least in this sample - that although the system provides a 33 channels grid, only 32 are the effective (used) ones: specifically, the first 15 lower channels plus the 17 higher ones (the 16th channel is not used).

Fig. 2 - MFSK segments

The FSK inserts too have usual Serdolik values, ie 40Bd/680Hz in this sample, and consist of short "01"s sequences (Figure 3).

Fig. 3 - FSK segments

This sample has been recorded on 20.8155 MHz/USB using a remote AirSpy server located in UK.

CIS MFSK-33 waveform is not the only one that does not always use all the available channels of the frequency grid: CIS MFSK-34 (aka Crowd-36) is another example in this regard (Figure 4).

Fig. 4 - frequency grid of some CIS MFSK-34 samples

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

3G-HF Fast Traffic Manager (FTM) at work

This sample provides an example of the use of 3G-HF (STANAG-4538) Fast Traffic Manager (FTM) protocol, which is sometimes referred to as simply FLSU (Fast Link SetUp). More precisely, FLSU is used to set up links, and it includes the traffic type that will be used immediately after the link set up is complete; FTM is used after the FLSU for cases in which the traffic type needs to be changed, or to negotiate channel access among linked stations.
As stated in S-4538 Annex-C Edition1 Amendment2, if a link has been established for delivery of packet traffic using the HDL+ data link protocol (BW7), all FTM and FLSU Protocol Data Units (PDUs) transmitted for the remaining duration of the packet link shall be transmitted using the BW6 burst waveform: thus, since the use of BW6, the link was initialized for HDL+ protocol. But, as you can see in Figure 1, at some point an FTM negotiation causes the change of the traffic type: from HDL+  (BW7 waveform) to LDL (BW3 waveform).

Fig. 1 - traffic type change

It's worth noting the use of BW4 waveform bursts after LDL data delivery, it's requested by the #4.6.5 Dual Demodulation condition: "Under no circumstances shall stations be required to simultaneously demodulate more than two waveforms. Any scenario requiring more than dual-demodulation is either an error in the specification or an error in interpretation" (1).

 
By the way, the BW3 burst transports a L3Harris "Citadel" encrypted message (Figure 2).

Fig. 3

https://disk.yandex.com/d/YCupV-cFBXOmqQ

(1) HDL+ states is missing in the Table 4.6.5-1: however, since BW6 burst waveform is used for Ack/EOM/Term messages, Master and Slave stations expect to receive a BW6 or a BW7 waveform.

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

KW-46 secured fleet broadcast over S-4285 in ISB mode (Humpty Doo, MHFCS)

Interesting fleet broadcast from the MHFCS (Modernised High Frequency Communications System) site in Humpty Doo, Northern Territory - Australia. The transmissions use STANAG-4285 600bps/L in ISB mode and are audible on 11145.0 KHz (Figure 1).

Fig. 1

Bitstream of the LSB channel (Figure 2) is a "classic" broadcast which is encrypted using KW-46 (or compatible) cipher device given the presence of the m-sequence generated by the polinomyal x^31 + x^3 +1 (KW-46T uses that M-sequences to synch the KW-46R receive devices).

Fig. 2 - bitstream of the LSB channel

The bitstream of the USB channel is more interesting since it consists of 12-bit strings where all the bits have the same logical value, likely originated by the GA-205 12-channel time division multiplexer: I already met such signal some years ago [1] but that time from the "Naval Communication Station Harold E. Holt" (NCS HEH) 6 km north of Exmouth. USB channel too transports a KW-46 secured traffic: as shown in Figure 3, I filtered out 11 channels and reshaped a single "column" into a 7-bit pattern then I successfully checked the presence of the x^31 + x^3 +1 m-sequence.

Fig. 3 - bitstream of the USB channel

As said, in this case the transmission is source by a Tx located in Humpty Doo, Northern Territory Australia.

Fig. 4 - DirectionFinding results (TDoA algorithm)

 

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

[1] http://i56578-swl.blogspot.com/2019/05/kw-46kiv-7m-secured-fleet-broadcast.html

MIL 188-220 App.D (Combat Net Radio) compliant transmissions in HF band

MIL-STD 188-220 suite (here indicated as MS-220D) was developed to meet the requirements for mobile Combat Net Radios (CNR) such as SINCGARS (Single Ground and Airborne Radio System) or more recent JTRS (Joint Tactical Radio System). The radios can handle voice and data communication, both secure and non-secure. SINCGARS radios work in the lower VHF band (30 to 88 MHz), with 25 kHz channel spacing and can operate on a single channel as well as in Frequency Hopping mode (FH). It's therefore rather rare to find transmissions in HF that use this protocol suite, especially in the low HF band (7 MHz)... but it may happen. Indeed, I was lucky enough to catch such transmissions on the same day (1030Z and 1058Z) on 7510 KHz/U (and it's not the first time it occurs).
The transmissions under consideration (Figure 1) are in STANAG-4538 "circuit service" mode, where link setup is performed by FLSU request/confirm exchanges (BW5 bursts) and MIL-STD 188-110A is the used traffic waveform.

Fig. 1 - STANAG-4538 Circuit Service mode

Appendix D of of MIL-STD-188-220 regards Communications Security Standards (COMSEC) and describes the requirements of the transmission frame structure when link encryption is provided by "external COMSEC" (traditional COMSEC) or by "embedded COMSEC" devices. The demodulated bitstreams perfectly fit the COMSEC preamble for external COMSEC (Figs. 2,3), ie when link encryption is provided by external devices.

Fig. 2 - Traditional COMSEC transmission frame structure (FIGURE D-1, MS-220D)

Fig. 3 - The COMSEC preambles of the demodulated bitstreams

Bit Synchronization subfield is used to provide a signal for achieving bit synchronization and for indicating activity on a data link to the receiver.  The  subfield consists of the data-rate clock signal, a string of alternating ones and zeros.

Frame Synchronization subfield is used to provide a framing signal indicating the start of the encoded MI (Message Indicator) to the receiving station. As for MS-220D "this subfield shall be 465 bits long, consisting of 31 Phi-encoded bits (1 encoded bit = 15 bits). The Phi patterns are a method of redundantly encoding data bits, a logical 1 data bit shall be encoded as Phi(l)=111101011001000, and logical 0 data bit shall be encoded as Phi(0)=000010100110111. A simple majority voting process may be performed at the receiver to decode the Phi-encoded frame pattern to its original format". Figure 4 shows the Frame Sync subfield of the demodulated bitstreams: as one can easily verify, the Phi-decoded content matches perfectly the sync pattern indicated in Figure D.2 of MS-220D (#D.5.1.1.2). 

Fig. 4 - Phi-encoded frame sync

Message Indicator subfield contais the COMSEC-provided MI (or Initialization Vector), a stream of 87 random bits that are redundantly encoded using the Phi patterns seen above. Cryptographic synchronization is achieved when the receiver acquires the correct MI. Decoding can be easily achieved (Figure 5).

Fig. 5 - Message Indicator subfield

Since the COMSEC preambles of the analyzed bitstreams match the "external COMSEC" frame structure, likely the encrypted parts (voice/data) are secured by an external crypto unit such as the KY-57 (Vinson) or the more advanced KY-99.
Such uncommon (in HF band) transmissions are maybe a forward from a VHF link, who knows.

https://disk.yandex.com/d/-_3GnxUV_XKN9Q