12 December 2018

XMPP over HF radio using STANAG-5066

(updated)

Interesting transmissions spotted on 4381.0 KHz and 4833.5 KHz (all usb) consisting of MIL 188-110A Serial HF waveform (fixed 600bps/S) and 6-bit code clear text (6x28) & STANAG-5066 as bearer for XMPP Multi-User Chat (MUC)  messages.
XMPP, the Internet Standard eXtensible Messaging and Presence Protocol, is the open standard for Instant Messaging (IM), Group Chat and Presence services. XMPP is widely used for military deployments, where operation over constrained and degraded networks is often essential, particularly for tactical operation. 
Multi-User Chat (MUC) is a central service for military communication. If data is being provided, it makes sense to share it so that all interested parties can see it. For example, it will enable external strategists or lawyers to observe communication in real time, and provide input as appropriate. It often makes sense to share information in the field, for example a group of ships jointly working out who will target what and how. MUC is an important operational capability. 
In XMPP a client connects locally to its server, and then there are direct server to server connections (S2S) to support communication with clients on other servers. The mapping of XEP-0361 (Zero Handshake Server to Server Protocol) onto STANAG-5066 is standardized in "XEP-0365: Server to Server communication over STANAG-5066 ARQ”. XEP-0365 is mapped onto the S5066 SIS and transferred using RCOP protocol.
The 6-bit text and S5066 bitstream (Fig. 1) is obtained after demodulating the 188-110A Serial waveform:
 
Fig. 1
S5066 peers have the addresses 010.050.066.001 and 010.050.066.003 (odd) in 4381.0 KHz channel; the addresses 010.050.066.002 and 010.050.066.004 (even) are used in the 4833.5 KHz channel. These are probably "exercise" addresses since the block 10.50 is allocated to Uganda. 
These transmissions have been monitored for about one day so I could collect hundreds of messages, only some of them are shown below as examples: you can see groupchat messages, Instant Messaging (private messages) and Presence/IQ messages. My friend and colleague Guido @decodesignals logged same transmissions (and same addresses) on 4613.0 Hz, in his catches the S4539 4800bps is used as the HF waveform.

<message
    from='latency.ground@ground.net/2aad61419fb06287'
    to='latency.p8-one@p8-one.net'>
    <body>
    (a3d5bb51-70c3-4152-9a29-ab7cddbb47a3; 20181207T224101.034169)
    Test Message H - Private Message From GROUND Latency Acct
    </body>
    <securitylabel xmlns="urn:xmpp:sec-label:0">
    <displaymarking bgcolor="green">UNCLASSIFIED</displaymarking>
    <label/></securitylabel>
</message>

<message
    from='mission-one@chat.ground.net/LATENCY_GROUND'
    to='mission-one@chat.p8-one.net'
    type='groupchat' id='fmucinte54838a0b2804718'>
    <fmuc xmlns='http://isode.com/protocol/fmuc'
    from='latency.ground@ground.net/8f9f7ba5ca23d374'
    sync_stamp='2018-12-07T22:44:52Z'/>
    <body>
    (29f06ec4-a4a9-4849-bd46-42c54efa42ea; 20181207T224452.309137)
    Test Message T - MUC From GROUND Latency Acct
    </body>
    <securitylabel xmlns="urn:xmpp:sec-label:0">
    <displaymarking bgcolor="green">UNCLASSIFIED</displaymarking>
    <label/>
    </securitylabel>
</message>

<iq
    from='mission-one@chat.ground.net/LATENCY_GROUND'
    to='mission-one@chat.p8-one.net/Supervisor Air'
    type='get' id='d98686c2-d66f-4bdc-9b4e-ceb9911c834e'>
    <query node='http://swift.im#3ScHZH4hKmksks0e7RG8B4cjaT8='
    xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<presence
    from='mission-one@chat.ground.net/LATENCY_GROUND'
    to='mission-one@chat.p8-one.net/LATENCY_GROUND'
    id='fmucint0e52f98befac3522'>
    <fmuc xmlns='http://isode.com/protocol/fmuc'
    from='latency.ground@ground.net/8f9f7ba5ca23d374'/>
    <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence
    from='mission-one@chat.p8-one.net/LATENCY_AIR'
    to='mission-one@chat.ground.net/LATENCY_AIR'
    id='fmucint0572337e8aafbad5'>
    <fmuc xmlns='http://isode.com/protocol/fmuc'
    from='latency.p8-one@p8-one.net/f5ac7b83c2cc6951'/>
    <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

