a curious AT-3400D/AT-3104 (CIS-12) modem configuration

Interesting catch of an AT-3400D modem (also known as CIS-12 or MS-5) running on 14344.0 KHz/USB with the quite uncommon 9 channel configuration (3-out-of-12) as shown in Figure 1 below

Fig. 1

CIS-12, as you know, is a pseudo OFDM 12-tone (+ 1 pilot) waveform using PSK2 or PSK4 modulation at speed of 120 Baud while the modem name is AT-3004D (or its newer counterpart AT-3104). Channels 1-10 are used for data, 11 and 12 are test/service channels, therefore the "aggregate" speed is 1200 Baud. 

Fig. 2

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

WALE & wideband traffic, probably RapidM proprietary WB-LDL & WB-RDL waveforms

My friend ANgazu and I are almost done going through nearly 30GB of recordings of broadband transmissions that took place in the portfion of 6.9-7 MHz band during October and November, monitoring was also possible thanks to SM5TAH/Mats who made available its broadband SDR receiver (Airspy HF+, SDR-IQ). As already discussed in previous posts, we think they were trial transmissions aimed at fixing the performance of modified waveforms with respect to the relative reference standards (118-110D App.D and 188-141D App.G) especially with regard to the fourth-generation ALE. Some of these tests were most likely conducted by Harris, as they more specifically concerned the 3GWB ALE (WBALE) and WHARQ broadband waveforms, although we did not find news or information about.

We also found 188-141D 4G-ALE (WALE) waveforms that use a modified/improved initial preamble that are probably traceable to trials by RapidM [1]: also in this case no direct confirmation other than a presentation given at an HFIA Industries meeting on March 2020. The traffic waveforms following those WALE handshakes are totally "new" (or at least never meet before for me) and defintely not 188-110D App.G compliant. Obviously, since these waveforms are used in the WALE trials they are developed, along with the related modem, by the same manufacturer.

bandwidths. We could detect waveforms spreading from 3 Khz to 48 Khz, their allocation within a wideband channel is negotiated during the WALE link setup stage and follows the specifications required by 188-141D (1). The examples in Figures 1a,1b show the wideband channel allocations of some of the monitored waveforms.

Fig. 1a

Fig. 1b

paradigma. The first consideration to make is that the traffic segments look like a ARQ system, but after the last data transfers the responder' ACKs are missing (Figure 2), maybe they are forward/reverse traffic links or the latest ACK is not required/mandatory by the system. Also notice that, although the wideband channel has been negotiated, the called station uses a different channel for its sendings, this channel is anyway "within" the one of the caller. Probably the responder announces it's own 16-bit sub-channel vector in the WALE confirm PDU.

Fig. 2

modulation. All the waveforms utilize eight-ary phase-shift keying (PSK8) constellation, the symbol mapping is the same used in 188-110D (Figure 3). As usual, the modulation rate varies according to the bandwidth.

Fig. 3

waveforms. According the used framing (ACF of 25.4 and 120 ms), we identified 2 families of waveforms, each consisting of 9 waveforms differing in bandwidth (3-24 and 48 KHz) and modulation rate (2400-19200 and 38400 Baud): unfortunately, the waveforms of the intermediate badwidths 30,36,42,.. KHz have not been found and therefore (hopefully at the moment) are missing.

25.4 ms framing. The frame structure consists of a "Tx Frame" consisting of a synchronization preamble followed by N "data packets" of fixed duration of 25.41 ms (except the 7200 Bd waveform), where N depends on the chosen waveform. Each data packet consists of alternating data (Unknown) and probe (Known) symbols. The frame structure is shown in Figure 4.

Fig. 4

A transmission consists of 1 or 3 Tx Frames separated by a "dead time" or a "guard interval", only the the first Tx Frame is preceeded by a TLC sequence (Figure 5).

Fig. 5

Main features of this family waveforms (so far seen) are sumarized in Table I.

Table I

The 25.4 ms periodicity of the data packets and their number N within each Tx frame can be seen in Figures 6 and 7 respectively.

Fig. 6

Fig. 7

