STANAG-4538 to forward 188-220 App.D (SINCGARS) Tx frames to HF

6898 KHz/USB seems to be a good place to catch transmissions which deal with STANAG-4538 3G-HF and COMSEC. After the 256-bit Initialization Vectors encryption, it happened to hear some STANAG-4538 transmissions that used the LDL protocol: nothing particularly interesting except for the transported datagrams that are certainly attributable to SINCGARS traffic which is usually exchanged, however, between 30 and 88 MHz! Indeed, after the analysis of the LDL bitstreams, it turned out that MIL 188-220 App. D "COMMUNICATIONS SECURITY STANDARDS" (shortly idicated as 188-220/D) exactly describes the structure of the transmitted datagrams.
In short, SINCGARS (Single Channel Ground and Airborne Radio System) [1] is a VHF Combat Net Radio (CNR) [2] WF providing secure voice and data communications; MIL 188-220 [3] is a military standard that governs the use of Combat Net Radios and covers layers 1 through 3 (physical, data link, and network) of the OSI stack.

Fig.1 - STANAG-4538 LDL session

LDL protocol analysys
Each LDLn transfer consists of a TX Frame consisting of one data packet. A data packet is defined as a fixed-length sequence of n-byte data (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused), both added by the LDL protocol. Each TX Frame is sent using burst waveform BW3. During the construction of BW3, a 32-bit CRC is computed across the data bits of each data packet and is then appended to it. Then, 7 flush bits having the value 0 are added to ensure that the encoder is in the all-zero state upon encoding the last flush bit. Sumarizing, the on-air LDLn bits are equal to 8n + (17+8+32+7)  or  8n + 64 (n  =  32,64,96,...,512).

That said, we can go back to the original datagram by inspecting the last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits) of the four BW3 bursts (Figure 2). In this sample the values of the Packet Number fields are: 0,0,1,1: most likely, each TX Frame is sent twice to improve the reliability of the transfer (the receive station discards the duplicated packets). Correspondly, the values of the single Packet Byte Count fileds are 415 (110011111) and 346 (101011010): this means that LDL416 protocol is used and therefore the original datagram was splitted into two packets each of 416 and 347 bytes (the Packet Byte Count field contains the number of user bytes -1). 

Fig. 2 - LDL overhead bits

Datagram analysis
The original datagram can be retrieved by reshaping the bitstream in a 3392-bit period (ie (8 × 416) + 64),  isolating the four rows, removing either the duplicated packets and the 64 overhead bits: the resulting bitstream is shown in Figure 3.

Fig. 3 - the original 15-bit period datagram

As said, 188-220/D exactly describes the regular patterns which compose the datagram, particularly the COMSEC preamble field that consist of three components: the bit synchronization subfield (it may consists of a string of alternating ones and zeros), the Frame Synchronization subfield, and a Message Indicator (or Initialization Vector, IV) subfield (Figure 4).

Fig. 4 - traditional COMSEC transmission frame structure (MIL 188-220 App.D)

As per 188-220/D #D.5.1.1.2, frame sync subfield, and Message Indicator are encoded using Phi patterns, a method of redundantly encoding data bits :

a logical "1" data bit is encoded as a Phi(1) = 111101011001000
a logical "0" data bit is encoded as a Phi(0) = 000010100110111

A simple majority voting process may be performed at the receiver to decode the Phi-encoded patterns to their origlnal format. 

 

It's to notice that the Phi patterns are generated by the polynomial x^4+x+1 [initial state 1,1,1,1]: this could be misleading if you are looking for a suitable descrambler for the preamble.

I extracted the original datagrams from three STANAG-4538 transmissions heard on 6898 KHz, removed the initial (long) bit sync subfields and placed the bitstreams side by side for better visibility of the COMSEC Frame Sync and IV subfields (Figure 5).

 

Fig. 5 - COMSEC preambles

As you see the Frame Sync subfield is the same in the three datagrams, this subfield is 465 bits long and consists of 31 Phi-encoded bits (as per 188-220/D): 

 

01) 111101011001000 → 1
02) 111101011001000 → 1

03) 111101011001000 → 1 

...

29) 111101011001000 → 1

30) 111101011001000 → 1
31) 000010100110111 → 0 

 

As expected, the pattern resulting after Phi-decoding matches exactly the one reported in 188-220/D:

 

1111111111111111111111111111110

 

The Initialization Vector subfield, a stream of random bits, is redundantly encoded using Phi patterns and is 1305 bits long (87 Phi-encoded bits) in all the three datagrams:

 

01001101001000000010001010110011110110110011

0111010010000110001011111010001111101000011
 

11100011100001100011110000110000101100111111

1100101101010111010101011111110100000000011

11101011101000001110101100100000000001001100

0110101100101010101001001010110101110010001

 

The ecrypted data block follows the Initialization Vector subfield, the external crypto device is presumably KY-57 [4] or the more advanced KY-99.

 

The same frame structure, and the same subfields lengths, was found in

- SINCGARS transmissions heard on 33 MHz (low VHF, GFSK 16000 Baud) (Figure 6)

- SATCOM transmission heard on 261.5 MHz (UHF, FM 16000 Baud) [5]

Fig. 6 - frame structure of a SINCGARS transmission

 

i.e. just where do you expect to find it (V/UHF).

 

Conclusions are hard to draw from such observations: since the LDL packets transport whole 188-220/D frames "as is", STANAG-4538 appears to be used as a kind of "bridge or relay" between V/UHF and HF (Figure 7).

 

Fig. 7

 

It sounds quite weird and unusual but however this is what was on-air. What is it, then? 

Since this type of transmission occurred several times and for some days, I tend to exclude that it was an operator mistake or a malfunction of the equipment: both would have been noticed and perhaps fixed. Maybe some kind of tests? Anyway, I find it difficult to think that such a mix is possible by using a "traditional" setup. Indeed, I think that using a SCA-based Software Defined Radio a skilled operator could instantiate a 188-220/D + S4538 session, but... why? Using a such SDRs configuration would be possible outrun the transmission range of (VHF line-of-sight) SINCGARS, but honestly such a solution seems rather crude and impractical. Maybe it was just occasional needs to forward 188-220/D frames to a certain HF endpoint.

In conclusion, at present I don't have a clear explanation and comments will be greatly appreciated. For completeness, it should be added that in these days I have tried some sporadic monitoring but I have not been able to hear these transmissions anymore (at least on 6898 KHz).

 

A big thank to my friend KC9FFV Marco (Forney, TX USA) who allowed me to use his KiwiSDR beyond the 120 minute time limit [6].
 

 

https://yadi.sk/d/uXodd0sc6oiLLw 

 

[1] https://en.wikipedia.org/wiki/SINCGARS

[2] https://en.wikipedia.org/wiki/Combat-net_radio

[3] https://yadi.sk/i/pauZfUz63Nxs-g

[4] https://www.cryptomuseum.com/crypto/usa/ky57/

[5] http://www.radioscanner.ru/forum/../msg335301

[6] http://marcocam.selfip.com:8073