Harris' 3G-ALE FLSU Async call: a 141B/STANAG-4538 optimised implementation?

I recently had the chance to study some good quality recordings of (certified) Harris 3G-ALE Asynchronous calls and surprisingly I found some features of implementation derived from the now superseded 188-141B that are not defined - or even not supported - by the relevant standard STANAG-4538.

More than once I came across such type of "long duration" FLSU bursts and so far I have always identified them as FLSU Asynchronous calls (STANAG-4538) [1][2] ...but this time it is not like that. What doesn't fit is that while each burst 2-4-6 consists of a single FLSU BW5 PDU (Protocol Data Unit), as expected, also the bursts 1-3-5, although of longer duration, seem apparently formed of single FLSU BW5 PDUs (figure 1).

Fig. 1 - Harris 3G-ALE bursts

A short recap for background... 

As per STANAG-4538 #5.1.3, the Asynchronous call consists of a "sequence" of FLSU PDUs sent consecutively, more precisely:
"The Asynchronous call begins with the LBT [...] followed by the transmission of about 1.35N Async FLSU_Request PDUs on the requested link frequency, where N is the number of channels in the scan list, and 1.35 is the duration of each dwell (in seconds) [...] the sequences of the Async FLSU_Requests (Type-3 PDU) is then terminated by one normal FLSU_Request (Type-0 PDU)"(1):

Fig. 2 - Asynchronous FLSU call (1) (FIGURE 5.1.10-4 STANAG-4538)

Therefore, the Async FLSU call is easily reacognizable by the 1013ms "spikes" (ie the duration of the BW5 PDU) resulting from its Cross-Correlation Function. Obviously, the 7296-bit (or 2432-tribit symbols) period of the bitstream matches the PSK8 symbols of the BW5 waveform. Figure 3 shows the CCF and the bitstream of an Async call recording ( the .wav file is in the download list).

Fig. 3 - CCF and bitstream of the FLSU Async call

The 50-bit frames resulting from its demodulation (fortunately Linking Protection was not used) are consistent with the standard protocol. By the way, since the 10 Type-3 PDUs, the scan list consists of 8 channels.

 

That said, let's back to the Harris 3G-ALE recordings.

The Cross-Correlation Function of bursts 1-3-5 shows strong ~906ms spikes instead of the expected 1013ms ones, consequently the demodulated bitstreams have a 6528-bit period length which in turn makes 2176 PSK8 symbols: so, we have  

 

(2432 - 2176) = 256 missing symbols

Fig. 4 - CCF and bitstream of the Harris FLSU Async call

Looking at the BW5 timing, the initial TLC section consists of 256 PSK8 symbols: well, these are exactly the symbols that we are looking for! 

I mean that the TLC section is sent only in the first BW5 PDU thus the following ones are a bit shorter being composed of only the preamble and data sections: hence the (576 + 1600) = 2176 symbol length period and the ~906ms CCF spikes. This "formation" of the Async call also clarifies why my decoder recognizes only the "first" BW5 PDU (figure 1). By the way, the value 

1013.33 + (5 × 906.66) = 5546.63ms 

fits perfectly in Harris recordings.

Fig. 5 - formation of the Harris FLSU Async call

Such a 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 Ttlc (used for transmitter level control and receiver AGC settling). All succeeding LE_Scanning_Call PDUs and the LE_Call PDU shall omit Ttlc, and include only the BW0 preamble (Tpre) and data (Tdata) portions".(2)(3)

So, we face 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. Below I have tried to find a satisfactory answer to this "particular" 3G-ALE call.

For simplicity and clarity of exposition, for now on I will refer to:
- "188-141B" as an FLSU Async call with omitted TLC sections (only the firts one is sent);
- "STANAG-4538" as an FLSU Async call w/out the omission of the TLC sections;
the FLSU protocol obviously implies the use of BW5 PDUs.

One could say that, given the nature of the TLC section (basically 256 throwaway symbols), sending it in a sequence of contiguous BW5 PDUs would makes a poor sense... but that's not entirely true. It is possible to verify that, starting from a certain number of channels onwards, the TLC sections act as a "buffer" and, ultimately, allow a successfully link establishment. Indeed, defining "scan time" the interval of time required for scan N-1 channels, linking is successful as long as the scan time does not exceed the duration of the Async call (figure 6).

Fig. 6 - "scan time" Vs Async call duration