However, I'm facing an odd problem about the length of the (known symbols) probes; let's see for example the 2400 Bd data packet: as from Figure 8, the 9.996 ms probe makes a length of 24 PSK8 symbols but after its demodulation the bitstream shows 75-bit lenght patterns, ie 25 PSK8 symbols! 

Fig. 8

The discrepancy is probably due to the SA PSK demodulator. Indeed, it must be noticed that either the preamble sequences and the probes are characterized by the lack of the sub-carrier in their harmonic spectrum (Figure 9): this feature has already been found in the modified/enhanced WALE preambles discussed in the previous post.

Fig. 9

 

120 ms framing. The frame structure consists of a TLC & synchronization preamble followed by fixed length 120 ms data packets, each data packet consisting of alternating data (Unknown) and probe (Known) symbols. The most interesting aspect is that the initial TLC & preamble sections consist of the same Tx Frame of the correspondent 25.4 ms family waveforms (Figure 10): it could be said that both waveforms (25.4 ms and 120 ms) present the same "front-end" to the receiving modem.

Fig. 10

The complete frame structure is shown in Figure 11.

Fig. 11

Figure 12 shows the 120ms period of some waveforms, unfortunately not all the samples have a good quality.

Fig. 12

The main features of this family waveforms (so far seen) are sumarized in Table II. It's interesting to see what came up when comparing the values of Table II with the correspondent values of the Waveform Number 7 of 188-110D App.D: as you see, most of the framings (ie the number of the PSK8 symbols) match the ones of the correspondent 188-110D waveforms. 

Table II

Although in some cases the durations are the same, the mini-probes sequence is different so there is no compatibilty between the observed waveforms and 188-110D. Figure 13 shows two frames of the 12 KHz 9600 Bd waveforms.

Fig. 13

RapidM Since these traffic waveforms are used together with the modified WALE waveforms seen in the previous post, it is logical to assume that they too are developed by the same manufacturer, ie - in our opinion - by Rapid Mobile (RapidM) [1]. A positive feedback comes from reading the technical documentation of their RM10 modem [2] "In addition, the RapidM proprietary wideband HF packet data modems known as WB-RDL is offered in the RM10 as a software option.  The WB-RDL waveforms and protocols are integrated with the WALE/4G ALE controller for link setup and dynamic forward/reverse traffic channel bandwidth negotiation. The combination of WALE/4G ALE with the WB-RDL provide data communication in challenged channel (e.g., SNR < 0 dB, high-latitude, high interference) conditions". More precisely, the documentation talks about the future WB-LDL & WB-RDL packet waveforms used with WALE: the acronyms could mean WideBand Low latency DataLink and WideBand Robust DataLink, that is the two families we have singled out (25.4 & 120 ms waveforms).

Fig. 12

We have quite a lot of assumptions and conjectures about it but at the moment we prefer to wait for "news" from RapidM on their official website (new RM12 wideband modem?) and monitor the HF bands for (hopefully) such new trials.

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

(1) the wideband channels are described in WALE PDUs using 16-bit “sub-channel” vectors, each bit element of a sub-channel vector refers to a sub-channel within an assigned wideband channel and describes 1.5 kHz sub-channels, range of 24 kHz, or 3 KHz sub-channels, range up to 48 KHz

[1] https://i56578-swl.blogspot.com/2022/11/an-enhanced-design-for-deep-fast-wale.html
[2] https://www.rapidm.com/product/rm10-wideband-software-defined-modem/

an enhanced design for Deep & Fast WALE preambles (RapidM RM12 HF modem?)

This post briefly summarizes the analysis of the Deep & Fast WALE waveforms seen so far, discussing in particular the acquisition preambles whose formation does not comply with the reference standard 188-141D (Appendix G, WALE or 4G-ALE). Some indications suggest that the monitored transmissions could be trials of a specific WALE implementation by Rapid Mobile adopted in their newest RM12 HF modem, but at present it's only a my guess.

1. Preamble
The preamble is used for rapid initial synchronization and provides time and frequency alignment. Both the Deep WALE and Fast WALE preambles use 4-ary orthogonal Walsh modulation by mapping each di-bit of the preamble sequence to "normal" or "exceptional" sets of 4-element Walsh repeated sequences.

 Walsh Sequences for WALE Preambles (MIL 188-141D, Table G-VIII)

