27 April 2023

Thales mixed-mode traffic

Just a couple of comments about the different waveforms that can be seen when analyzing traffic exchanges performed using Thales equipment. 

1. As you see in Figure 1, after the proprietary Systeme-3000 Skymaster ALE, data are transferred using STANAG-4285 FEC and the HDR Single Tone waveforms (both proprietary) and even STANAG-4539. That's a bit unusual since, once link negotiation is complete, the  selected traffic waveform shall remain the same during that link session (apart FEC coding, interleaver and data rate).

Fig. 1

The order in which the different waveforms appear does not seem "formalised", probably it's due to the adaptive feature of the modem - which therefore adopts different data rates and waveforms - or it's in some way "announced" during the link negotiation. In this regard, the "dual demodulation state" comes to mind, a characteristic of 3G-ALE indicated in STANAG-4538: ie, the nodes partecipating in packet data type links do not expect a same waveform and are ready to demodulate  specific xDL waveforms. Looking at Figures 1,2, it seems that shall nodes be required to simultaneously demodulate at most four waveforms within the same logical link, ie they look for STANAG-4285 FEC and HDR ST (Thales proprietary) or NATO STANAG-4539, and obviously the ALE waveform signaling the link terminate. I don't know how this happens but I would guess the ALE phase announces what waveforms will be used.

Fig. 2

2. As from STANAG-4539 #, the synchronisation preamble consists of two parts. The first part consists of at least N blocks of 184 8-PSK symbols to be used exclusively for radio and modem AGC (also known as TLC section). The value of N is configurable to range from values of 0 to 7. The second section consists of 287 symbols. The first 184 symbols are intended exclusively for synchronisation and Doppler offset removal purposes while the final 103 symbols also carry information regarding the data rate and interleaver settings. The total duration of the sync preamble as a function of the number N is shown in Table I.

Table I - sync preamble duration Vs N (at 2400 Bd)

In all the recordings at my disposal I noticed the same duration of the synchronisation preamble, i.e. 349.5 msec which correspond to N = 3 or three 184 symbols blocks for the TLC section (Figure 3): this - of course - is just a mere common peculiarity but which at least so far has not been denied in similar recordings (Thales). Other S4539 recordings I have analyzed have different preamble sync lengths. As specified above, the value of N is configurable, however it is not clear if this parameter is accessible to the operator or if it is a factory setting (however modifiable).

Fig. 3 - some Thales STANAG-4539 synchronisation preambles

Thales engineers certainly have the ability to modify the STANAG-4539 preamble, as in the case of the extended preamble employed in their Salamandre HFXL waveforms, however even military grade modems such as the Harris RF-5710A are able to recognize and demodulate these S4539 bursts, assuming that the data rate and interleaver settings values that are "read" by the modem are actually the exact ones

Fig. 4 - my Harris RF-5710A working Thales mixed-mode recordings

Such further recordings and comments are very welcome.


18 April 2023

LDL 139-byte packets

For a few days I have been following the 3G traffic that takes place on 6682.0 KHz/USB and I have noticed that many of the transfers are exactly the same length (139 bytes) and follow the same sending formality, ie the protocol used is LDL (3G-HF STANAG-4538) and are retransmitted twice within the same link session.

Fig. 1

The caller node issues a 2-way FLSU_Request Protocol Data Unit (PDU) which conveys the caller node address,  priority, and the desired traffic service (packet or circuit mode). The called node responds with a FLSU_Confirm PDU, indicating the ability to continue with the requested traffic service. As it's known, FLSU protocol use the BW5 waveform.
Both the caller and called alternate sending LDL PDUs, with the caller sending data using the LDL Data Send PDU (BW3), and the called responding with the LDL ACK/NAK PDU (BW4).  This process continues until all data has been transferred error-free, as indicated by the caller sending redundant LDL End Of Message (EOM) PDU’s. Immediately after the LDL transfer is complete, both stations iunitiate the Fast Traffic Management (FTM) protocol to negotiate further traffic. This gives the called node an opportunity to send data in the reverse direction. After a the Link Timeout has occurred, the last station to receive an LDL transfer terminates the link by sending an FLSU_Term PDU. It's worth noting that after the EOM PDUs, both nodes remain linked (!) and given that the caller has already completed its data transfer, it is up to the called node to deliver any packet traffic it has, or to terminate the link if it doesn't have traffic to send. Note that:
- the EOM PDU indicates to the receiving station that the data transfer will be terminated;
- the Term PDU indicates to the receiving station the sender’s departure from the current link.
in EMCON scenarios the link termination is up to the caller node

Fig. 2

In these recordings, packet-mode service and LDL160 protocol are used. Before analyzing the bitstreams let's see how an LDL packet is built.
The "original" datagram to be sent is split into fixed-length segments which will be processed into packets by the chosen LDL protocol. An LDL data packet is defined as a fixed-length sequence of n-byte data segment (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused). During the construction of the LDL BW3, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the  data bits of each data packet and then appended. 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 length of a LDLn burst is computed in bit as 8n + 64 (n = 32,64,96,...,512 bit), in this case (LDL160, n = 160) 1334 bit or 168 bytes.
That said, lt's go back to two decoded LDL packets (belonging to the same link session) by inspecting their last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits):

Fig. 3

Let's try to analyze the 139 bytes messages. As indicated by the value of the bits 5-0 (all 0s, Packet Number #0) and SOM/EOM bits (all 1s) the original datagram consists of only one packet, the Packet Byte Count field (bits 14-6) indicates that the user bytes are 139 thus the remaining 21 bytes are filled with 0s.


The analysis of the bitstreams shows that each datagram is always sent twice (Figs 4,5): I don't know if it's due to a negative ACK sent back by the reiceiver or rather a usual way of doing to give redundancy and reliability to the system.

Fig. 4
Fig. 5

After the removal of the 31-byte encapsulation added by the Harris "Citadel" cripyographic engine

00 00 00 00 01 01 2D 1E 56 1E 56 1E 56 1E 00 1A 5D 1A 5D 1A 5D 1A 5D (header)
1E 56 1E 56 1E 56 1E 02 (tail)

the resulting datagrams consist of 108 bytes. Such messages are very frequent(!), also sent using the circuit-mode service and MS-110A as traffic waveform. Sometimes it's occured to see that the 139-byte encrypted message is split into five packets and then sent using LDL32 [1] or even 9 times repeated using LDL160 [2], as shown in the Sequence Number fields in Figure 6

Fig. 6


[1] https://yadi.sk/d/PvOS5FbM3H96Wz
[2] https://yadi.sk/d/_SCU3U073GzPf9