Suppose we have a 21 channel network: the worst case that can happen is that a 141B async caller begins a call on the last channel of the scan list (after a successful Listen Before Transmit interval) while the called station has just begun to dwell on the first channel. Let's calculate how many PDUs must be sent in the call:

1.35 × 21 = 28.35 ≅ 28 Async FLSU_Request PDUs + 1 normal FLSU_Request PDU

for a total duration of (including the initial 1350 milliseconds LBT interval):

1350 + 106.66 + (906.66 × 29) = 27749.8 ms.

The called station will employ (20 x 1350) = 27000 ms to come upon channel 21, so it will receive only a portion of  (27750 - 27000) = 750 ms of the Async call: this means that a part of the acquisition preamble of the final FLSU_Request will be lost and presumably the linking attempt will fail or at least will be at risk. Such a problem will not happen in case of a STANAG-4538 async caller, since its call will last:

1350 + (1013.33 × 29) = 30736.57 ms

therefore the called station will receive a quite large portion of about (30736.57 - 27000) = 3736.57 ms of the Async call (ie more than 3 times the duration of a BW5 FLSU PDU).(4)

I plotted the durations of Async calls and scan times versus a scan list of 5 to 30 channels: the results are quite interesting (figure 7). In case of 141B, starting from channel 16 the distance between the duration of the call and the scan time is getting thinner, until it becomes null or even negative. STANAG-4538 implementation instead maintains a quite wide margin (figures 7a). Then I plotted the the difference (async call duration - scan time) referred to the "useful" duration of a BW5 PDU ( 906.66ms, ie preamble + data): say a sort of measure of the "linking useful margin" versus the number of channels. In case of 141B calls, as expected, the linking gets problematic starting from a 16-channel scan list (figure 7b); no problems in case of S4538 calls (figure 7c).

Fig. 7

Well, how many channels can be allocated to a scan list? Looking at the framing of BW5, the "Argument 1" field reserves 6 bit for the channel; excluding the default value ("111111"), 63 values (0...62) remain available. As it was already evident from figure 7, a 141B Async call does not capture the called station in case of such a large number of channels but - conversely - it's best performing then STANAG-4538 in a network with a smaller scan set (number of channels < 17) just because it has a shorter call duration and therefore a faster linking time (figure 8).

Fig. 8

Probably the Harris' choice of omitting the exceeding TLCs just lies in the fact of better performance in small scan lists (say an "optimised" implementation): perhaps a specific algorithm chooses whether or not to omit the TLCs exceeding the first, or perhaps it's a manual setting. That solution is anyway not compatible with the 188-141B implementation (BW5 is unknown to that standard) and probably also with a "strict" implementation of STANAG-4538: the unanswered calls in figure 1 could be a sign of interoperabilty problems (5), who knows. Judging by the behavior of my decoder, however, I verified that in case of a "late entry" the decoding is successfully only when the Async call contains multiple TLCs: but it's just a decoder, I don't know the algorithm it uses and doesn't matter. Unfortunately I don't have a military grade STANAG-4538 appliance to test its responses, so further analysis are needed to confirm my guess.

I want to thank my friend ANgazu who helped in the analysis and identification of the signal and sent me some recordings of these "mixed" Async calls that he heard just some days ago around 6950 KHz: sign that this solution is still in use today.

https://disk.yandex.com/d/xbGLZvU5y5A1Qg 188-141B FLSU Async call (single TLC)
https://disk.yandex.com/d/gXsMejYAvHFstA   S4538 FLSU Async call (multiple TLCs)
(regarding the Harris recordings, the author prefers that I keep this material confidential)

Some ending comments:

a) I played Lego ® bricks with the burst #1 of the Harris recordings. Using the great tool Audacity ® [3] First I isolated and removed the TLC section of the first BW5, then I did my best by cutting the burst into segments each of 906.66 ms duration. Then I assembled a new burst by inserting the TLC section before each segment and putting it all together. The result confirms the expectations, apart from two error PDUs due to the approximate way of the cut & paste. By the way, five scanning PDUs mean 4 channels in the scan list.

b) You've probably noticed the possibility of a 768-bit/256-symbol period in figure 4:

 

As per STANAG.4538 #13.9.6, the BW5 PDU data symbols are PN-spread using a spreading sequence which is repeated every 4 blocks of 64 tribit sequences, ie every (64×4) = 256 symbols: these repetitions cause the 106.66ms ACF and hence the 256-symbol periodicity:

 By the way, yet another 106.66ms ACF...