Each 32-element is then scrambled by performing a modulo 8 addition between the PSK8 symbol sequence below and the corresponding Walsh element
{7,1,1,3,7,3,1,5,5,1,1,6,7,1,5,4,1,7,1,6,3,6,1,0,4,1,0,7,5,5,2,6}

2. Deep WALE
Deep WALE uses a 240 ms preamble consisting of 18 orthogonal Walsh modulated channel symbols. The first 14 fixed di-bits {0,1,2,1,0,0,2,3,1,3,3,1,2,0} are fixed, the final four di-bits are protocol-dependent and mapped using the "exceptional" 32-element Walsh sequences set. Each 32-element is then scrambled in accordance with 1. for a resulting sequence  of 576 PSK8 symbols.

Fig. 1 - Deep WALE preamble

I coded a C++ Deep WALE modulator in order to get a (synthesized) 188-141D compliant bitstream and then compare it to the bitstreams got by demodulating the (real) over-the-air Deep WALE calls extracted from a monitoring file. Since I was only interested on the preamble formation, to simplify the code I used a random generator in place of the 192 coded and interleaved PDU bits;  the "modulator" is limited to the PSK8 symbol mapping  (1).

Fig. 2

 

Sumarizing what seen in the previous posts, durations and symbols "into the game" are shown in Table I below:

Table I - comparison between real (on-air) and sythesized Deep WALE PDUs

As expected from the time-based analysis, the comparison of the bitstreams confirms that the real signals differ from the standard ones in the way their preamble is formed: specifically the real preambles have a longer duration (350 ms, 840 PSK8 symbols) and do not have sequence repeats (autocorrelation = 0). Conversely, the inevitable repetitions of the scrambling sequence during the formation of the synthesized preamble cause a 96-bit/32-symbols ACF (on the right of figure 3).

Fig. 3- on-air (left) and sythesized (right) DeepWALE bitstreams

The symbols of the real & synt preambles are shown below in figure 4:

Fig. 4

3. Fast WALE

As per 188-141D, Fast WALE uses a 120 ms preamble consisting of 9 orthogonal Walsh modulated channel symbols. The first 5 di-bits {3,3,1,2,0} are fixed, the final four di-bits are protocol-dependent and mapped using the exceptional set. Conversely to Deep modulation, the final two di-bits are unused and are set to 0. Each 32-element Walsh sequence of the preamble is scrambled in accordance with 1. for a resulting sequencetotal of 288 PSK8 symbols. By the way, the duration of the preamble is the same of the following coded and interleaved data frame and it's the half of the Deep WALE preamble.

Fig. 5 - Fast WALE preamble

A second C++ "sketch" was coded to produce a (synthesized) 188-141D compliant bitstream to be compared with the ones coming from the demodulation of the real signals. As in the previous code, a random generator is used in place of the coded and interleaved data bits.
From the analysis of the recordings I was able to detect at least four types(!) of Fast WALE framing which differ in the length of the preambles (figure 6) while keeping the duration - and therefore the symbols - of the data portion unchanged (120 ms, 288 PSK8 symbols) .

Fig. 6 - different Fast WALE framings

Table II - comparison between real (on-air) and sythesized Fast WALE PDUs

As in Deep modulation, the on-air preambles have no sequence repeats even when their duration matches the standard 240 ms; in the other cases, duration and therefore the number of symbols, are less than the ones specified in the standard. Figures 7,8 depict such differences, notice the 32 known symbols probes in both the bitstreams and the 96-bit/32-symbols ACF of the synthesized preamble.

Fig. 7 - on-air and sythesized Fast WALE bitstreams

Fig. 8

 

4. "RapidM RM12 modem" supposition
Unless there are other protocol "options" that I'm not aware of, the differences between the analyzed preambles and those described by 188-141D are due to a specific (proprietary?) implementation. In this regard, my friend ANgazu found an interesting document by Rapid Mobile - literally entitled "Considerations for Synchronization Enhancements for 4G/WALE" - where two proposed improvements to the WALE synchronization preambles are illustrated. Specifically, the second proposal presented by RapidM (slide 18, "WALE Enhanced Preamble") perfectly fits with durations and symbols of the on-air signals:

