a STANAG-4285 autobaud waveform?

Interesting STANAG-4285 transmission heard on 14000 KHz/USB and sent me by my friend GrandBleu from radiofrecuencias.es (Figure 1)

Fig. 1 - STANAG-4285 segments

The 35 sec segments seem a modified S-4285 waveform since they begin with a block, that I here refer to as "header", and which is not referenced in the standard. The header has a duration of 116ms and is modulated using PSK2, as you may see in Figure 2.

Fig. 2 - PSK2 modulation detected in the initial "header"

I used the SA phase detector and its relative bitmap in order to "browse" the signal and to better indagate the header. Looking at Figure 3 you may see a 13.333ms repeated pattern: well, 13.333ms @ 2400 symbols/sec makes a duration of 32 symbols (31,999) or 32 bits, since the header is PSK2 modulated (ie 1 bit = 1 symbol).

Fig. 3 - 32-bits repeated pattern in the header of the heard S-4285 waveform

Consequently, I tried a PSK2 demodulation of the headers of some segments and after their differential decodings I obtained  bitstreams which exhibit a well-defined structure consisting of initial and final "01"s sequences and characterized by a 32 bits sequence which is six times repeated immediately before of the final "01"s sequence and that exactly matches the pattern seen in the bitmap of Figure 3.

[10100001001111001111100011011110]

Fig. 4 - differential PSK2 decoding of a header

The same 32-bit sequence was found in all the headers I demodulated (just 3 of them are shown in Figure 5), even if it didn't appear in the same order I wrote it: one must consider the characteristcs of the SA's generic (!) PSK-n demodulator .

Fig. 5

I don't think this so-called header is actually a “transmit level control” (TLC) block. Indeed, no information is carried by the TLC since it's a sequence of symbols intended solely for the purpose of establishing the radio TGC (transmit gain control), ALC (automatic level control) and AGC (automatic gain control) before the actual preamble is sent/received. In my opinion this S-4285 waveform feature an “autobaud” facility (1) which is coded in the initial header (perhaps a Walsh coded sequence?). As shown in Figure 5, the autobauding information would consist of 6 frames, each with a duration of 13.3 ms and a length of 32 bits (total length of 192 bits), and precedes the S-4285's usual synchronization preamble.

And let's get to the data blocks. To identify which sub-mode is used I chose from time to time the various options made available by a S-4285 decoder (k500) until I found the option that had 100% confidence and 0 errors: that is, 300bps and zero length interleaving.  As a test, I used a second S-4285 decoder and always got the same result even if the resulting bitstreams didn't seem structured. Although these decoders indicated 100% confidence and 0 errors (corrections), curiously they did not detect/show the 32-bit words used for signaling the Start Of Message (SOM = 0x03873C3C MSB first) and End Of Message (EOM = 0x4B65A5B2 MSB first): could it be sign of a "fake" decoding? Finally, I used a third, more sophisticated, decoder configuring it in "auto-detect" mode: this third test also confirmed the 300bps/N sub-mode but with the reporting of corrections and a resulting bitstream with a 40-bit/5-byte period that has - in my opinion - a bit more sense.
The 40-bit length period is due to the presence of a sequence that is four times repeated near the end of all the decoded segments (Figure 6). Note that the same considerations made above apply to the sequence in question.

[1101101000100111101001111111000111100101]

At first glance it could be an EOM/EOT signal but the bitstream should come from a higher level protocol (datalink layer) i.e. after the removal of the S-4285 overhead and therefore should have a different function.

Fig. 6 - a data blocks bitstream

That datalink protocol (if any ) is at present unknown to me.

Back to the initial headers, I remembered having seen something similar a while back while I was analyzing Harris' serial PSK8 waveforms [1] and by demodulating their initial headers I found a correspondence between those headers and the one analyzed here: that is, a sequence of 32 bits of length which is repeated six times between sequences of initial and final "01"s (Figs. 7,8)