(1) Transmitting 1.35N Async FLSU_Request PDUs guarantees that all other scanning PUs (Partecipating Units, ie the other nodes in the HF network) will scan the calling channel during the Async call, even under the worst case time of day offset conditions. If the time of day offset can be estimated more accurately, fewer than 1.35N Async FLSU_Request PDUs may be sent to capture the desired PU. Since the address of the called PU(s) is contained in the Async FLSU_Req PDU, all PUs that are not included in the call are free to resume scanning. Called PU(s) that receive one of the Async FLSU PDU’s stop scanning and wait for the normal FLSU_Request.

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

(3) 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".

(4) The Called station that receive one of the asynchronous FLSU PDUs stop scanning and wait for the normal FLSU_Request PDU, which is sent immediately after the final Async_FLSU_Request PDU. After receiving a valid FLSU_Request PDU, the addressed stations responds normally with the FLSU_Confirm PDU (STANAG-4538 #5.1.3)

(5) The BW5 bursts 2-4-6 of figure 1 may convey the FLSU_Terminate link PDU (type-2) which is sent by the caller station in case of link failure (STANAG-4538 #5.1.5). Unfortunately, Linking Protection is used so the decoding does not help to indentify the used BW5 types.

[1] https://i56578-swl.blogspot.com/2019/10/async-flsu-followed-by-stanag-4197-3g.html
[2] https://i56578-swl.blogspot.com/2021/04/a-long-and-protected-flsu-async.html
[3] https://www.audacityteam.org/download/

Thales HDR Single Tone modem? (TRC-3600/3700 family)

 

I rcently spent a bit of time monitoring the data transfer sessions which frequently happen on 6478.0 KHz/usb in ARQ mode. As usual, transfers start with the link setup stage: the particular and distinguishable shape of the ALE burts makes it possible to identify the Thales Systeme-3000 Skymaster ALE. The initial part of the ALE burts is SDPSK (Symmerical Differential PSK) modulated at 2000 Baud speed with a carrier frequency of 1600 Hz; as you see, transitions do not traverse the origin and the information is stored in the transitions and not in the states (figure 1). The initial part is followed by short MFSK-8  125 Baud segment that is not compatible with MS 188-141 2G-ALE although the scope be the same (they use different tones library).

Fig. 1 - Systeme-3000 Skymaster ALE

The SDPSK part exhibits a 50ms ACF that corresponds to a 100-bit frame (figure 2)

Fig. 2

Data bursts are PSK-8 modulated at a symbol rate of 2400 Bd and exhibt a 106.6 msec ACF (corresponding to 256 symbols) but adopt diferent frame structures: likely it's due the the adaptive feature of the modem which therefore adopts different data rates and waveforms (figs 3,4).

Fig. 3

Fig. 4

The presence of the Systeme-3000 ALE bursts - and thus a Thales proprietary waveform - suggest that the 2440Bd/PSK8 waveforms (used for data) are sourced by the High Data Rate modem incorporated into the TRC-3600/3700 family of combat radios. Quoting TRC-3600 datasheet: "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 performances of the modem, the use of powerful error correction codes and the use of real time adaptive procedures enable to offer reliable HF links even on a severely degraded ionospheric path. The links are automatically optimized in real time according to the possibilities of the HF channel".

...and yes, yet another 106.6 ms ACF waveform.

 https://disk.yandex.com/d/GAB7inxTA7-QWw

Harris RF-5800 Digital Voice PSK8 serial waveform (yet another 106.6 ms ACF)

A friend of mine sent me these signals consisting of a complete session utilizing the Harris 600/2400 bps Digital Voice (DV) mode:

1- selcall & link setup
2- 600/2400 bps vocoder PSK segments
3- link terminate

Fig. 1 - Harris Digital Voice mode session

Selcall is quite clear:  it's an MSK/OQPSK modulation at 2000 Baud speed, followed by short MFSK-8 125 Baud in non-standard MS-188-141A fomat, ACF is 50 ms (100 bit) and the resulting bitstream is characterized by the presence of the usual pattern (figures 2a, 2b).

Fig. 2a - Harris selcall MSK/OQPSK part

Fig. 2b - Harris selcall MFSK segment part

The VD mode PSK8 serial waveform is used only when a voice link is selected, although it also allows data to be sent over the same link; both data and voice are secured with Citadel encryption. Its ACF is the quite common 106.6 ms and that causes false-positive STANAG-4285 detections by decoders. As shown in figures 3a 3b, each frame consists of 256 tribit symbols, according to SA raster and bitstream each frame consisting of 66 sync sequence symbols (instead of 80 as in other similar 106.6 ACF waveforms), followed by a data block consisting of 190 symbols. The sync sequence is transmitted recurrently every 106.6 ms and uses PSK2 modulation.

Fig. 3a - Harris VD PSK8 serial

Fig. 3b - Harris VD framing

From Harris RF-5800 datasheet: "The digital voice mode utilizes the latest military MELP and LPC-10 algorithms for high-quality secure narrowband voice at 2400 bps. The Harris 600 bps vocoders extend the communication range beyond conventional 2400 bps systems." [1]

About the 106.6 ms ACF waveforms (figure 4), as said here, it seems that decoders such as Sorcerer and therefore also K500 try to identify a signal by measuring its ACF and comparing it against an internal table that allows the identification: likely, the length of the ACF and the initial PSK2 sync sequence mislead the decoders which consequently give a false positive STANAG-4285 id.

Fig. 4 - some common 106.6 ms ACF waveforms

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

[1] https://disk.yandex.com/i/sFOl3aX98-d6SQ

 

Echotel 1810 and STANAG-4285, ie don't blindly trust decoders

It happened by chance to analyze a complete session of data exchange in MAHRS mode (ALE + traffic) while I had a STANAG-4285 decoder in active state on the desktop: to my surprise the decoder started printing out a bitstream though - as said - it was set for STANAG-4285 (Figure 1)

Fig. 1

Intrigued by that fact, I went to see the points that S4285 and MAHRS Echotel HF modem have in common enough to confuse the decoder, other than the obvious features such as speed (2400Bd) and modulation (PSK8).  

The first thing that stands out is the equality of the ACF values, Figure 2: 106.6 ms, or 256 symbols. Thus - in my opinion - it seems that the decoder in question (Sorcerer and therefore also K500) tries to identify a signal by analyzing its ACF: probably those kind of decoders have an internal table that allows this association.  

Fig. 2 - ACF values for STANAG-4285 and Echotel serial

The structure of the frames is anyway very different, unless the first 80-symbol preamble which is common to both the waveforms (Figure 3): S-4285 framing consists of an initial 80 symbol preamble followed by 4x32-symbols data segments and 3x16-symbol probes; Echotel framing consists of the initial 80 symbol preamble that is followed by a data block consisting of 176 data symbols. 

Fig. 3 - framing structure for STANAG-4285 and Echotel

As third common feature, both the 80-symbol preambles are modulated using BPSK: the pronounced BPSK states in the constellation plane of the Echotel 1810 signal are quite eloquent (Figure 4)

Fig. 4

STANAG-4285 is not an autobaud waveform so the decoding is based on the user settings, just for fun I played with some sub-modes even if - as obvious - the decoder can't find the expected known symbols (16-symbol probes). The best results, in terms of "confidence", were obtained by setting the bit rate to 2400 bps, obviously the corrections are equal to zero in the uncoded mode:

It must be said that this Echotel 1810 waveform is not the only S4285-like waveform, another example is the 2400Bd PSK-8 serial waveform from the THALES TRC-1752 modem (Thales Système 3000 family), although the latter is more properly defined as "variant".

Fig. 5 - THALES TRC-1752 STANAG-4285 variant

 

At the end, do not blindly trust decoders: they are not infallible and there is no magic wand; just open your wav files and analyze them.

Echotel-MAHRS 2400 serial

The so-colled Echotel MAHRS 2400 is a 2400Bd PSK-8 serial waveform with simmetical 2 x 8 pre-tones in respect of the 1800Hz carrier. The signal has strong 106.66ms ACF spikes (256 tribit symbols) due to its frame structure: an initial 80 symbol (240 bit) preamble that is followed by a data block consisting of 176 data symbols (528 bit). The pronouncec BPSK states in the constellation plane are due to the BPSK modulation of the preambles (Figure 2).

 

Fig. 1

Fig. 2

The waveform belongs to the Telefunken Racoms HF HRA 5100 radio communication, an ARQ-like system used in airborne platforms for air-to-air and air-to-ground comms. As far as is recoverable from the web, "MAHRS" (Multiple Adaptive HF Radio System) is the name of the HF radio-data standard originally developed by Telefunken, Arcotel is the radio processor and Echotel 1810 is the HF modem. The HRA 5100 system has been replaced by the more recent HRA 9100, both supplied by Elbit System (Figure 3).

Fig. 3

 

https://disk.yandex.com/d/x-bVsSFriyfJtg

STANAG-4285

STANAG 4285 is specified by the NATO (North Atlantic Treaty Organization) Military Agency for Standardization in "Characteristics of 1200 / 2400 / 3600 Bits per Second Single Tone Modulators / Demodulators for HF Radio Links" (16. February 1989).

Carrier frequency: 1800 Hz
Manipulation (n-ary): 8-ary PSK (+ BPSK modulated preamble)
Manipulation speed: 2400
Autocorrelation frequency (ACF): 106.7

Using different n-ary PSK modulations and FEC (Forward Error Correction) coding rates, serial binary user information (raw data, or payload) accepted at the line side input can be transmitted at different user data rates (measured in bps).

Most STANAG 4285 transmissions are originated from BRASS encrypted circuits that use encryption devices called "KG-84 Loop". These circuits send pseudo-encrypted data 24h/7 NOTWITHSTANDING from the signal that is applied to their input.

This here is 10568.2 IDN NCSA Naples running in sub-mode 600L on USB. As shown by decoder Sorcerer, it's clearly a random encrypted transmission

Let's have a look at the decoder phase-plane, since they use (at present) the submode 600L we expect to see a 2-PSK constellation:

The phase-plane might lead us to think that the signal is a 2-PSK... but it is not so: those are the raw-data transported by the signal (payload) and NOT the signal itself !

Well, go on analyzing that same SATANAG-4285 signal using the tool SA-Signals Analizer, from the great Serghei (RIP).

The signal has been isolated from noise and re-sampled at 8000 Hz

thought approximatively, we get a Baud Rate of 2400 and not 600 as declared by the our decoder (but remember that the decoder measures the data rate!).

Measuring the STANG-4285 ACF (Auto Correlation Frequency) we get a value of about 106.7 milliseconds, as expected (106.67); evidently the received signal or the recording are not so clear:

Below the results after running the SA phase-plane tool:

as expected, the constellation shows an 8-PSK signal (8-ary) running at 2400 baud, along with a 2-PSK payload, as shown by the decoder!

While SA do analyze, the decoder is just doing its job: it doesn't care about envelopes but just the messages inside: this is an important concept that you must have clear when you want to analyze a signal. Let's look at the STANAG-4285 ACF one more time. 

Measuring this parameter with SA analyzer we got 106.7 milliseconds, but what using a decoder? No problem, measuring the ACF using Code300-32 by Hoka we get the value of 32 bit for a STANAG-4285 signal:

 while, as seen above, SA shows an ACF of 106.7 msec for the same signal.

Why this difference? and what is the REAL value of the ACF, 32-bit or 106.67 msec ?

This happens just because the simple ACF function used in some decoders doesn't display the ACF of the decoded bitstream, but rather the repetitive pattern of the raw signal itself.  Let's have a look at the signal structure.

In STANAG-4285 an 80 symbol BPSK preamble is being inserted into the signal every frame (256 symbols) and that's what creates your pattern

1000ms/2400Bd = 0.4166667 ms per symbol for a 2400Bd system like S4285
256 symbols x 0.4166667 = 106.67 ms (so you have a repetition every 106.67 ms) 

The primitive "ACF" module of the decoder probably runs the raw signal (not the bitstream) against a 300 Bd display, which creates a pseudo ACF of 32 bits on a STANAG 4285 signal:

1000ms/300Bd = 3.33333 ms per symbol
32 bits x 3.33333ms = 106.67ms -> and there you have the 32 bit pseudo ACF created by the BPSK inserts every 256 symbols used in STANAG 4285.

Which just goes to show!

Below, an phase-plane example of a STANAG-4285 mode sending null traffic (all zeroes), it could be supposed as an idle mode (no chars was printed in the output screen of the decoder):

The majority of STANAG-4285 transmissions are encrypted BRASS circuits using loop encryption devices. These "cipher" devices in use today are mainly the BID1650 while the new NATO countries use R&S ELCRODAT. 

They will send pseudo random encrypted crypto traffic 24h a day - regardless of any input, the station will always send encrypted data as output. This output is in most cases synchronous, only in rare cases will you see asynchronous traffic on these BRASS circuits.Please remember that most stations use 600bps/Long, while there is a number of French and British nodes that use the submode 1200bps/Long. You can find out the right speed and interleaver setting by looking at the error rate of the decoder. When you have selected the correct parameters, you will see an error rate close to 0%.
In order to find out the correct terminal setting, you will need to look at the bitstream output - asynchronous traffic will clearly display the start and stop bits.