A bit of intelligence gathering can be done by the reading of the messages and from TDoA.
Direction finding  is not easy since the transmissions originate from two different sites, however the results obtained indicate UK as the area of operations (Fig. 2): maybe UK MoD?
Fig. 2 - TDoA result
The namespace attribute fmuc xmlns='http://isode.com/protocol/fmuc can be a clue of the use of the M-Link software developed by Isode for XMPP [1]. By the way, reading some Isode documentation available in the web you can see odd 10.x.y.w S5066 addresses like the ones used in the heard transmissions (Fig. 3)

Fig. 3 - from XMPP5066EVAL.pdf by Isode
Servers names and nodes names as: mission-one@chat.ground.net/LATENCY_GROUND and mission-one@chat.ground.net/LATENCY_AIR, as well as the Test Message format suggest a test phase aimed to measure the latency of air and ground links. Note also that the tests are performed using different HF waveforms: MIL 188-110A Serial 600bps and STANAG-4539 4800bps.

That being said, probaby these are UK MoD test transmissions concerning (Isode) XMPP over HF radio but it's only my guess. Ropey @Topol_MSS27 suggests that "maybe P8 (chat.p8-one.net) is a clue and references new ops for upcoming P-8A's due to join RAF from Nov next year" [2].

12 December update
My friend Martin G8JNJ, owner of the http://southwest.ddns.net:8073/ KiwiSDR, reports he heard synch'ed transmissions on 4381.0 KHz and 5505.0 KHz too, all usb. His TDoA runs point to Inskip (Former RNAS Inskip), a transmitting site of UK DHFCS located in Lancashire, North England: it confirms my TDoA and is a further clue in favor of RAF operations.

(a lot of documentation is publicy available in the web about ISODE XMPP, google is your friend) 
[2] https://www.raf.mod.uk/aircraft/p-8a/ 

CIS-79 "TANDEME" OFDM 79-tone


CIS-79 "tandem", OFDM 79-tone spotted on 10790.0 KHz/usb with bad SNR value. The signal is formed by 80 sub-carriers but the higher one (#80) is zeroed and unmodulated. The waveform uses QAM-64 modulation at symbol-rate of 30.5 Baud and 37.5 Hz channel step. No ACF value (=0) has been detected. Each symbol lasts 315 samples (256 +59). 
Note that a "control/service" symbol is sent each three tones using BPSK (Fig. 2): this feature was also commented here but in that case PSK-8 modulation is used. The signal was resampled at 9600Hz before to be analyzed.

Fig. 1

1 December 2018

STANAG-5065 MSK300, LF shore-to-ship surface broadcast

Nice catch of a STANAG-5065 MSK300 signal picked up by a colleague using the Alicante Kiwisdr on 145.0 KHz. By the way, we wish here to thanks the owner of Alicante kiwisdr for his kindness allowing the use of his sdr uninterruptedly for long periods.
The signal is transmitted from Guardamar de Segura in Spain (also known as "Torreta de Guardamar" [1]) currently operated by the Spanish Infanteria de Marina to convey messages to submarines. The use of the S5065 Low Frequency MSK300 waveform (surface broadcast) and the "mission" of Guardamar site, suggest that these transmissions could be intended for surfaced submarines or submarines cruising at periscope depth.  
 
Fig. 1- TDoA results (left), Tx location obscured by Google Earth (right)
While other broadcast stations for submarines such as DHO38 or NSY transmit continuously, Guardamar only transmits if there is traffic to send, and, since the low bandwidth that characterizes the LF band, transmissions may last for some more than an hour. Most likely the Thales TRC 2556 VLF/LF digital multi-channel receiver is used aboard [2].

As said, the S5065 MSK 300Bd/150 is the used waveform:

Fig. 2 - MSK 300Bd/150Hz waveform
Messages use 7-bit START-STOP ITA2 (Baudot) code which is then encrypted using the KW-46 crypto equipment (KWT-46 transmitter and the KWR-46 receiver hase the code name Vallor). Encryption results in bits 1 to 6 being encrypted and bit 7 (STOP) being replaced with a deterministic unencrypted Fibonacci bit defined by the polynomial x^31+x^3+1 which provides synchronization to the receive KW-46 equipment. 
In MSK300 mode the encrypted data from KW-46 are coded into a (13,12) Wagner error coding scheme and then applied to the MSK modulator (as seen here, processing for STANAG-5065 FSK operations does not include Wagner encoding). As shown in Figure 3, the encoding includes blocking the information into 2 character groups, substituting a parity bit for every second Fibonacci bit to form a (13,12) Wagner odd parity code block (odd numbers of 1s) over 12 informations bits (Fibonacci bit excluded).

Fig. 3 - (13,12) Wagner encoding of KW-46 encrypted stream
In MSK modulations the intelligence is contained in the phase shifts and is not consistent with the frequency shifts, thus the signal can't be demodulated using a generic FSK demodulator.

Fig. 4 - MSK300 phase-plane (before equalization)
After some unsuccessful demodulation attempts I asked my friend Christoph Mayer for help, he too checked the S5065 waveform and kindly sent me an MSK demodulator written by him and re-coded for Octave. The results of the analysis of the modulated stream, shown in Fig. 5 after left shifted, perfectly matches the schema of Figure 3.

Fig. 5 -  S5065 MSK300 stream after demodulation
It's very interesting to note that both the sequence obtained with n F-bits and that obtained with n/2 (n/2 -1) F-bits are attributable to the same polynomial x^31+x^3+1, my guess is that this feature maybe helps the initial synchronization of the FEC process detecting the position of the Wagner odd parity bits.




25 November 2018

8-ary constellation bursts at 12800bps data rate (2)

Some other observations and updates about the S4539 12800bps 8-ary constellation already discussed here: this post was possible thanks to the collaboration of my friends AngazU, Christoph, Martin G8JNJ, and Sergio.

As shown in Figure 1, the polarity of mini-probes matches the 12800Ubps (6,6,2) setting so no doubt about the proper operation of the used decoders, primarily the Harris RF-5710A model.

Fig. 1a) 287 symbols preamble and sync sequence (red);
Fig. 1b) the actual "6,6,2" setting read from the preamble;
Fig. 1c) the theoretic "6,6,2" setting