Fig.7

Fig.8

From the above it seems that L3Harris (and perhaps not only them) have added the "autobaud" function to some waveforms such as STANAG-4285, obviously it is only my hypothesis which has no direct or indirect confirmation: your comments and other submissions will be as usual welcome and may assist in resolving this matter.

https://drive.google.com/file/d/1WD9gBFzbGnmMdBFITTOYFf5AOTWCij4y/view?usp=sharing

(1) the “autobaud” facility enables the receiver modem to automatically adapt the transmitter’s data rate and interleaver configuration without operator intervention

[1] http://i56578-swl.blogspot.com/2021/11/harris-psk8-2400-bd-digital-voice.htm

ECCM Frequency Hopping Spread-Spectrum (FHSS) example

Looking at the spectrum of the receivable signals around 7 MHz in the UKR skyes, as well as numerous and very frequent STANAG-4538 and L3Harris WHARQ waveforms, it may happen that we observe transmissions in frequency hopping mode (FHSS, or Frequency Hopping Spread-Spectrum) as shown in Figure 1.
Frequency hopping (also known as ECCM, Electronic counter-countermeasures) is the most commonly used Transmission Security (TRANSEC) technique. The frequency hopping capability provides advanced anti jam protection for communications. In HOP radio mode, the transmitter frequency changes so rapidly that it is difficult to intercept or jam the signal. For additional security, hopping data and digital voice data can be encrypted. 

Fig.1 - FHSS transmission

Me and my friend ANgazu from radiofrecuencias.es had the chance the analyze these signals and share the results. We observed transmissions which use 26 or 27 channels and occupy a bandwidth of 81 KHz, since each channel is 3 KHz wide (2700 + 300 Hz separation). Hopping rate is 8.88 sps with an hop time of ~112.5 ms (say 102 ms ON, 10.5 ms OFF).

Fig. 2 - FHSS single channel frequency occupation

Fig. 3 - FHSS timing

Like a single-channel serial tone waveform, the modulation used is 2400 Bd PSK8 for both voice and data (Fig. 4).

Fig. 4 - FHSS modulation

This waveform is fielded in AN/PRC-150(C) radios by L3Harris. Wideband hopping covers a frequency band that is bounded by a lower and upper frequency specified in multiples of 100 Hz, frequency exclusion bands may also be programmed. AN/PRC-150 narrow band hopping uses frequencies within a defined bandwidth of the center frequency (Fc) as in the Table below: notice the reported 81 KHz bandwidth  in case of  3.5 MHz <= Fc < 9.995 MHz.

Table 3.16 - L3Harris AN/PRC-150 operation manual

An important aspect of hopping is synchronization, ie all radios in a net shall use the same frequency at the same time intervall: that alignment may be accomplished with the use of GPS, but is some in cases (very very rare) it uses the manual  3x4 sync sequences as shown in Figure 5.

Fig. 5 - 3x4 sync sequences

If our guess is correct, we can assume a large employ of L3Harris equipmente in that (war) theatre.

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

Harris Citadel II secured transmissions, 12/32 bytes length IVs

Continuing the monitoring and analyzing the receivable signals around 7 MHz band, I am increasingly convinced that the Harris Citadel II is the encryption algorithm used for these transmissions. In the analysis of the bitstreams published in the previous post [1], I have spotted patterns that look like 32 bytes Initialization Vectors:  the 256 bits are split in two 128 bits parts, each 3 times repeated, sent just after the Citadel sync sequence and prepended the ciphertext (Figure 1). 

Fig. 1 - 32 bytes (256 bits) IV