As said, according 188-141D every Walsh Symbol repeats the same scrambling sequence

{7,1,1,3,7,3,1,5,5,1,1,6,7,1,5,4,1,7,1,6,3,6,1,0,4,1,0,7,5,5,2,6} 

and such repetitions have detrimental effect on synchronization acquisition performance: avoiding such on-air repetitions during the preamble removes false peaks in acquisition correlations. RapidM "Enhanced Preamble" proposal just consists of the replacement of the scrambled sequences with CAZAC sequences (2) consisting of 168 PSK8 symbols for Fast WALE and 840 PSK8 symbols for Deep WALE (the other proposal concerns a 448-symbol extended scrambling sequence).
By the way, figure 9 shows the measured autocorrelations for on-air and synthesized preambles of both Deep & Fast WALE PDUs.

Fig. 9 - autocorrelations

The RapidM slides, which also announce the upcoming RM12 48kHz Wideband Modem, were presented at the HFIA meeting of March 2020: since the first WALE signals I could analyze date back January 2021, timings are consistent.

If my guesses are right, the analyzed transmissions could just be trials by RapidM, also because - at the time of writing - the RM12 modem is not yet in their catalog [1]. However, I haven't found any confirmation yet and furthermore there are some other aspects, such as the lack of the 1800 Hz carrier in the preamble sectors or the CAZAC sequences formation, which need further investigation. Probably the lack of the carrier during the preamble modulation (figure 10) is due to the "tone excision" feature, since the suppression of the 1800 Hz tone improves the waveform resilience and performance in the presence of channel interference [2]: that's another (RapidM?) enhancement to the WALE preamble.

Fig. 10 - the lack of the carrier in a Deep WALE PDU preamble

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

[1] https://www.rapidm.com/
[2] https://www.rapidm.com/standard/stanag-4539/ 

(1) C++ code for Deep WALE PDU formation (Arduino Mega-2560)

char buffer[60];
int preamble[18] = {0,1,2,1,0,0,2,3,1,3,3,1,2,0,0,0,0,0};
int pScramble[32] = {7,1,1,3,7,3,1,5,5,1,1,6,7,1,5,4,1,7,1,6,3,6,1,0,4,1,0,7,5,5,2,6};

int preambNorWalsh[4][32] = {
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
{0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4},
{0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4},
{0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0}
};

int preambExcWalsh[4][32] = {
{0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4},
{0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0},
{0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0},
{0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4}
};

int pduWalsh[16][64] = {
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
{0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4,0,4},
{0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4},
{0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0,0,4,4,0},
{0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4},
{0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0},
{0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0,0,0,4,4,4,4,0,0},
{0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4,0,4,4,0,4,0,0,4},
{0,0,0,0,0,0,0,0,4,4,4,4,4,4,4,4,0,0,0,0,0,0,0,0,4,4,4,4,4,4,4,4,0,0,0,0,0,0,0,0,4,4,4,4,4,4,4,4,0,0,0,0,0,0,0,0,4,4,4,4,4,4,4,4},
{0,4,0,4,0,4,0,4,4,0,4,0,4,0,4,0,0,4,0,4,0,4,0,4,4,0,4,0,4,0,4,0,0,4,0,4,0,4,0,4,4,0,4,0,4,0,4,0,0,4,0,4,0,4,0,4,4,0,4,0,4,0,4,0},
{0,0,4,4,0,0,4,4,4,4,0,0,4,4,0,0,0,0,4,4,0,0,4,4,4,4,0,0,4,4,0,0,0,0,4,4,0,0,4,4,4,4,0,0,4,4,0,0,0,0,4,4,0,0,4,4,4,4,0,0,4,4,0,0},
{0,4,4,0,0,4,4,0,4,0,0,4,4,0,0,4,0,4,4,0,0,4,4,0,4,0,0,4,4,0,0,4,0,4,4,0,0,4,4,0,4,0,0,4,4,0,0,4,0,4,4,0,0,4,4,0,4,0,0,4,4,0,0,4},
{0,0,0,0,4,4,4,4,4,4,4,4,0,0,0,0,0,0,0,0,4,4,4,4,4,4,4,4,0,0,0,0,0,0,0,0,4,4,4,4,4,4,4,4,0,0,0,0,0,0,0,0,4,4,4,4,4,4,4,4,0,0,0,0},
{0,4,0,4,4,0,4,0,4,0,4,0,0,4,0,4,0,4,0,4,4,0,4,0,4,0,4,0,0,4,0,4,0,4,0,4,4,0,4,0,4,0,4,0,0,4,0,4,0,4,0,4,4,0,4,0,4,0,4,0,0,4,0,4},
{0,0,4,4,4,4,0,0,4,4,0,0,0,0,4,4,0,0,4,4,4,4,0,0,4,4,0,0,0,0,4,4,0,0,4,4,4,4,0,0,4,4,0,0,0,0,4,4,0,0,4,4,4,4,0,0,4,4,0,0,0,0,4,4},
{0,4,4,0,4,0,0,4,4,0,0,4,0,4,4,0,0,4,4,0,4,0,0,4,4,0,0,4,0,4,4,0,0,4,4,0,4,0,0,4,4,0,0,4,0,4,4,0,0,4,4,0,4,0,0,4,4,0,0,4,0,4,4,0}
};