Now look at the on-air symbols shown in Fig. 2: S4285 symbols (Fig. 2a) are exactly mapped to a PSK-8 constellation but the S4539 symbols being analyzed occupy different points (Figs. 2b,2c). It looks like a subset of the QAM-64 symbols is used for data  while the 4 "circled" points are the QPSK symbols of the mini-probes. Thus, since no interleaving and no coding are used in 6,6,2 mode (12800bps), the source data must be prepared such that after the scrambling the resulting 6-bit numbers will be mapped only to a 8-point subset of the QAM-64 outer ring. This makes sense and clarify the 12800bps speed, though we do not figure out why this is done.
 
Fig. 2
Figure 3 shows the plots of one frame obtained by Christoph: 256 data symbols + 31 mini-probe symbols: the 31 mini-probe symbols were descrambled and are at I=1,Q=0. As you can see the other points fit perfectly the 8 out-of-20 points of the QAM-64 outer ring [7 3 24 56 35 39 60 28].

Fig. 3 - 256 data symbols + 31 mini-probe symbols
These eight symbols have interesting structure: the 3,7,24,28 symbols are the same of  35,39,56,60 unless the left-most bit and they are at the same distance (32)

 3 000011
 7 000111
24 011000
28 011100

35 100011
39 100111
56 111000
60 111100

According to Christoph, the 6 bits are ABBCDD where ABC identify the point and D+B=1 mod 2. The ABC bits stream exhibit a 480-bit leghth period (Fig. 4).

Fig. 4
Back to the transmissions, our monitoring revealed that the entire sequence lasts about 36 seconds and consists of 6 "clusters", or "sets", each consisting of three channels with same spacing and arrangement:


Lately, our friend Martin G8JNJ noticed in the lower cluster A1 A2 A3 one weaker set (TDoA 100% St Eval) every 30 seconds (approx) and one set of stronger ones every three to five  minutes (approx) which he wasn't able to TDoA. "So that I think I'm hearing more than one transmitter site. It's proving to be very difficult to TDoA the second one, as they transmit much less frequently, but there is a big difference in RX signal strength between the transmissions", Martin says.
A friend of AngazU suggested that they could be developing some kind of turbo equalizer or similar. These emissions would be tests of a  training sequence and they would be measuring errors, convergence time and other parameters under different conditions. Just a guess, if they  succeed, we will see the  full constellation.