This type of encrypted transmissions occurs when the STANAG-4538 circuit mode service is used, in the packet mode service (L/HDL protocols) - although Citadel is also used there - the bitstreams do not show any repeating pattern: my guess is that in such a case the Citadel I algorithm is being used.
That said, I took care of catching & recording only the circuit mode transmissions, still within the same portion of HF band. Bitstreams analysis turned out to be very useful, especially the transmissions recorded on 6769.5 and 6772.5 KHz/USB; indeed, in these transmissions the used Initialization Vector (IV) is 12 bytes (96 bits) length and it's three times repeated (Figure 2): this is really interesting since I would have expected to see 32 bytes IV as in other similar recordings.

Fig. 2 - 12 bytes (96 bits) IVs after removal of the initial sync sequences

I have verified this characteristic in all transmissions recorded on that frequency, Figure 2 lists only a few for brevity.

Fig. 3

So far, I've observed the following format (related to S-4538 circuit mode services):

16 bytes start/sync sequence 0x1E561E561E561E001A5D1A5D1A5D1A5D (Citadel)
12 bytes IV (3 times rptd) - OR - 32 bytes IV (2×128 bits parts, each 3 times rptd)     
ciphertext
...
8 bytes end sequence 0x1E561E561E561E08 (Citadel)  

The different lengths of the used Initialization Vectors (12 and 32 bytes) suggest that the Citadel II algorithm (if this is the case) can be configured for different block cipher modes with different block lengths; moreover it's backward compatible with its predecessor Citadel I, given the coexistence of circuit/packet modes within the same logical link (see the comment in previous post). Anyway, different configurations of the algorithm in different frequencies make me think about field tests: indeed war theaters are formidable test-beds not only for weapons but also for milcomm technologies, new waveforms and COMSEC.

The few informations I could find by googling the web seem confirm my guess, even if I've still no confirm: "The Citadel II algorithm can be operated using any block cipher traffic mode [...] include Cipher Feedback mode (CFB), Counter Mode and Self Synchronizing Cipher Feedback Mode (SSCFB). The 256-bit Citadel II algorithm provides a configuration that is interoperable with current Citadel I-based applications and a configuration that is fully disclosable" [2]. Note that although Citadel I and II  are referred to as algorithms, they are actually ASIC chips (Application-Specific Integrated Circuit), ie algorithms rendered in hardware, which are embedded - for example - in Harris Falcon II, Falcon III family radios. 

It is still not clear to me why the (presuemed) Citadel II encryption is not used in packet mode transmissions, ie in LDL/HDL protocols: I don't think it's due to problems acquiring the IVs since at the upper layer surely sits a data link protocol like S-5066 which is able to assemble the received packets.

Obviously - as said - these are just a my speculation and comments are welcome: further recordings and bit luck may help...

https://disk.yandex.com/d/2ceYFGyy0LWdJA

[1] https://i56578-swl.blogspot.com/2023/05/harris-citadel-ii-secured-traffic.html
[2] https://www.researchgate.net/...

Harris Citadel II secured traffic?

For some days now I have been dedicating some time to monitoring the 6.8-7.1 MHz band where it is possible to receive several STANAG-4538 (3G-HF) signals and among which also WHARQ wideband activity [1], the latter waveforms developed by Harris (now:L3Harris) [1]. Figure 1 is an example.

Fig. 1 - L3Harris WHARQ traffic [1]

 

What turned out to be very interesting are the S-4538 circuit mode services where MS-110A is used as the traffic waveform (Figure 2), note also that sometimes the packet mode service follows, in the case of Figure 2 using low-latency data link (LDL) protocol and BW3-BW4 waveforms

Fig. 2 - STANAG-4538 traffic using circuit mode and packet mode services

After demodulation of some MS-110A segments, the presence of the well-known sync sequence:
1E 56 1E 56 1E 56 1E 00 1A 5D 1A 5D 1A 5D 1A 5D 
in all the segments indicates that the traffic is secured by the Harris Citadel cryptographic engine [2], so far nothing new (Figure 3).

Fig. 3

