Deep WALE (4G-ALE) Async call using PSK2

(for background http://i56578-swl.blogspot.com/search/label/4G-ALE)

Very interesting example of an asynchronous three-way Deep WALE handshake (4G-ALE, MS-141D App.G)(1) sent to me by my friend ANgazu; recordings credits to EA6AMM Gaspar. 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.
In figure 1 you can see the call which is formed by the "scanning call" (also known as "capture probe") + the actual Request, the call is then followed by the called & caller Confirm bursts. The scanning call is designed to capture asynchronously scanning receiver(s) so that they will stop scanning to receive the final Request. 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 and receivers are held unitl the reception of the ending Request.

Fig. 1 - Deep WALE async call

The scanning call consists of repeated blocks (known symbols) with an ACF value of 80 ms (Figure 2) 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. Since the capture probe lasts about 3500 ms, assuming the default setting is used, the number of channels is 15.

Fig. 2 - ACF value of scanning call (capture probe) portion

But the most important thing - see Figure 3 - is that the Deep WALE waveforms (call and confirms) use PSK2 modulation(!) rather than PSK8 as required by MS-141B App.G standard.

Fig. 3

Once demodulated, the capture probe consists of a 192-bit sequence (originating the 80 ms ACF) which is repeated - in this sample - 44 times (blocks):

0x [D1 38 6C BC 22 71 BD 65 B9 21 D6 F2 C6 FD FE 8F 49 D1 D9 FD 36 0D F1 80]
0x [2E C7 93 43 DD 8E 42 9A 46 DE 29 0D 39 02 01 70 B6 2E 26 02 C9 F2 0E 7F] opposite polarity 

Fig. 4 - 192-bit sequences forming the scanning call blocks

These waveforms are not MS-141D App.G compliant at all; in fact, according to the standard:
- the modulation used shall be PSK8, while in the recorded samples is used PSK2;
- the scanning call blocks shall consist of 96 symbols, while here the blocks consist of 192 symbols, exactly double (obviously, the respective ACF values ​​are also double);
- the duration of the Deep WALE Request (~ 622 ms) does not match the expected 1520 ms value (240 ms preamble + 1280 data ms).

Perhaps it is some specific implementation of a new and more robust Deep WALE call, given that PSK2 is more robust than PSK8 especially in terms of error performance under the same noise conditions (2).

https://disk.yandex.com/d/GBKjZzt4q9509Q (recordings credits to EA6AMM Gaspar)

(1) The multiplicity of abbreviations and acronyms sometimes doesn't help, below what I used:
WB ALE (or WBALE), Harris implementation of 3GWB
WALE (or 4G ALE), wideband ALE as for MIL 188-141D App.G, fourth generation ALE
note that WB ALE is not synonymous with WALE since the latter has its own PDUs and waveforms.

(2) In PSK2, the phase shift between the two possible symbols is 180°, which makes it very easy for the receiver to distinguish between them even in the presence of noise. In PSK8, the phase difference between adjacent symbols is only 45°, so even a small amount of noise can cause symbol errors.

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

Fast WALE Async call (4G-ALE)

In the asynchronous call, used to set up a link between two stations when one or both of them is scanning asynchronously, the WALE Request PDU must be preceded by a scanning call, the "capture probe", which similarly to 2G/3G ALE is aimed to capture asynchronously scanning receiver(s).

Asynchronous two-way point-to-point link setup example (from MIL 188-141D App. G)

The capture probe consists of repeated blocks of known symbols that will be recognized by the scanning receivers so that they will stop scanning and wait to receive the WALE Request PDU (Protocol Data Unit) which immediately follows the capture probe section. The capture probe must last long enough so that every scanning receiver will have a chance to receive it, thus its duration depends on the number of channels (N) in the scan set and on the minimum dwell time Dmin (200 ms as default setting) and shall be  ≥  Dmin * (N+2).

In the sample being analyzed the "Fast" WALE waveform [1] is used to convey the WALE Request PDU which follows the capture probe (figure 1).

Fig. 1

 

Each capture probe block consists of the following 96 PSK8 symbol sequence:

 

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

 

and, since it's transmissed at the symbols rate of 2400 symbols/s, each block has a duration of 40 ms. Notice that the number of the known symbols in each block (96) is the same of the number of the unknown symbols sent in the call PDU: most likely this choice was adopted to facilitate the recognition and acquisition of the ending call. 

Figure 2 shows the 40 ms ACF spikes of the scanning call portion.

Fig. 2 - ACF of the capture block section

It's interesting to compare the way 3G-ALE (STANAG-4538) and 4G-ALE (MIL 188-141D WALE) implement the async calls: 

• the 3G-ALE async call consists of 1.35 N  "011-type" Request PDUs, where N is the number of  frequencies in the scan list, and 1.35 is the duration of the dwell period (in seconds); the call ends with a single "000-type" PDU Request. Since the address of the called station is contained in each of the "011-type" PDU Requests (as in 2G style), all stations that are not included in the call are free to resume scanning;

• since the 4G-ALE async call is not addressed, a station must wait for the Request PDU (sent at the end of the capture probe) to find out if it is the recipient of the call. 

 

It might seem like a disadvantage, but 4G is actually much more faster that 3G; indeed, assuming a 10 channels scan set, the maximum wait duration is approximately equal to 13.5s for 3G and 2.4s for 4G (with minimum dwell time of 200 ms).

 

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

[1] https://i56578-swl.blogspot.com/2021/01/4g-ale-fast-wale-188-141d-and-wbhf.html

Fast WALE (4G-ALE) and wide band traffic (WBHF)

Thanks to a reporting of my friend Martin G8JNJ, on 4744.0 KHz - mostly in the morning -  it is possible to receive transmissions which use Fast WALE (188-141D App.G) and WBHF (188-110D App.D) waveforms: it's the first time for me that I have the canche to "see" and analyze 4G-ALE signals. 

The WALE (4G-ALE) system uses waveforms derived from the WBHF waveforms for its transmissions, and draws ideas from both second and third-generation ALE for its protocols. The WALE waveforms operate in 3 kHz and provide two interoperable modes for sending PDU: the “Fast” WALE waveform (intended for very fast link setup in voice-quality channels) and the “Deep” WALE waveform (designed for operation in the most challenging channels, including SNR < 0dB). The choice between Fast or Deep WALE can be made on a call-by-call basis as receivers listen to both types of WALE calls, as well as 3G & 2G ALE calls for simultaneous operation with existing narrowband circuits.[1]

In the recorded session shown in Figure 1, the transmissions consist of two-way WALE handshakes followed by data transfers using ARQ method and WBHF waveforms: the bursts following the last ACQs are probably an EOM signaling given that the following session begins with a WALE handshake. Since the strong signals in the analyzed sample, I can't say if it's a bidirectional link. 

Fig. 1

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 (ie, for each bit input to the encoder, two bits are taken from the encoder). Using Fast WALE the coded and interleaved bits of each PDU are sent in alternating blocks of unknown (data) symbols and known (probe) symbols.

The WALE waveforms employ PSK8 modulation of an 1800 Hz subcarrier at a rate of 2400 symbols per second. The two more dense states in the phase plane of Figure 2 are due to the BPSK modulation of  Fast WALE data.

Fig. 2

 

In the analyzed samples the portion before the coded and interleaved PDU, according its 83.33 ms duration, consists of 200 PSK8 symbols (figure 3). Since the preamble and the TLC sections use the same 32-element Walsh chips (32 PSK8 symbols), the initial portion consists of 1 TLC block (13.333 ms) followed by 168 PSK8 symbols (70 ms) which do not resolve into an integer number of 32-element Walsh chips! These values, durations and symbols, are not compliant with relevant standard (188-141D #G.5.1.8.2) which requires nine 32-element Walsh chips for the Fast WALE  preamble, for a total of 288 PSK8 symbols and a 120 ms duration.

Fig. 3

The structure of the known/unknown symbols blocks is exactly compliant with 188-141D: ie, 288 PSK8 symbols and a 120 ms duration (figure 4). Notice that according 188-141D, the length of the preamble shall be equal to the sum of the lengths of the known/unknown symbols blocks.

Fig. 4

The traffic waveforms are PSK8 modulated at symbol rate of 9600Bd, ACF value is 120ms that makes a 3456-bit length period or 1152 PSK8 symbols (Figure 5): the frame structure (Figure 6) matches the waveform #7 of 188-110D App.D ie, 1024 Unknow symbols (3072 bit) + 128 Known symbols (384 bit). 

Fig. 5 - WBHF waveform #7

Fig. 6

The bursts I termed as "EOM" also employ PSK8 modulation at symbol rate of 9600 Baud and have a frame length of 1504 symbols (Figure 7).

Fig. 7

[1] https://www.rapidm.com/wp-content/uploads/2018/10/RM10_WBHF_EN.pdf

https://yadi.sk/d/FkvzXFHKLL0Rbw