By the way, subjecting for example the F1 channel to the k500 decoder it prints out only 1536 decoded bits although it correctly recognizes the 12800U setting. As shown in Figure 5, each burst is made up of 13 frames for a total of 256x13=3328 QAM-64 data symbols that make 3328x6=19968 bits of data! (no interleaving neither coding is used in 12800U mode). Thus it seems that only one data frame (256 x 6) is processed by k500 (possibly the first one?): maybe it's a decoder limitation due the short burst duration? Note that it does not happen when I use the RF-5710A modem.

Fig. 5
(to be continued)

23 November 2018

WINB Red Lion to test DRM Single Channel Simulcast (SCS)

(updated)
Shortwave station WINB has recently started conducting test in DRM directed to Europe on 15670 kHz Monday - Friday from 11:00 -17:00 UTC using a new DRM 18 Kw transmitter, an ASI CE-50000WS, and Rhombic antenna at 062 degrees, according to WINB’s own website. The signal can be received by several KiwiSDR receivers in Europe, as well as by the N4LGH KiwiSDR located in Florida which has the signal from the back of the beam (Fig. 1).
My friend F4MP "Zyg" emailed me kindly asking to take a look at those "combo" test signals, given that DRM  is only located in the upper 5 KHz sideband of the channel.

Fig.1 - my reception of WINB DRM tests from N4LGH KiwiSDR

Datacast rather than simulcast? 
As from ETSI TS-102-509 V1.1.1, strictly the term simulcast can be taken to describe a transmission allowing the simultaneous transmission of analogue and digital versions of the same audio programme in one frequency channel (Single Channel Simulcast, SCS). A simulcast signal signal consists of a sinusoidal carrier and two additional signal parts in the upper and lower sideband. The digital part in the upper sideband corresponds to a DRM signal, therefore a standard DRM consumer receiver will be able to extract and decode the included digital data. An analogue audio AM receiver applying envelope demodulation on the overall received signal will provide an audio signal to the listener comparable to standard AM transmission. [1] [2]
Clearly, that's not the case of WINB. Moreover, due to the fact that multipath propagation via the ionosphere is a typical characteristic of radio channels in HF broadcasting, the use of SCS is recommended only for LF and MF bands with mainly ground wave propagation.

So, what is carried by the lower sideband of the signal?
Nobody knows with certainty, at least at present when I'm writing this post. Interesting discussions on WINB DRM test transmissions can be read in the DRM Forum as well as in w4uvh site:
Oddly, on DRM Forum nobody associated with WINB has commented on the simul/datacasting although they have made several posts regarding the DRM broadcast.
 
Looking at FCC license for these tests we note the 10K00G9W emissions designator for the CE-50000WS transmitter beamed to north Europe (Fig. 2):

Fig. 2 - FCC license
10K00G9W designator means that WINB may transmit:
10 k = 10 kHz signal bandwidth
G = phase modulation
9 = Analog and digital channels
W = any combination of telegraphy, fax, data, telephony or video

so the license offers the chance to transmit digital signals or ordinary AM signals.
Analyzing the lower sideband of the signal I may count up to 78 unmodulated tones that could be MFSK as well as constructed using OFDM tecnology, in this case the tones have rotated phases. Likely it's a test/experimental transmission w/out data carried.
Fig. 3
Fig. 4
31 October update
I have a little but important update: some days ago I heard WINB DRM signal at my QTH on 13690 KHz, surely due to good propagation conditions. I twitted a little post and WINB answered asking a report about that reception. The most important fact is that they confirmed data transmission o the lower 5 KHz channel.


23 November update
First time, at least at my side, that I hear their emissions on 9265.0 KHz in the morning: a bit unusual band (30mt) since the time (0930 UTC). Maybe they are testing the "service" in different bands?



21 November 2018

two interesting MFSK catches

1) MFSK-66 (33+33) 40Bd/40 (presumed)
Transmission heard on 9122.0 KHz/usb on 20 November, 0832z. It looks like they use 2-tones x symbol and a manipulation speed of 40 Bd (Fig. 1). Dividing the spectrum into two equal parts gives a grid of 33 tones, 40Hz spaced, with the expected symbol rate of 40Bd (Fig. 2): this is why I defined the signal as MFSK 33+33 40Bd/40Hz, but I could be wrong. Likely Russian users.


Fig. 1
Fig. 2
Fig. 3

2) 19KHz wide MFSK-17 33.3Bd/1200Hz
Transmission heard on 13386.0 KHz/usb (centered on ~ 13397 KHz) on 20 November, 1156z. Never meet a such wide band MFSK waveform.