What really surprised me is that once removed the sync sequence (or reshaping the bitstream to to 128-bit length period) a 256-bit pattern, split in 2 parts each 3 times repeated, emerge from the bitstreams... never seen before in such secured transmissions!

74 04 9F 5C 72 1C 0F 51 CB EE 30 AA F6 01 ED 1A 54 F0 CE C2 DA 02 C8 CB 81 91 3C 8A C9 07 67 01
EE 82 FB 12 56 78 A1 2E 75 7F 21 39 26 24 A7 A8 F4 A6 CF CE 56 B0 E4 18 22 E2 F1 C0 1E 8E 17 DA
40 36 4B A6 74 6A 63 05 A5 E8 81 14 A7 65 25 73 43 26 17 13 0D AB 4C F0 90 8D 5B 5A AB A5 4C 9A

Fig. 4 - 256-bit patterns (2x128)

Even more interesting is the fact that the bitstream resulting from the demodulation of one of the BW3 bursts (the same 111-byte packet was sent several times) while indicating Citadel encryption does not show those 2x128 bits patterns (Figure 5).

Fig. 5 - BW3 bitstream (8/128 bits period)

So: 

* since, for example, KG-84/KIV-7 use a 16 bytes length Initialization Vector and it is sent in 2 parts of 64 bits length (each 4 times repeated), 
* given the presence of the well-known Citadel start/stop sequences,
* it's not an AES algorithm since the length of its Initialization Vector is 16 bytes regardless of the key size (12 bytes for AES-GCM) 

It's a mine guess that maybe we see  32 bytes Initialization Vectors, which are sent in 2 parts of 128 bits length, each 3 times repeated, and that these transmissions could be secured by the 256-bit Harris Citadel II algorithm [3] which likely needs such IVs.
Obviously that's just a my speculation, comments are welcome.

Monitoring was possible thanks to KiwiSDRs from Romania (YO8SGV - Dorohoi)  and Russia (radiorubka - Tambov) so they must be using low power and NVIS techniques.

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

[1] https://i56578-swl.blogspot.com/search/label/WHARQ
[2] https://www.cryptomuseum.com/crypto/harris/citadel/index.htm
[3] https://www.cryptomuseum.com/crypto/harris/citadel2/index.htm
 

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

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/

Harris wideband operations (a bit "intruding" within the 7 MHz HAM band)

Wideband activity was heard at the end of August around 7 MHz (figure 1) using mainly Romanian and Greek KiwiSDR receivers, my friend KarapuZ sent me his recordings which are of a much better quality than mine and therefore more suitable for analysis. According my friend, this network was set up around March-April 2022 and is well audible in our area since the network is presumably deployed in the south-east of Europe.

Fig. 1 - wideband transfers

Waveforms, durations and signal sequences in my opinion point to Harris devices: they have in fact developed and implemented  a wide band ALE (WBALE) adaptive system that selects the best channel, the available bandwidth and the frequency offset required for optimal wideband communications [1]. As I already mentioned in some blog posts, Harris WBALE relies on 3G-HF STANAG 4538 Fast Link Setup (FLSU) to establish a wideband link:

- the calling station first places a call using STANAG 4538 FLSU to exchange profiles of the two linking radios’ and and negotiate a traffic waveform
– the standard FLSU Request PDU has a traffic type parameter; Harris uses a new value of this parameter (reserved but not defined in  STANAG 4538: see table 4.6.1-2 "second 6-bit argument field") to indicate that a wideband link is to be established
- the radios then use an additional handshake (not defined in STANAG 4538) to negotiate bandwidth and offset (from the assigned frequency, see figure 1) to be used, based on the results of the preceeding "spectrum sensing"  (1).

Figure 2 shows the timing diagram of all the signalling required for the Harris WBALE protocol: the timing diagram follows the one described in 188-141D App.G, even if the used waveforms are different!

Fig. 2 - wideband session timing and real-world wideband transfer

 