int shiftRegister[159] = {
0, 0, 0, 1, 0, 0, 1, 1, 0, 1, 1, 0, 0, 1, 0, 1,
1, 1, 1, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0,
1, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 0, 1, 1, 1, 0,
1, 1, 1, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0,
1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 1, 0, 1,
0, 1, 1, 1, 1, 0, 1, 0, 1, 0, 0, 0, 1, 1, 1, 1,
1, 1, 0, 0, 1, 1, 0, 1, 0, 1, 1, 1, 1, 1, 0, 1,
1, 1, 1, 0, 0, 0, 1, 1, 0, 0, 0, 1, 1, 0, 1, 0,
1, 1, 1, 0, 0, 1, 1, 1, 0, 0, 0, 1, 1, 0, 0, 0,
1, 0, 0, 1, 0, 0, 0, 1, 1, 0, 1, 0, 0, 1
};

void setup() {
  Serial.begin(9600);
}

void printBin(byte tribit) {
  for(int i=2; i>=0; i--){
    Serial.print(bitRead(tribit,i),BIN);
  }
  Serial.print(" ");
}

int getQuadbit(void) {
   return (random(16));   
}

int getTribit(void) {
  int bitout, bittap, bitin;
  int i,j;
  for(j=0; j<16; j++) {
    bitout = shiftRegister[158];
    bittap = shiftRegister[31];
      for(i=158;i>=1;i--){
        shiftRegister[i]=shiftRegister[i-1];
      }
    bitin = bitout^bittap;
    shiftRegister[0]=bitin;
  }
  return (shiftRegister[2]<<2)+(shiftRegister[1]<<1)+shiftRegister[0];
}

int doScramble (int a,int b) {
  if (a+b < 8) {
    return (a+b);
  }
  else {
    return (a+b-8);  
  }
}

void loop() {
  int scramblingSym;
  int tribit;
  int psk8;

  // preamble
  for (int i =0;i <14;i++){
    int y =preamble[i];
    for (scramblingSym=0;scramblingSym <32;scramblingSym++) {
      psk8 =doScramble(preambNorWalsh[y][scramblingSym],pScramble[scramblingSym]);
      Serial.println(psk8); //check        
    }
  }  
  for (int i =14;i <18;i++){
    int y =preamble[i];
    for (scramblingSym=0;scramblingSym <32;scramblingSym++) {
      psk8 =doScramble(preambExcWalsh[y][scramblingSym],pScramble[scramblingSym]);
      Serial.println(psk8); //check        
    }
  }  
    
  // PDU
  for (int quadBitSet =0;quadBitSet <48;quadBitSet++){
    int pduSymbol =getQuadbit();
    for (scramblingSym=0;scramblingSym <64;scramblingSym++) {
      tribit =getTribit();
      //printBin(getTribit()); //check    
      psk8 =doScramble(pduWalsh[pduSymbol][scramblingSym],tribit);
      Serial.println(psk8); //check    
      //sprintf(buffer, "Walsh modulated PDU symbol:%i  scrambling symbol:%i  PSK8:%i",pduWalsh[pduSymbol][scramblingSym],tribit,psk8);
      //Serial.println(buffer);        
    }
  }
  for( ; ; );
}