Fig. 4
Fig. 5

 

16 November 2018

email over hf using FED-1052 DLP and "IDEA" encryption (2)

Yet another interesting catch of an email-over-hf session using FED-1052 Datalink Protocol (DLP, Appendix B) and IDEA encryption. The transmission was recorded on 09187.0 KHz/usb 1357z: encrypted MIL 188-141A 2G-ALE to set up links and switch to MIL 188-110A serial tone waveform for emal traffic via FED-1052 App.B DLP (Data Link Protocol); ASCII-7 data are encrypetd using CFB64 "IDEA" algorithm. Headers are unencoded so you can read both the sender and recipient, in this sample:
sender: ZJ1, root@bfzj1f1.is.bf.intra2.admin.ch
recipient: ZA1, statist@bf.intra2.admin.ch
email ID: "stat-ZJ1-20181113135501" (2018.11.13, time: 135501)
The FQDN (Fully Qualified Domain Name) "intra2.admin.ch" indicated in the e-mail addresses suggests an intranet of the central administration of the Swiss Federation: likely this is the Swiss Army or the Diplo Service.
A more detailed post about such transmissions can be read here.

Fig. 1 - on air signals, MIL 188-110A Serial Tone waveform
Fig. 2 - FED-1052 App.B stream


7 November 2018

IP over HF via STANAG-5066 RCOP, MIL 188-110A as HF waveform

Interesting transmissions spotted on 9105.0 KHz/usb at 1240z, user/locations are unid, maybe form US-Mil stations? The transfer concerns IP-over-HF (IPoHF) via STANAG-5066 RCOP protocol [1]: 1380 bytes IP packets are exchanged in directions 192.168.2.48 -> 192.168.12.48 and 192.168.1.48 -> 192.168.14.48 , ESP (IPSec) secure protocol is used.  MIL-STD 188-110A Serial is used as the HF waveform. STANAG-5066 Addresses (001.003.003.103 001.001.001.101) belong to US-DoD. Similar transmissions was heard on 8th October on 13378.0 KHz/usb using 188-110A and S4539 QAM-64 as HF bearers (discussed here) maybe the user is the same.
The sequence of the figures illustrates the various steps that have been performed in the analysis of the signal.

Fig. 1 - 188-110A on-air symbols
Fig. 2 - STANAG-5066 bitstream after the removal of 188-110A overhead
Fig. 3 - hex-dump after the removal of STANAG-5066

The hex-dump file resulting after the removal of STANAG-5066 PDUs encapsulations has been processed using "wireshark" software: IPv4 addresses and headers as well as IPSec encapsulation are clearly visible.

Fig. 4 -


https://yadi.sk/d/wuBIWQ_HSwVRMA
https://yadi.sk/i/6p-izzJatalVwg
https://yadi.sk/i/ulK473q0E2rCNw

[1] https://www.isode.com/whitepapers/ip-over-stanag-5066.html

https://yadi.sk/i/6p-izzJatalVwg

3 November 2018

two interesting FSK catches: 74.5Bd /250 and 75Bd/200

1) FSK 74.5Bd/250
Some FSK 74.5Bd/250 short transmissions (Fig. 1) have been heard on 11018.0 KHz (CF) sending the same seven bits pattern in postive and in negative polarity (Fig. 2). Since the short transmission time I coould not DF the transmission site.

Fig. 1
Fig. 2
 FSK 74.5Bd/250

2) FSK 75Bd/200
The FSK 75Bd/200 (Fig. 3) is a continuous transmission that can be heard on 8408.0 KHz (CF), most likely an encrypted broadcast (shore-to-ship ?). Several TDoA runs point to the West Mediterranean sea area: the Tx location could be Algeria or Balearic Islands (Fig. 4).

Fig. 3
Fig. 4

The demodulated bitstream does not exhibit ACF spikes (ACF = 0) after normal and differential decoding and can be descrambled using the polynomial x^8+x^6+x+1 but without appreciable results.
A similar transmission (FSK 75Bd/200) was heard on 11 Jan 2018 on 4540.0 KHz. In that case, after differential decoding, the stream showed up a clear 365-bit period (Fig. 5) which is due to the sequence of the scrambler polynomial x^7+x^6+1. The descrambled stream is shown in Figure 6 (thanks to cryptomaster).

Fig. 5
Fig. 6

1 November 2018

(some) October logs