Traffic is exchanged using Harris proprietary WHARQ waveforms family, quite well recognizable by their "superframe" consisting of a STANAG-4538 BW6 preamble followed by 8 frames each characterized by a different miniprobe pattern.  An ACK PDU is transmitted by the receive station using a BW6 burst waveform. Figure 3 shows the main parameters of the WHARQ 2400 Bd 3-KHz bandwidth waveform.

Fig. 3 - WHARQ 2400 Bd 3-KHz bandwidth waveform

As I titled, the problem lies in the fact that one of the WB channels occupies about 12 kHz of the low part of the 7 HAM MHz band. It must be said that the 7 MHz band is primarily assigned to radio amateurs, however also shortwave broadcasters and land mobile users have primary allocations in some countries so amateur stations must share bandwidth with these users. 

The choice of the 7 MHz for such milcomms is probably related to the "primary and secondary users" concept [3] which divides the users into primary users (licensed) and secondary users (unlicensed): the first “own” the bandwidth allocation while secondary users are only allowed to use this spectrum in a non-interfering basis:

a) for WBALE primary user mode, stations that link for the purpose of transferring data will use a bandwidth and offset in each direction that is chosen to maximize the signal-to-noise ratio (SNR) with which transmissions in each direction are received. Stations will avoid interference with other stations within the same network, but will make no effort to prevent interference with other stations outside the network, except as a byproduct of optimizing communications within the network.  This can have at least two significant implications:
1. the bandwidth and offset used in each direction of the link may be different;
2. the stations may cause harmful interference to communications in other networks while themselves not experiencing harmful interference. 

b) in secondary user mode, WBALE stations will not (as far as is practical) cause interference to other stations outside the network that are operating within the same channel allocations used by the network. In particular, whenever a link is established for a wideband data transfer, the bandwidth and offset used for the link will be chosen so as to avoid interference with any transmission detected by either side. This is likely to require that the same bandwidth and offset be used in both link directions.  

As you may see in figure 1, the bandwidth and offset used in each direction of each logical link are the same, threfore, in my opinion, it seems that they use this portion of band (7 MHz) in secondary user mode.

Fig. 4 - a Rockwell Collins modem performing the spectrum sensing (2)

(1) To effectively utilize the allocated bandwidth, WBALE will need to listen to an entire wideband channel of up to 24 kHz, detect the presence of interfering signals on the channel that could render all or part of the channel unusable, and identify any portion of the channel that may still be usable even if the channel is partly blocked. This function is referred to as "spectrum sensing".

2) Initial Wideband ALE developing and testing was condected togheter by Harris and Rockwel Collins.

 

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

 

[1] https://disk.yandex.com/i/69TapvtM0Z0G-A
[2] https://i56578-swl.blogspot.com/search/label/WBALE

[3] William N. Furman, John W. Nieto, Eric N. Koski: The 10th Nordic Conference on HF (2013)

 

HARRIS PSK8 2400 Bd Digital Voice, an autobaud waveform?

Discussing with my fiend ANgazu about the HARRIS Digital Voice waveform (see this post), it turns out that likely that waveform is designed to provide the autobaud feature which is coded - in our opinion - in its initial header just before the normal frames' structure. As shown in figure 1, the "presumed" autobaud header consists of 8 frames each with a duration of 13.3 ms and a length of 32 bit (given the PSK2 modulation at 2400 Bd) for a total length of 256 bit. The synchronization functions would then be performed by the preamble sequences which are transmitted every 106.6 ms.  The autobaud function it may be necessary  since, according to the RF-5800 data sheet, the narrowband digital voice mode may use MELP and LPC-10 algorithms at 2400 and 600 bps.

Fig. 1 - the presumed autobaud header

Moreover, looking at the bitstream of an entire session (figure 2) it can be argued that the shorter segments are used for the management of the voice-link (ARQ mode); selcall, link setup and link closure are performed by the HARRIS specific waveform.

Fig. 2

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