(2) Constant Amplitude Zero AutoCorrelation waveform (CAZAC) is a periodic complex-valued signal with modulus one and out-of-phase periodic (cyclic) autocorrelations equal to zero. CAZAC sequences find application in wireless communication systems for synchronization of mobile phones with base stations. Zadoff–Chu sequences are well-known CAZAC sequences with special properties. 
https://en.wikipedia.org/wiki/Constant_amplitude_zero_autocorrelation_waveform

WALE (4G-ALE) three-way traffic channel negotiation

This post can be considered a continuation of the previous one since it too is based on the observations and analyzes of the same monitoring file. Also in this case these are asynchronous calls but with the particularity of using three-way handshakes. 

Although the common protocol exchange for 4G-ALE link establishment is the two-way handshake, it may occurs a traffic channel negotiation which requires a three-way handshake. When sending a link setup request, the caller is able to measure occupancy in its assigned sub-channels, but will not generally know whether the Confirm PDU from the called station will be strong enough to overcome low-level local interference in some sub-channels. However, after measuring the SNR of the Confirm PDU, the caller may compute that there will be adequate SNR on sub-channel(s) that it initially reported as occupied. In such a case, the caller should send a Caller Confirm PDU with Rx sub-channel vector bits set to indicate the wider available traffic channel (figure 1),

Fig. 1 - example 3-Way Computation of Traffic Channel (188-141D Figure G-19)

However, as shown in figure 2, it's worh noting that in these samples no data traffic was recorded after the channel negotiations (the "responder" is here termed by me as "called").

Fig. 2 - contiguous 3-way handshakes