06205.0: ELETTRA11: Italian Ny, I 0822 USB/J3E radio-check with IBIS11 (11Oct18) (AAI)
06690.0: BD9: Unid (Moroccan-Pol ?) 0632 USB 188-141 2G-ALE calling T4N (24Oct18) (AAI)
06733.0: 6628: Ascott-6628 RAF USB 1007 J3E/USB requesting wx reports to TASCOMM for LFLL, LFMN, LICJ, LMML (20Oct18) (AAI)
06922.0: ---: Unid 0824 USB 3G-HF 2-way FLSU handshake / LDL96 transfer,83 bytes 'Citadel' encrypted file (11Oct18) (AAI)
06931.0: ---: Unid (prob from Croatia) 0828 USB STANAG-4285 600bps/S, 2 stations exchanging 128-bit MI encrypted msgs (11Oct18) (AAI)
07559.0: ---: Unid 0715 USB 3G-HF FLSU handshake / HDL24 transfer (24Oct18) (AAI)
07606.0: ---: Unid 0910 USB NILE/Link-22, STANAG-4539 TDMA Waveform #2 (09Oct18) (AAI)
07625.0: ---: Unid 2150 ISB Link-11 CLEW (30Oct18) (AAI)
07856.0: SE3: Polish-Mil, POL 1034 USB MIL 188-141 2G-ALE calling EM4 (31Oct18) (AAI)
07961.0: 32X: Unid 0748 USB 188-141 2G-ALE calling DRX (22Oct18) (AAI)
07961.0: 32X: Unid 0749 USB 188-141 2G-ALE calling DRY (22Oct18) (AAI)
07961.0: FAY: Unid 0638 USB 188-141 2G-ALE calling DRX (24Oct18) (AAI)
08086.0: NX10: Algerian-Mil, ALG 0900 USB 188-141 2G-ALE handshake KB23 / MIL 188-110A Serial (20Oct18) (AAI)
08132.0: BP25: Bundes Polizei patrol vessel "Bayreuth", D 0835 USB 188-141 2G-ALE handshake BPLEZSEE HQ / GM2X00 HF modem serial waveform, updating GPS position (23Oct18) (AAI)
08162.0: 093: Hungarian Defense Forces, HNG 0755 USB 188-141 2G-ALE calling 035 (22Oct18) (AAI)
08190.0: --- : Unid 0645 USB 3G-HF HDL+ transfer (18Oct18) (AAI)
08190.0: CAPPELLETTI: GdF Patrol Boat Cappeletti G094, I 1005 USB 188-141A 2G-ALE handshake ROMA, sending email using R&S PostMan II and X.25 over GM2100 modem (11Oct18) (AAI)
08218.0: ---: Unid 1720 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (03Oct18) (AAI)
08677.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0725 USB PSK-2 48000Bd waveform, 576-bit period (16Oct18) (AAI)
08684.5: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0742 USB BPSK/QPSK 2400Bd waveform (11Oct18) (AAI)
08722.0: AB1: Maltese Navy, MLT 1745 USB 188-141A 2G-ALE calling EB7 (03Oct18) (AAI)
09120.o: PP7: Polish-Mil, POL 1152 USB 188-141 2G-ALE calling ML2 (23Oct18) (AAI)
09162.0: ---: Unid 1204 USB 3G-HF FLSU handshake / LDL448 transfer, 859 bytes 'Citadel' encrypted file (23Oct18) (AAI)
10185.0: MIRADOR2: Unid 1417 USB 188-141A 2G-ALE sounding (06Oct18) (AAI)
11118.0: ---: Unid 0607 USB (offset + 1500Hz) Siemens CHX200 F1-modem (CHP-200) FSK 249Bd & 250Bd/170Hz, selcall mode (10Oct18) (AAI)
12194.0: CM6: Commandement de la 6e Région Militaire Tamanrasset, ALG 0638 USB 188-141 2G-ALE calling TIN (18Oct18) (AAI)
12457.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 1340 USB 6KHz WideBand PSK-2 4800bps waveform (14Oct18) (AAI)
12780.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0810 USB 18KHz WideBand PSK-2 19200bps waveform (14Oct18) (AAI)
13378.0: ---: Unid 0848 USB MIL 110A & STANAG-4539, STANAG-5066 IP-over-HF sessions (01Oct18) (AAI)
17398.2: ---: DHFCS Cyprus Is. Overseas Stn 1120 USB STANAG-4285/1200bps 1536-bit TDM protocol (prob. DRS GA-205 multiplexer) (28Oct18) (AAI)