Showing posts with label FAST-WALE. Show all posts
Showing posts with label FAST-WALE. Show all posts

23 November 2022

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

17 February 2021

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

8 January 2021

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