Aside from the 3-way handshakes, it must be noted that both "Deep" and "Fast" WALE waveforms are used throughout the same handshake (see figure 3) conversely to what specfied by 188-141D: " Either of the waveforms may be used in any transmission, but the same waveform shall be used throughout a transmission" (#G.5.1). The transmissions could also be Point-To-Multipoint (PTM) Async link setups and consequently the third burst could be actually the Confirm PDU from a "second" called node, however the (deprecated) mix of  waveforms still remains as well as the suspect that these are modified waveforms.

Fig. 3 - use of both Deep and Fast waveforms throughout the same handshakes

As said, this sample is not a "spot" one but it's extracted from a quite large monitoring file that has already been (partially) analyzed previously,  consequently it was logical to expect WALE PDUs with observed on-air durations different than the ones specified in the relevant 188-141D.

Fig. 4

As well as  the not-compliant durations of Deep and Fast PDUs (due to their preambles length), in my opinion  the lack of (expected) traffic after the 3-way channel negotiations and the "unusual" (if not deprecated) use of both Deep and Fast waveforms throughout a same transmission, are clues that reinforce the hypothesis of test transmissions aimed to verify the performance of modified 188-141D WALE waveforms and therefore of a "new" 4G HF modem... further analysis and investigations will follow in next posts.

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

Deep WALE (4G-ALE) Async call

Thanks to my friend and collegue ANgazu, I was able to analyze some WALE (4G-ALE, 188-141D App.G) asynchronous calls transmissions which reveal some aspects that are not entirely clear or even a bit discording with the relevant standard, at least according my analysis and the docs at my disposal. Perhaps it is some specific implementation or maybe tests, as a lot of 4G-ALE & wideband activity has been recently monitored in the 6.9 - 7 MHz portion. 

Fig. 1

As in the "Fast" WALE async call [1], the LSU Request PDU must be preceded by a scanning call (the so-called "capture probe") which is designed to capture asynchronously scanning receiver(s) so that they will stop scanning to receive the final LSU Request. The capture probe consists of repeated blocks of 96 known PSK8 symbols that permit rapid detection of the call, and therefore very short scanning dwell times. As in 2G and 3G ALE, the duration of the WALE scanning call dependes on the number of channels in the scan set and is as follows:
Tcapture ≥ Dmin(N+2)
where Dmin is the asynchronous-mode minimum dwell time (200 ms as default setting) and N is the number of channels. However, conversely of 2G and 3G ALE, the scanning call portion of the async WALE call is unaddressed: that is, the addresses of the stations are not sent during the capture probe (1).

Fig. 2 -  Deep WALE async call

In the sample being analyzed, after demodulation the 6000 ms capture probe consists of 150 blocks which corresponds to a scan set of 28 channels and confirms the use of the minimum dwell time (6000=200*30).

Fig. 3

As per 188-141D App.G, the capture probe is followed by a 240 ms acquisition preamble, followed in its turn by one (or more) coded and interleaved WALE Request PDU. The WALE LSU protocol use a fixed 96-bit length PDU for both Fast and Deep waveforms with a correction coding consists of a constraint length 9 (CL-9), half rate convolutional code producing a 192-bit coded block to be interleaved (ie, for each bit input to the encoder, two bits are taken from the encoder).
Using the Deep WALE waveform, the coded and interleaved PDU bits are sent four at a time. Each set of four bits (a “quad-bit”) is used to select one of the 16-element Walsh sequences, the selected 16-element Walsh sequence is then repeated 4 times to yield a 64-element Walsh sequence. Each 64-element channel symbol is scrambled using 64 8PSK symbols of a scrambling sequence generated using a 159-bit shift register with a single tap after bit 31 which run without re-initialization for all PDUs in a transmission (the shift register is initializated only at the beginning of a the Deep ALE transmission) (2).
Therefore a (coded and interleaved) 192-bit WALE PDU resolves in 48 "quad-bit" sets each consisting of 64-element Walsh sequence, for a total of 48 * 64 = 3072 PSK8 symbols, and has a duration of 1280 ms (Known Symbols segments are not sent in Deep WALE PDUs, so Walsh coded data symbols are sent continuously after the initial preamble).

 

The lack of mini-probe shapes in the PDU portion and its 1630 ms duration (figure 2) allow to Id a Deep WALE modulation. Unfortunately, the autocorrelation of the signal is not of much help. Given that the scrambling shift register x^159+x^31+1:

• is iterated 16 times between the generation of each scrambling symbol
• run without re-initialization(!) for all PDUs in a transmission
• has a max sequence length of 2^159 -1
• is used to scramble a small number of PDUs (if not only one)

it will be impossible to get repetitions in the portion of the WALE PDU but - obviously - only the strong 40 ms spikes due to the 96-symbol blocks of the capture probe (figure 4).

Fig. 4 - ACF values of the scanning call and WALE pdu portions

However, it should be noted that the 1630 ms duration of the Deep WALE PDU does not match the expected 1520 ms one (240 preamble + 1280 data): thus, there is somewhere an "extra" duration of 110 ms. In this regard, figure 6 shows a short segment "S" where, although the lack of the 1800 Hz carrier (or not detected/detectable by SA), the signal is still actually keyed at 2400 symbols/sec; also notice that in place of the carrier rather fairly solid "diagonal traces" show up. 

Fig. 6

Looking at the time durations in figure 7, the segment "S" lasts ~350 ms and "positionally" it coincides with the preamble preceding the Request PDU data: here it's the reason of the extra 110 ms duration, ie an "extended" 350 ms (240+110) preamble which consists of 840 PSK8 symbols that - anyway - does not resolve into an integer number of Walsh modulated symbols! (188-141D #G.5.1.7.1 specifies a 18 Walsh modulated symbols preamble).

Fig. 7

Such discrepancies between the actual on-air signals and the relevant standard have already been highlighted in the Fast WALE PDUs, at least in the ones that I had the chance to analyze [2]. It must be noted that the recent releases of 188-110D and 188-141D extend the max bandwidth to 48 KHz therefore 110C/141C compliant waveforms are in some way a bit "obsoleted" as well as HF modems such as Harris RF-5800 (WBALE & WHARQ waveforms), RapidM RM10 and others. What do I mean? My point is that probably we are dealing with a proprietary implementation/enhancement of the latest WBHF standards (ALE and traffic waveforms): given the quite long monitoring available (more than 30 GB of recordings to review), further analysis and investigations will follow in next posts.

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

(1) In 2G and 3G-ALE the address of the called station is contained in the scanning call, thus all stations that are not included in the call are free to resume scanning. The 4G-ALE scanning call consists of repeated blocks of known symbols so that a station must wait for the final Request PDU  to find out if it's the recipient of the call:

That choice of unaddressed scanning calls has interesting consequences:

• all scanning stations are captured and held until the WALE Request PDU (which contains the address) is received. This is a drawback, but the short dwell time (200 ms) results in short scanning calls, so this is mitigated;

• because it does not contain station addresses, the capture probe of the async call is not encrypted.

 

(2) the same (159,31) scrambling polynomial and Walsh sequences are used in MIL-STD 188-110C for the Waveform ID-0

[1] https://i56578-swl.blogspot.com/2021/02/4g-ale-async-two-way-point-to-point.html
[2] https://i56578-swl.blogspot.com/2021/01/4g-ale-fast-wale-188-141d-and-wbhf.html

Harris' 3G-ALE FLSU Async call (2)

Commenting the recent post about the Harris's implementation of the FLSU Async call [1], an anonymous reader sent me a good quality recording of that signal. Observing the spectrum/time FFT of figure 1 the call has a duration of about 9 seconds (9170 ms) and, according to the value of the ACF , it consists of 10 BW5 frames. By calculating the respective durations and taking into account the omission of the TLC sections exceeding the first, we get

1013.33 + (9 × 906.66) = 9173.27 ms

ie a value that matches the duration of the call and confirms the FLSU Async call implementation adopted by Harris (by the way, a 7-channel scan list in this sample).

Fig. 1

In addition to the time based approach, in order to verify the above results I tried a tribit symbols based analysis of the demodulated bitstream. Indeed, as per STANAG-4538 (and 188-141B too) the TLC section (256 pseudo-random tribit symbols) and BW5 preamble sequence (576 tribit symbols) are modulated directly without undergoing the PN spreading thus their patterns are easily identifiable within the bitstream. A good way to bring out the two desired sequences is to use synchronization of the bitstream:

a) synchronizing on the preamble sequence
10 rows come out, which therefore correspond to the preambles of the 10 BW5 PDUs (don't fall into the 4-bit HEX trap: since the PSK8 modulation, the symbols we are looking consist of tribit values, ie 4,4,7,3,... = 100, 100, 111, 011,...):

Fig. 2

b) synchronizing on the TLC sequence
as expected, the result consists of only 1 row which is just the one relating to the "entire" first BW5 PDU:

Fig. 3

As a further confirmation, I synchronized the stream on the "border" of the two sequences getting a single row result:

Fig. 4

So, in my opinion, both approaches demonstrate the composition of the FLSU Async call which is implemented by Harris: ie, the TLC section is sent only in the firts BW5 PDU (as per 188-141B #C.5.2.4.5.2):

 

Looking at the bitstream, it's also  evident that this network uses the Linking Protection (LP) procedure [2]. As per STANG-4538 #9.3.2 "Scanning call PDUs shall be scrambled using alternating word numbers 00000000 and 00000001. The word number used in scrambling the first scanning call PDU shall be selected so that the scanning call PDU sent immediately before the Call PDU is scrambled using word number = 00000001. The Call PDU that concludes an asynchronous-mode call shall be scrambled using word number = 00000010": that's the reason of the alternating patterns of figure 5.

 

Fig. 5

By the way, it's worth noting that LP does not address jamming or similar techniques, which are best countered by TRANSEC, nor is it intended to replace the COMSEC function of traffic protection: indeed, LP protects the linking function, including related addressing and control information.

 

A recent monitoring of 6.9 MHz band by my friend ANgazu (who I thanks for sending some recordings) shows the use of the same async call also in WBALE & WHARQ scenarios:

 

Fig. 6

 

https://disk.yandex.com/d/JCbCPlmTV_wl1g (Harris Async call)

https://disk.yandex.com/d/IQe71tmy0VIA3g  (WBALE & WHARQ)

[1] https://i56578-swl.blogspot.com/2022/10/harris-3g-ale-flsu-async-call.html
[2] https://i56578-swl.blogspot.com/2017/02/stanag-4538-3g-ale-flsu-calls-with.html