Quantcast
Channel: diario SWL I-56578 Antonio
Viewing all 623 articles
Browse latest View live
↧

a 3G Multicast Data Link w/ NAKs?

February 19, 2017, 6:20 am
$
0
0

few days ago, 16 Feb, I copied a 3G-HF transmission on 10958.0 KHz/USB consisting of an initial FLSU PDU (BW5 burst) followed by 13 not-ACKed LDL PDUs (BW3 bursts) and ending with a single BW4 burst: this scenario recalls the 3G Multicast Data Link with NAKs (MDLN) protocol previously copied and reported here (Fig. 1).

Fig. 1
I could not find official NATO/Stanag documentations about the 3G Multicast but only some "proposed" papers; Multicast MDL Protocol is still cited as "still in development" in STANG-4538 Amendment 2 Draft 0.3, the one at my disposal, thus the following are my suppositions based on the clues which I can see, so, comments are welcome (after all, this blog is just a collection of notes by a digital signals enthusiast and amateur analyst and does not claim to be a scientific blog).

Multicast Data Link protocol (MDL/MDLN) shares many of the characteristics of the other 3G data link protocols but unlike the 3G ARQ protocols, MDL links employ the one-way link setup: each transmission begins with an TM,  FTM or FLSU PDU that indicates the MDL mode that will be used in the remainder of the transmission.
The MDL_Data PDUs use the BW2 and BW3 burst waveforms used in HDL and LDL: in this case the MDL-288, a stream of 288-byte bursts, is used (as known the BW3 data section can be any multiple of 32 bytes, from 32 up to 512 bytes).
Fig. 2 - BW3 frame
The transfer ends with a BW4 burst, Fig. 3, most likely acting as MDL_EOM PDU (any PDU sent using BW4 in the forward direction is an EOM PDU).

Fig. 3
Sending an FLSU_Terminate would impose a triple demodulation requirement on the receiving stations (they do not expect BW5 bursts) thus, as it happens in LDL transfers, the calling station sends an MDL_EOM PDU (BW4 burst) to signal the receiving stations that the datagram has been transferred, and hence will send no more MDL_Data PDUs for the current datagram.  MDL_EOM PDU would use BW1 burst in case of MDL-5k (HDL BW2 used for MDL_Data)?

Once demodulated, the received datagram transports Harris Citadel off-line encrypted messages (Fig. 4) 

Fig. 4


↧
Search

chasing HAARP

February 24, 2017, 5:57 am
$
0
0
photo from Chris Allen twitter account
On 19-22 February, scientists used the HAARP (High-frequency Active Auroral Research Program) research instrument to conduct multiple experiments, including the so-called "Luxembourg Broadcast" and creation of "Artificial  Aurora". Radio listeners  were able to tune HAARP radio transmissions in real time by following Chris Fallen, Assistant Research Professor in the Space Physics Group at UAF, on twitter during his experiments at HAARP. 
I too tried to  follow the HAARP transmissions on 21 and 22 February and other than a fake transmission I had also a copy, or better a "track", of the 22 February Artificial Aurora transmission: short report follows below.

21 February,  a fake transmission
The alarm clock rings at 0300 UTC (0400 CET), just a coffee and then in front of the radio hoping to catch the Luxembourg Broadcast scheduled for that session/time. Propagation is quite good and I tune alternately to 2.8 and 3.3 MHz (the advertised frequencies), although both the frequencies are under my eyes in the portion of the band displayed in the SDR waterfall. Since the exact frequencies of the transmissions are not known until shortly before the experiment begins, I follow the operational updates published in @ctfallen, a special twitter account.
Looking for the Luxembourg Broadcast on 2.8 and 3.3 MHz, at 0314 UTC I copy a short CW transmission on 2.8, repeated few seconds later on 3.3 MHz (Fig. 1). The Morse coded message is the bare "vvvvv de haarp" which exhibits a wrong keyd "p" (uh?). The too-simple message, the not uniform separation between tones, the wrong "p" and the HAM style of the keyer make me think of an European "joker" and thus of a fake transmission!
I send images and recordings to Chris Fallen and his team, warning about a possible fake transmission by some European joker: they oddly confirm the reception, but after further analysis they realize that the copied transmissionwas really a fake (as supposed).

Fig. 1 - the 21 Feb 0314UTC fake transmissions

22 February,  Artificial Aurora transmission
Too tired to wake up early in the morning, I choose for an off-line listening and program SDR-Consolefor a timed IQ recording starting at 0330 untill 0500 UTC 22 February.In the afternoon I analyze the file and, given the propagation conditions and the HAARP antennas beam, I decide to read the recordered band using the powerfull QRSS viewer by I2PHD ("Argo").Since the need to know the exact frequencies, as said, I browse the 22 February operational updates in @ctfallen. Indeed, for Artificial Aurora experiments they have to match the frequency to the specific peak plasma density altitude by operating a low power scanning ionosonde and then pick the main transmitter frequency based on the ionosonde analysis.
At ~0400 UTC Chris Fallen says:
3.4 MHz (and 9.5 MHz probe) tune in! If in Aalaska maybe try to photograph the artificial auroral spot"
here we are: using the IQ file navigator I move on 3.4 MHz @ 0400 UTC to dig the signal ...and I find it: although weak, a track of the Artificial Aurora transmission is visible just in the place and time at which it was to be.Quoting Fallen,  "the broadcast only sounds like a silent carrier wave, as if a radio DJ fell asleep and neglected to change the record" (Fig. 2). Note that the 1025Hz track in the QRSS waterfall is due to the 1 KHz offset (I was tuned on 3999.0 KHz/USB) plus the 25 Hz calibration error of my receiver.

Fig. 2 - the 22 February 0400 UTC Artificial Aurora transmission


Operation of the HAARP research facility, including the world’s most capable high-power, high-frequency transmitter for study of the ionosphere, was transferred from the U.S. Air Force to UAF in August 2015. Research funding agencies include the National Science Foundation, Department of Energy’s Los Alamos National Lab and the Naval Research Laboratory.

For more details on the dates and times of Fallen’s experiments, as well as information, visit:
Information is also available at the HAARP website, the UAF:  
and the official UAF HAARP Facebook page:

Address from The SWLing Post page:
↧
↧

a new S4285-like waveform (most likely a new Iraqi waveform)

February 25, 2017, 3:07 am
$
0
0

The signal appears on-air as a PSK-8 modulation of a 1800Hz single tone, symbols rate is the quite usual 2400 Baud (Fig. 1). ACF is 120 msec, that makes 288 PSK-8 symbols per frame or a 864-bit length period (Fig. 2).

Fig. 1
Fig. 2
The structure of the frame resembles the well-known Stanag-4285 waveform: the initial 63 symbols preamble is followed by four data blocks, each block consisting of 51 unknown symbols (user data) and 7 known symbols (mini-probe); the last block is transmitted w/out the miniprobe (Fig. 3). As said, each frame is transmitted each 120 mesc.
Looking at the constellation, the two pronounced points lead to think to a BPSK modulated preamble which is probably not scrambled (just as in Stanag-4285) and use Walsh modulation (Fig. 4).

Fig. 3
Fig. 4

The recording was sent me by KarapuZ and his friends, translators have identified the language as Iraqi (sometimes voice comms were copied in between the data exchanges) and are inclined to think  to marine coast stations. Transmissions were copied on several USB frequencies such as 7997.0, 8228.0, 8250.0, 8458.0, 8613.0, 17380.0,...



↧

a possible variant of the CIS-48 OFDM modem

February 28, 2017, 6:06 am
$
0
0

This signal was copied on 9905.0 KHz/USB at 0922 UTC 22 February, although the poor quality of the recording (it mostlydepends on the signalweakness) some interestingcharacteristicscan be obtainedfrom its analysis.
Once the signal has been processed with a pass-band filter, the spectrum reveals the presence of 48 tones (Fig. 1) which are confirmed by the SA-OFDM module: in particular the 48 tones are 62.5 Hz spaced and are keyed at a symbol rate of 50 symbols/sec (Fig. 2); the "magic K" value is very good, ie 1/4, meaning a quite consistent result.

Fig. 1
Fig. 2
The poor quality of this sample does not allow to detect what kind of modulation is used in the channels (possibly 4-ary?) anyway it's possible to see that a special/service symbol, consisting of a certain combination of used/unused & modulated/unmodulated tones, is sent each 102 symbols (Fig. 3):

Fig. 3
The body of the signal is preceeded and followed by 6 tones, the initial ones are modulated with BPSK at 100 symbols/sec (Fig. 4)

Fig. 4
The CIS-48 OFDM modem is mentioned several times in radioscanner.ru forum and my friend KarapuZ, who helped in the identification, addressed me to one of his posts just related to CIS-48:
From these readings I may understand that some variants of this modem are on-air and most likely this is one of these: better and further recordings just of this signal, as well as your comments, would be needed.




 
↧

Logs

March 1, 2017, 1:22 pm
$
0
0

06550.0: R26573: US Army Helo 1336 USB MIL 188-141 2G-ALE hadshake RAPTOR followed by voice comms (11Feb17) (AAI)
06629.7: ---: Unid 0841 USB STANAG-4285 modem, 600bps/L KG84 encryption (11Feb17) (AAI)
06721.0: 170035: USAF C-5 #87-0035 1013 USB MIL 188-141 2G-ALE calling GUA - Anderson AFB Guam (11Feb17) (AAI)
06730.0: SPADA01: Italian AF, I 0833 J3E/USB radio-check with SFINGE (01Mar17) (AAI)
06771.0: A6C: Unid (Lithuanian net ?) 2029 USB USB MIL 188-141 2G-ALE calling C1A (16Feb17) (AAI)
06801.0: Z01: NPRD Zagreb, HRV 1314 USB MIL 188-141 2G-ALE sounding (11Feb17) (AAI)
06806.0: KA31: Algerian Military, ALG 0947 USB MIL 188-141 2G-ALE calling PY3 (11Feb17) (AAI)
06831.0: D20: HPRD-net Dubrovnik, HRV 1332 USB MIL 188-141 2G-ALE sounding (11Feb17) (AAI)
06831.0: E5X: RMZO/HPRD-net Zagreb, HRV 0902 USB MIL 188-141 2G-ALE sounding (11Feb17) (AAI)
06840.0: R24504: US Army Helo, Sikorsky UH-60A Black Hawk 1000 USB MIL 188-141 2G-ALE sounding (11Feb17) (AAI)
06902.6: KXV46: Unid US DoS stn 1036 USB MIL 188-141 2G-ALE calling KXV45 (27Feb17) (AAI)
06942.5: 0OE: Dutch Military, HOL 0832 USB MIL 188-141 2G-ALE calling DLNE (27Feb17) (AAI)
07071.0: PEM03D: Unid 1001 USB MIL 188-141 2G-ALE handshake PEM01D followed by short MIL 188-110A (rptd several times) (17Feb17) (AAI)
07102.0: F6EMT: Global ALE Net Paris, F 0755 USB MIL 188-141 2G-ALE sounding (01Mar17) (AAI)
07345.0: CAMP: prob. a Swiss net 0857 USB MIL 188-141 2G-ALE calling any station (@?@) (28Feb17) (AAI)
07390.5: ---: Unid 0940 USB MIL 188-141A 2G-ALE in Linking Protection mode (21Feb17) (AAI)
07421.5: CHFEDR: Greek Air Force, GRC 0757 USB MIL 188-141 2G-ALE calling IVRG1 (01Mar17) (AAI)
07421.5: CHFEDR: Greek Air Force, GRC 0759 USB MIL 188-141 2G-ALE calling LGSM1 (01Mar17) (AAI)
07421.5: CHFEDR: Greek Air Force, GRC 0803 USB MIL 188-141 2G-ALE calling RCLS1 (01Mar17) (AAI)
07460.0: 2417: Moroccan Civil Protection, MRC 0800 USB MIL 188-141 2G-ALE sounding (01Mar17) (AAI)
07467.0: PO1: Slovakian Military, SVK 0852 USB MIL 188-141 2G-ALE handshake PO2, voice comms (20Feb17) (AAI)
07479.0: ---: Unid 0705 USB (offset +1500Hz) Siemens CHX-200 selcall (24Feb17) (AAI)
07499.0: ---: Unid 2138 USB Arcotel MAHRS-2400 modem PSK-8 2400Bd in ARQ mode (23Feb17) (AAI)
07519.0: ---: Unid 0848 USB 3G-HF aync FLSU call w/ Linking Protection (17Feb17) (AAI)
07519.0: ---: Unid 0907 USB 3G-HF Circuit-Mode, FLSU w/ Linking Protection followed by MIL 188-110A (17Feb17) (AAI)
07519.0: ---: Unid 0955 USB 3G-HF 2-way FLSU followed by HDL traffic (21Feb17) (AAI)
07520.0: DA01: Algerian Military, ALG 0702 USB MIL 188-141 2G-ALE calling DA10, LQA exchange (24Feb17) (AAI)
07575.0: KB16: Algerian Military, ALG 0858 USB MIL 188-141 2G-ALE calling PY10 (14Feb17) (AAI)
07829.0: ---: Unid 0825 USB 3G-HF HDL+ traffic (BW6, BW7) (15Feb17) (AAI)
07840.0: DA01: prob. Algerian Military, ALG 0803 USB MIL 188-141 2G-ALE calling DA03 (14Feb17) (AAI)
07840.0: SUV: prob. Algerian Military, ALG 0832 USB MIL 188-141 2G-ALE calling ITY (14Feb17) (AAI)
07841.0: ---: Turkish Mil, TUR 0746 USB (offset + 1500Hz) FSK 600Bd/400Hz, sending two messages w/ KG-84C sync pattern (01Mar17) (AAI)
07845.0: DA01: Unid (prob. Algerian Military) 0829 USB MIL 188-141 2G-ALE calling DA02 (15Feb17) (AAI)
07898.0: 049112: German Red Cross, D 0818 USB MIL 188-141 2G-ALE sounding (01Mar17) (AAI)
07911.3: 50018: Unid 1728 USB MIL 188-141 2G-ALE sounding (01Mar17) (AAI)
08045.0: ---: Unid (prob. Bulgarian Diplo) 0833 USB RFSM-8000 modem with data-masking (15Feb17) (AAI)
08059.0: DA08: Unid (prob. Algerian Military) 0817 USB MIL 188-141 2G-ALE calling DA01 (15Feb17) (AAI)
08132.0: BP25: German Police vessel Bayreuth, D 1815 USB R&S X.25 login to BPOLBPLEZSEE_HF (BPLEZS) carried by R&S GM-2100 HF modem, link w/ MIL 188-141A 2G-ALE (19Feb17) (AAI)
08152.0: M02: Swedish Military, S 1719 USB MIL 188-141 2G-ALE calling SO1 (01Mar17) (AAI)
08152.0: M02: Swedish Military, S 1723 USB MIL 188-141 2G-ALE calling UO1 (01Mar17) (AAI)
08167.0: XSS: DHFCS Forest Moor, G 0810 USB MIL 188-141 2G-ALE calling XPZ (15Feb17) (AAI)
08174.0: KF01: Unid (prob. Tunisian Military) 1003 USB MIL 188-141 2G-ALE handshake with ND01 followed by half-duplex MIL 188-110 App.B OFDM 39-tone modems (15Feb17) (AAI)
08270.0: 194: Unid 1820 USB MIL 188-141 2G-ALE calling 130 (01Mar17) (AAI)
08277.0: ---: Chinese net, CHN 1645 LSB OFDM 30-tone bursts (01Mar17) (AAI)
08280.0: SHARK15: Unid (presumed Egyptian net, EGY) 1637 USB MIL 188-141 2G-ALE calling ST2 (01Mar17) (AAI)
08280.0: SHARK3: Unid (presumed Egyptian net, EGY) 1632 USB MIL 188-141 2G-ALE calling ST1 (01Mar17) (AAI)
08327.0: ---: Unid 1709 USB 3G-HF 2-way FLSU handshake followed by HDL-12 transmission, Harris Citadel off-line encryption (01Mar17) (AAI)
09025.0: JDG: USAF Diego Garcia AB, DGA 2012 USB MIL 188-141 2G-ALE sounding (28Feb17) (AAI)
09038.0: R26577: US Army Helo 1353 USB MIL 188-141 2G-ALE sounding (11Feb17) (AAI)
09169.0: 1005: Mauritanian Gendarmerie, MTN 2008 USB MIL 188-141 2G-ALE sounding (28Feb17) (AAI)
09219.0: A509: Unid (Israeli AF?) 0914 USB MIL 188-141 2G-ALE sounding (22Feb17) (AAI)
09273.5: ---: Unid 1014 (cf +1500Hz on USB) R&S ALIS 228.6:5Bd/170 calling address 219 (20Feb17) (AAI)
09905.0: ---: Russian Mil/Gov 0825 USB CIS-48 OFDM 48-tone modem variant (27Feb17) (AAI)
10958.0: ---: Unid 1558 3G-HF MDL traffic sending datagram with Harris Citadel encryption (16Feb17) (AAI)
11130.0: X2: Moroccan Military, MRC 1012 USB MIL 188-141 2G-ALE calling S41, LQA exchange (20Feb17) (AAI)
11186.2: ---: Unid 1413 USB 3G-HF FLSU followed by LDL BW4/BW3 traffic (23Feb17) (AAI)
11217.0: XSS: UK DHFCS, G 1026 USB MIL 188-141 2G-ALE handshake UKE304 RAF E3D awacs (20Feb17) (AAI)
11226.0: GUA: USAF AB Guam, GUM 1255 USB MIL 188-141 2G-ALE calling JTY Yokota AB Japan (18Feb17) (AAI)
11424.0: ---: Russian Mil/Gov, RUS 1022 USB CIS-45 HDR modem V1 33.3Bd 62.5Hz BPSK bursts (20Feb17) (AAI)
14460.0: ---: Russian Mil/Gov, RUS 0955 USB CIS-128, OFDM 64+64 tone modem 21Bd (27Feb17) (AAI)

↧
↧

single couples of Fast LSU PDUs: what is the scenario?

March 4, 2017, 3:01 am
$
0
0


Often, and on several frequencies, I noted isolated couples of Fast LSU PDUs (BW5 waveform) which exhibit the following characteristics:
1) since the strength of the signals, the bursts seem to be issued by the same station;
2) they are not immediately followed by traffic (circuit or packet);
3) in all the observed cases the time distance bewteen the two bursts is always the same, ie ~2212 msec (Fig. 1) as if there was a missing LFSU PDU in the middle (Fig. 2). It's worth noting that the time between a Request and a Confirm PDU is ~580 msec;

Fig. 1
Fig. 2
4) PDUs have inconsistent protocol field values, thus, unless decode errors, these are issued in Linking Protection mode.

That said, what scenario these couples of FLSU PDUs depict? 
I searched an answer in STANAG-4538 #5.1, which describes, by means of specific example scenarios, a subset(!) of the over-the-air capabilities provided by the FLSU protocol. According to these examples, the copied FLSU PDUs can be attributed to failed 2-way link setups (circuit mode) and to failed LQA exchanges. Other scenarios as the Broadcast TOD (Time Of Day) distribution are less probable since their specific format.  

a) failed 2-way link setup (circuit mode) 
Fig. 3a - failed 2-way link setup (circuit mode)
All two-way FLSU calls require only a request and confirm PDU transmission. A third transmission is issued only if the caller station does not correctly receive, or does not receive, a confirm PDU as expected (the empty place in Fig.1): in these cases, the caller station is required to transmit an FLSU_Terminate PDU.
If this were a packet traffic example, sending an FLSU_Terminate would impose a triple demodulation requirement on the receiving station. Thus, the calling station must send up to N “xDL_Terminate” (EOM)  PDUs to abort the ARQ protocol, ie a BW1 ACK for HDL and a BW4 ACK for LDL as in Fig. 3b (ACKs sent in the data forward direction are intended as EOM).  
Since this is a circuit traffic example, the “xDL_Terminate” PDUs is not necessary, and the calling station sends the FLSU_Terminate PDU immediately after the failed call response (as in Fig. 3a).

Fig. 3b - failed 2-way link setup (packet mode)

b) failed LQA exchange
Fig. 4
Many times I copied 2G LQA exchange requests w/ no reply sent by the called station e.g.:
11130.0: X2: 1012 USB MIL 188-141 2G-ALE calling S41, requesting LQA exchange, no reply 
and this could be a possible 3G scenario of such cases.
As said above,the basic exchange in FLSU is a two-way handshake: the caller sends a request PDU and the called station responds with a confirm PDU; if the caller station does not correctly receive, or does not receive, a confirm PDU as expected, the caller is required to transmit an FLSU_Terminate PDU.


c) Broadcast TOD distribution

Fig. 5

In a TOD Distribution scenario, the unsynchronized station transmits 1.35N Asynchronous FLSU_Req PDUs using the asynchronous calling technique described in this post. The FLSU_ Request PDU (with traffictype set to TOD) is transmitted once, at the end of the asynchronous calling period (Fig. 5). 
The Broadcast TOD distribution can be achieved by the net control station issuing both the TOD_Request and TOD_Response PDUs. All stations that monitor the broadcast TOD can then receive the TOD sync passively. The TOD_Response PDU is sent after the monitoring timeout period which is defined as two scanning dwell periods.
But, if this were the scenario, the TOD_Request is sent alone and not as the last in the Async request! so this case appears improbable (Fig. 6).

Fig. 6


d)
Lastly, one could say that I did not copy the missing FLSU Confirm PDUs: yes, it could be real, but the fact that in all these copies I never heard them would be singular as much as  improbable.

Above I have exposed my (maybe wrong?) suppositions, but vendors implementations and the common practice, which may diverge from the standard specifications, must also be considered as well as other capabilities that are not specified in the STANAG-4538 profile. 
That's why I expect your comments (after all, that's the beauty of the web).
  

https://yadi.sk/d/cAJShDFl3EzkYc 
https://yadi.sk/d/ltCmE4Go3EzksW 
↧

3G-ALE, 2-Way Link Quality Analysis (“LQA Exchange”) example

March 8, 2017, 12:03 am
$
0
0


this is surely a post of few or zero significance, just to add another over-the-air scenario of those depicted in the NATO STANAG-4538 document.
The diagram in Fig. 1 shows the procedure by which a PU can exchange SNR information for all scanned channels in both directions with a second specified PU. This is accomplished by means of a 3-way FLSU PDU exchange on each of the scan channels. The LQA Exchange, as well as other 3G-HF activity, has been copied on 10132.0 KHz/USB (sunday morning, 1019 UTC) in the reserved WARC band of 30mt.  

Fig. 1
When a PU is given a request for an LQA Exchange with another PU, it sends a FLSU_Req PDU on the next scan channel on which it is able to. The FLSU_Req PDU includes the caller PU address and called PU address, and is of type REQUEST_2Way.
The called PU estimates the SNR of the received FLSU_Req PDU and reports the channel quality back to the caller PU by responding with an FLSU_Conf PDU on the same channel. The caller PU, on its turn, estimates the SNR of the FLSU_Conf PDU and reports it back to the called PDU through an FLSU_Term PDU that terminates the 3-way exchange.



↧

3G-ALE, Synchronous 2-way FLSU failure – packet traffic example

March 9, 2017, 3:19 am
$
0
0

Fig. 1 shows the required procedure for a failed Link Set Up. All 2-way FLSU calls require only a Request and Confirm PDU transmission. The third handshake is issued only if the caller PU does not correctly receive a Confirm PDU as expected. There can be many reasons for such a case. Some examples include: CRC failure, propagation failure, an unexpected result in any field of the FLSU_Confirm PDU, or reception of an unexpected PDU of a different type. In these cases the caller PU is required to transmit a FLSU_Terminate PDU. However, the caller must honour the requirement that a receiving PU need not execute more than dual demodulation. 

Fig. 1
The scenario in fig. 2 depicts the case in which the HDL ARQ protocol is invoked via the original FLSU call. 
Since the calling PU did not receive the FLSU_Confirm response, it must assume that the response did not propagate properly and that the called PU is prepared for the HDL packet transfer protocol. As such, the called PU is set up to receive either the first HDL forward packet PDU (BW2), or an HDL_Terminate PDU (BW1) . Sending a FLSU_Terminate (ie a BW5 burst) would impose a triple demodulation requirement on the receiving PU! 
Thus, the calling PU must send up to N BW1 bursts carrying the HDL_Terminate PDU’s to abort the ARQ protocol (under the xDL protocol specification, “N” is defined by the number of xDL_Terminate PDUs that would fit within the time slot of a forward packet PDU). In this sample, the caller sends 3 BW1 bursts for a total duration of (3 x 1306.66) = 3919.98 msec.
If this were a Circuit Traffic example, as seen, the “xDL_Terminate” PDU’s would not be necessary, and the calling PU could send the FLSU_Terminate PDU (BW5) immediately after the failed call response.

Fig. 2
Fig. 3


↧
Search

Logs

March 11, 2017, 12:44 am
$
0
0

[MIL-STD 188-141]
03831.0: ZEMD: Zollboot Emden, D 2150 USB MIL 188-141 2G-ALE calling ZLST, no reply (01Mar17) (AAI)
06562.0: J64: Moroccan Military, MRC 2130 USB MIL 188-141 2G-ALE sounding (09Mar17) (AAI)
06562.0: P53: Moroccan Military, MRC 2132 USB MIL 188-141 2G-ALE sounding (09Mar17) (AAI)
06629.0: DYA: Iraqi Border Police, IRQ 2125 USB MIL 188-141 2G-ALE calling DB1 (09Mar17) (AAI)
06660.0: 5001: Unid 2119 USB MIL 188-141 2G-ALE LQA Excgange w/ 5005 (09Mar17) (AAI)
06721.0: 299212: USAF C-17A Globemaster aircraft '09-9212' 0730 USB MIL 188-141 2G-ALE sounding (07Mar17) (AAI)
07457.0: LIS: Unid 0718 USB MIL 188-141 2G-ALE calling XGY, no reply (07Mar17) (AAI)
07535.0: FN02: Algerian Military, ALG 0814 USB MIL 188-141 2G-ALE LQA Excgange w/ PY0 (10Mar17) (AAI)
07535.0: TC01: Algerian Military, ALG 0841 USB MIL 188-141 2G-ALE LQA Excgange w/ PY0 (10Mar17) (AAI)
07549.0: K3R: Lithuanian Military, LTU 0744 USB MIL 188-141 2G-ALE LQA exchange w/ TMUNET (07Mar17) (AAI)
07776.0: BF01: Unid (prob. Tunisian net) 0847 USB MIL 188-141 2G-ALE LQA Excgange w/ QS02 (10Mar17) (AAI)
07776.0: CU01: Unid (prob. Tunisian net) 0836 USB MIL 188-141 2G-ALE LQA Excgange w/ AV01 (10Mar17) (AAI)
07776.0: KW0: Unid (prob. Tunisian net) 0839 USB MIL 188-141 2G-ALE LQA Excgange w/ KW01 (10Mar17) (AAI)
07776.0: KW04: Unid (prob. Tunisian net) 0848 USB MIL 188-141 2G-ALE LQA Excgange w/ KW03 (10Mar17) (AAI)
07776.0: KW04: Unid (prob. Tunisian net) 0900 USB MIL 188-141 2G-ALE LQA Excgange w/ KW05 (10Mar17) (AAI)
07894.0: 8411: Turkish Civil Defense Kocaeli, TUR 0810 USB MIL 188-141 2G-ALE sounding (10Mar17) (AAI) 
07900.0: 820614: Unid (presumed Kyrgyzstan net, KGZ) 2215 USB MIL 188-141 2G-ALE sounding (09Mar17) (AAI)
07939.0: HBZ: Unid (prob. Roumanian Military, ROU) 0809 USB MIL 188-141 2G-ALE LQA Excgange w/ HFC (10Mar17) (AAI)
07940.0: PO1: Slovakian Military, SVK 0902 USB MIL 188-141 2G-ALE handshake PO2, female voice comms (10Mar17) (AAI)
08000.5: HBLZDRD1: Roumanian Military, ROU 0818 USB MIL 188-141 2G-ALE LQA Excgange w/ HFJCDRD1 (10Mar17) (AAI)
08000.5: HBLZDRzZM: Roumanian Military, ROU  0800 USB MIL 188-141 2G-ALE calling HFJCDRzZM (10Mar17) (AAI)
08011.0: 312: Unid (Turkish Civil Defence, TUR ?)1719 USB MIL 188-141 2G-ALE LQA exchage w/ 425 (05Mar17) (AAI)
08055.0: 940101: Unid (presumed Mauritanian Gendarmerie, MTN) 2232 USB MIL 188-141 2G-ALE sounding (09Mar17) (AAI)
08070.0: XS45: Algerian Military, ALG 0844 USB MIL 188-141 2G-ALE LQA Excgange w/ PY50 (10Mar17) (AAI)
08092.0: 8411: Turkish Civil Defense Kocaeli, TUR 0806 USB MIL 188-141 2G-ALE sounding (10Mar17) (AAI)
08195.0: 10536: Unid 1824 USB MIL 188-141 2G-ALE calling 8536 (07Mar17) (AAI)
08252.0: N61: Chinese Military, CHN USB MIL 188-141 2G-ALE handshake A99 followed by QPSK 2400Bd/MFSK-8 125Bd mixed mode (05Mar17) (AAI)
10345.0: JCI: Saudi Air Force, ARS 1621 ISB MIL 188-141 2G-ALE calling RFI, no reply (04Mar17) (AAI)
10425.0: XPU: UK-DHFCS, G 0814 USB MIL 188-141 2G-ALE LQA Excgange w/ SRX (08Mar17) (AAI)
10429.0: 2169: Unid 1000 USB MIL 188-141 2G-ALE LQA exchage to 2151 (05Mar17) (AAI)
10600.0: 920007: Unid 0819 USB MIL 188-141 2G-ALE LQA exchange w/ 920001 (07Mar17) (AAI)
10915.0: 105016: Unid 1654 USB MIL 188-141 2G-ALE sounding (07Mar17) (AAI)
10915.0: 302006: Unid 1722 USB MIL 188-141 2G-ALE sounding (07Mar17) (AAI)
10950.0: GWB: Unid 1815 USB MIL 188-141 2G-ALE sounding (09Mar17) (AAI)
10973.0: LCR154: Polish Military, POL 1142 USB MIL 188-141 2G-ALE LQA Excgange w/ SPI324 (10Mar17) (AAI)
11106.0: EK9: Greek Military, GRC 1417 USB MIL 188-141 2G-ALE LQA exchange w/ GEF (06Mar17) (AAI)
11130.0: ELJADIDNET4: Moroccan Military El Jadid, MRC 1131 USB MIL 188-141 2G-ALE LQA Excgange w/ C3 (10Mar17) (AAI)
11130.0: J64: Moroccan Military, MRC 1630 USB MIL 188-141 2G-ALE sounding (04Mar17) (AAI)
11130.0: S32: Moroccan Military, MRC 1151 USB MIL 188-141 2G-ALE sounding (10Mar17) (AAI)
11135.0: GANOB10: Unid 1422 USB MIL 188-141 2G-ALE LQA exchange w/ HQ4 (06Mar17) (AAI)
11135.0: HQ3: Unid 1433 USB MIL 188-141 2G-ALE sounding (06Mar17) (AAI)
11173.0: 01012016: Algerian Air Force, ALG 0833 USB MIL 188-141 2G-ALE LQA Excgange w/ CM6 (08Mar17) (AAI)
11260.0: 920007: Unid 0903 USB MIL 188-141 2G-ALE sounding (02Mar17) (AAI)
11436.0: 1207: Unid 0918 USB MIL 188-141 2G-ALE LQA calling 0762 (09Mar17) (AAI)
11494.0: 704: USCG Hercules HC-130H7 #1704, US 1832 USB MIL 188-141 2G-ALE sounding (09Mar17) (AAI)
11494.0: LNT: USCG CAMSLANT Chesapeake, US  1835 USB MIL 188-141 2G-ALE LQA Excgange w/ J07 (09Mar17) (AAI)
13224.0: NAP: Saudi Air Force, ARS 1439 USB MIL 188-141 2G-ALE sounding (06Mar17) (AAI)
16029.0: A99: Chinese Military, CHN 1013 USB MIL 188-141 2G-ALE calling N61 (06Mar17)
16170.0: N22: Unid (Chinese Military, CHN ?) 0917 USB MIL 188-141 2G-ALE LQA exchange w/ N12 (06Mar17) (AAI)
16240.0: 1304: Moroccan Civil Protection, MRC 1017 USB MIL 188-141 2G-ALE sounding (06Mar17) (AAI)
16240.0: 1318: Moroccan Civil Protection, MRC 1020 USB MIL 188-141 2G-ALE sounding (06Mar17) (AAI)
16358.6: KWY94OS: Unid US-DoS station 1025 USB MIL 188-141 2G-ALE LQA exchange w/ KTR67 (06Mar17) (AAI)
16576.0: FUX03D: Unid (prob. French Navy, F) 1008 USB MIL 188-141 2G-ALE LQA exchange w/ FUV03D (06Mar17)

[mixed]
06228.0: ---: Unid 2134 USB Hagelin HC-256 voice scrambler (01Mar17) (AAI)
07500.0: ---: Unid 0853 USB 3G-HF LQA Exchange (10Mar17) (AAI)
07504.0: ---: Unid 0802 USB Thales skymaster ALE + Robust Mode MFSK-8 125Bd (07Mar17) (AAI)
07803.0: ---: Unid 0907 USB Thales Skymaster ALE call (10Mar17) (AAI)
08045.0: ---: Unid (prob. Bulgarian Diplo) 0830 USB RFSM-8000 modem with data-masking (10Mar17) (AAI)
10132.0: ---: Unid 1050 USB 3G-HF 2-way FLSU link setup followed by traffic in ciruict mode (MIL 188-110A) (05Mar17) (AAI)
10344.0: ---: Unid 0825 CW "... AA5 = 423 K" (07Mar17) (AAI)
10627.0: ---: Unid 0951 USB 3G-HF 2-way FLSU link setup followed by LDL traffic (07Mar17) (AAI)
10863.0: ---: Unid 0857 USB 3G-HF FLSU link setup followed by LDL traffic (08Mar17) (AAI)
10900.0: ---: Unid 0924 USB 3G-HF (several) LQA Exchanges (08Mar17) (AAI)
10900.0: ---: Unid 0950 USB 3G-HF 2-way FLSU link setup followed by traffic in ciruict mode (MIL 188-110A) (08Mar17) (AAI)
11111.0: STAT23: Tunisian MoI net, TUN 1233 USB (offest 1700Hz) PacTOR II sending email to SAT152 (10Mar17) (AAI)
11409.0: ---: Unid 1611 USB (offset + 1000Hz) HARRIS Autolink I call (04Mar17) (AAI)
11430.0: ---: Unid 1040 USB 3G-HF FLSU link setup followed by HDL traffic (08Mar17) (AAI)
12193.0: ---: Russian Mil/Gov, RUS 1310 USB CIS-112 OFDM 112-tone 22.22Bd BPSK modem, callUp and data (09Mar17) (AAI)
15957.0: ---: Russian Air Force, US 1055 USB FSK 50Bd/500, encrypted messages (06Mar17) (AAI)
16083.0: ---: Russian Intel, RUS 0900 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz), s/off 0907 (06Mar17) (AAI)
16207.0: ---: Russian Navy, RUS 1138 T-600 FSK 50Bd/200, Message Sync 0x1eb41eb2952 (06Mar17) (AAI)
 


↧
↧

3G MDL with BW3-32 (LDL) burst waveform

March 15, 2017, 6:29 am
$
0
0
Yet another over-the-air example of 3G Multicast Data Link (MDL) protocol copied on 7700.0 KHz/USB at 2206 UTC, 14 Mar: this time the BW3 waveform from the LDL protocol, the one with a 32-byte payload (most robust), has been used.


The One-way Point-To-Multipoint (PTM) FLSU_Request PDU specifies the group address as its destination and the originating station address as its source. The Channel field is normally set to ‘111111’ to indicate that the channel carrying this PDU will also be used for the traffic. The Traffic Type field indicates which of the MDL modes will be used to carry the traffic.


The carried message has been secured using Harris "Citadel" encryption, as well as the FLSU_Request (sent in Linking Protection mode).



https://yadi.sk/d/hZI6WjHL3FsjGs

↧

Nokia Adaptive MSG-Terminal, FSK 401Bd/301Bd 780Hz shift

March 17, 2017, 7:51 am
$
0
0

This is an interesting copy of transmissions sourced by the Nokia Adaptive MSG-Terminal (Nokia Sanomalaite M/90) in "dual" 401 (401.5) and 301 Baud mode, both running with constant 780 Hz shift and heard on 10225.0 KHz/USB (offset = 1700 Hz) at 0605 UTC.


The three transmissions resemble a PtP ARQ system where the caller station use the 401Bd mode to send data and the called station use the 301 Bd mode for ACKs, also note that in the second transmission the 401Bd frame is sent without the preamble: maybe it is a segment which belongs to the first transmission. However, during that same recording the 401Bd mode has been used also as stand-alone (Fig. 2).

Fig. 2
Just the preamble is probably the "business card" of this waveform: talking with my friend KarapuZ about this device, he pointed the fact that the preamble it's always modulated at a speed of 301 Baud. 
Indeed, at a first glance the speed seem to be constant in the two modes: 401 and 301 Baud (Fig. 3)

Fig. 3
but trying to demodulate the 401Bd signal it's possible notice some distorsions in the preamble which are not present when the stream is forced to 301 Baud (Fig. 4)

Fig. 4
These distorsions are not present in the case of the 301Bd signal (Fig. 5)

Fig. 5
In order to prove this characteristic, KarapuZ sent me a recording of the Nokia M/90 running at 151 (150.5) Bd and also in this case it's possibile notice that same behavior in the preamble (Figs. 6,7)

Fig. 6

Fig. 7
KarapuZ also suggested to demodulate the 151Bd signal using the differential decoding: after the removal of the synchronization bits (vertical solid columns in the 4-bit period stream) and inverting the polarity, a period of 8 bits with 1 stop bit is obtained. Next, it's difficult to state how to process the information, as a rule, such terminals use off-line encryption. Since the removal of 2 bits of four, the data signaling rate is 150/2 = 75 bps.



Some info about the Nokia Adaptive MSG-Terminal "Sanomalaite M/90" (Fig.8 ) can be found here:
https://www.revolvy.com/main/index.php?s=Sanomalaite%20M/90
https://en.wikipedia.org/wiki/Sanomalaite_M/90

Fig. 8 (Wikipedia)
I had a copy of the 301Bd mode on April 2016



https://yadi.sk/d/htVJdKCj3G5aHc
https://yadi.sk/d/QP1c4nli3G5afh


↧

a STANAG-5066 HF MailServer at work

March 19, 2017, 2:50 pm
$
0
0
this is a good example of a STANAG-5066 based HF Mail Server (an MTA, Mail Tranfer Agent) at work: the HF Mail Server receives one email transmitted by a wireless client (over-the-air path) which is addressed to multiple non-HF recipients, and then it takes care of each single delivery by forwarding each message through an infrastructured TCP/IP path and returns back the email transmitted notifications to the sender (Fig. 1). Just the copy of the over-the-air "notifications" allowed to retrace the scenario.
The transmission concerns HF mail tests from a Turkish HF newtork, most likely belonging to the Coast Guard, and was (accidentally!) copied by KarapuZ. The HF Mail Server sits in the middle and acts as default MTA for the turkhfmail.com domain, so it's  "transparent" to the users. Both the sender and the Mail Server are in the same STANAG-5066 HF network: respectively, 1.0.0.3 and 1.0.0.1 (S-5066 Addresses).

Fig. 1
The used HF waveform is STANAG-4285 with ARQ extension provided by upper STANAG-5066 data link protocol (Fig. 2), the channel is used in half-duplex mode.

Fig. 2
The transmission, as said, convey test emails in clear-text, so these are not critical/secure messages, however only the domain names are visible while the account names are obscured. As I mentioned several times, I'm only interested on the way the "boxes" travel on-the air and not in their contents.

Figure 3 shows the transmission of the email from a certain <user>@turkhfmail.com (the sender at gw-HF-mail) tosome recipients belonging to different not-HF email domains. Notice that the Adobe license is the content used as test message (so nothing important, just a text).

Fig. 3
the HF mail server reports the emails status to the original sender by transmitting a single notification for each addressed recipient: in this case the sender is the HF mail server.
I wanted to illustrate more clearly two of those test notifications in order to understand the involved users and their role. Figure 4 shows the status notification of the email which is addressed to Directorate General of Coastal Safety, Figure 5 show the status of an email addressed to Selex ES headquarter in Turkey

Fig. 4
Fig. 5
The Turkish Directorate General of Coastal Safety is the client and the Italian Selex-ES is the solution vendor: it's quite obvious that these are the recipients since they are the most interested on the results of the tests. 

Some other informations can be acquired from the headers. 
1) The used protocol is CFTP (Compressed File Transport Protocol). CFTP is used to reliably send compressed SMTP e-mail over a STANAG-5066 HF subnetwork from one SMTP mail server to another. In operation, when an email message is received at a 5066 node, it is placed in an incoming mail folder (mail spool directory). The CFTP client, also called the Delivery Agent (DA), removes mail from this incoming folder and processes the mail for delivery over HF via 5066. The CFTP DA compresses the message and information about the message, e.g. size, id, recipients, etc. into a file.This compressed file is then transferred to the destination HF 5066 node(s).
2) User-Agent at the sender node is Mozilla/5.0 rv:12.0 Thunderbird/12.0.1 on Windows NT 6.1
3) The email domain name is turkhfmail.com, usually mail servers use mail.<domain name> as their hostname so I tried to nslookup mail.turkhfmail.com and got 212.156.62.66 (relay7.selex-comms.com.tr); the mail server is owned by Turk telekom and hosted directly by Selex-ES (Fig. 6)

Fig. 6
The HF mail server, as an MTA, also delivers messages from senders outside the HF network to STANAG-5066 HF recipients as shown in Figure 7
Fig. 7
It's worth noting the match of the mail server public IP address.
↧

Logs (a lot of)

March 23, 2017, 4:59 am
$
0
0

05316.0: Z1V: Slovakian Air Force, SVK 0842 USB MIL 188-141 2G-ALE calling M1I (21Mar17) (AAI)
05350.0: ---: Unid 0733 LSB TADIRAN AutoCall MFSK-4 (21Mar17) (AAI)
05426.0: SM8: Polish Military, POL 0743 USB MIL 188-141 2G-ALE LQA Report to OR2 (21Mar17) (AAI)
05695.0: ---: Unid 0745 USB 3G-HF 2-way FLSU handshake followed by HDL traffic (21Mar17) (AAI)
05885.0: 082: Hungarian Mil, HNG 0800 USB MIL 188-141 2G-ALE handshake 085 flwd by voice scrambler (21Mar17) (AAI)
06373.0: ---: Unid 2148 USB Chinese mixed QPSK 2400Bd + MFSK-8 125Bd modem (14Mar17)(AAI)
06510.0: N1R: Slovakian Air Force, SVK 0855 USB MIL 188-141 2G-ALE calling Z1V (21Mar17) (AAI)
06715.5: ---: Unid 0715 USB 3G-HF HDL traffic (21Mar17) (AAI)
06733.0: IDR: Italian Navy S.Rosa Rome, I 0810 J3E/USB DAGA-88 aircraft, voice comms +  RATT 75Bd/850 (offset 2000 Hz) (21Mar17) (AAI)
06745.5: AC01: Algerian Militay ALG 0821 USB MIL 188-141 2G-ALE handshake XV01 followed by MIL 188-110 App.B 39-tone OFDM (21Mar17) (AAI)
06867.0: ABC7: Croatian Military, HRV 0829 USB MIL 188-141 2G-ALE calling ABD1 (21Mar17) (AAI)
06990.0: CZ7: Polish Military, POL 1427 SB MIL 188-141 2G-ALE calling TO9, CMD AMD "PODAJ POZYCJE" (19Mar17) (AAI)
06990.0: WO7: Polish Military, POL 1418 USB MIL 188-141 2G-ALE LQA Report to IS7 (19Mar17) (AAI)
06990.0: WO7: Polish Military, POL 1418 USB MIL 188-141 2G-ALE LQA Report to KR8 (19Mar17) (AAI)
07390.5: A17: Unid 0805 USB MIL 188-141 2G-ALE LQA report to A14 (16Mar17) (AAI)
07457.0: LIS: Unid 0720 USB MIL 188-141 2G-ALE LQA Exchange w/ XGY (13Mar17) (AAI)
07500.0: ---: 0832 no call USB MIL 188-141 2G-ALE calling BETA (16Mar17) (AAI)
07512.0: TWVE2: Spanish Police Segovia, E 0940 USB MIL 188-141 2G-ALE LQA Report to TWVS3 (21Mar17) (AAI)
07512.0: TWVE2: Spanish Police Segovia, E 0958 USB MIL 188-141 2G-ALE LQA Report to TWVA3 (21Mar17) (AAI)
07512.0: TWVE2: Spanish Police Segovia, E 1000 USB MIL 188-141 2G-ALE LQA Report to TYMC3 (21Mar17) (AAI)
07527.0: TYMT2: Spanish Police Toledo, E 0629 USB MIL 188-141 2G-ALE sounding (16Mar17) (AAI)
07541.0: ---: Unid 0910 (cf) FSK-2 19.5Bd/125, ACF 125 bits, sending same test sequence (21Mar17) (AAI)
07605.0: ANOUAL2: Moroccan Military, MRC 1819 USB MIL 188-141 2G-ALE sounding (16Mar17) (AAI)
07620.5: COU: 0835 USB MIL 188-141 2G-ALE calling VOR (16Mar17) (AAI)
07620.5: COU: 0837 USB MIL 188-141 2G-ALE calling SAT (16Mar17) (AAI)
07651.0: DD1: Israeli Air Force, ISR 1747 USB MIL 188-141 2G-ALE sounding (18Mar17) (AAI)
07664.0: ---: Unid 2208 USB 3G-HF 2-way LQA exchange (14Mar17)(AAI)
07692.0: 7VG: Moroccan Gendarmerie, MRC 1730 USB USB MIL 188-141 2G-ALE LQA Report to W3A followed by MIL 188-110A (17Mar17)(AAI)
07692.0: 8GH: Moroccan Gendarmerie, MRC 1814 USB USB MIL 188-141 2G-ALE LQA Report to ED7 followed by MIL 188-110A (17Mar17)(AAI)(17Mar17)(AAI)
07692.0: P1U: Moroccan Militari, MRC Unid 1954 USB MIL 188-141 2G-ALE LQA Report to 7VG (15Mar17) (AAI)
07692.0: W3A: Moroccan Militari, MRC Unid 0810 USB MIL 188-141 2G-ALE calling 7VG (16Mar17) (AAI)
07699.0: ---: Unid 1759 USB 3G-HF FLSU handshake followed by LDL traffic (13Mar17) (AAI)
07700.0: ---: Unid 2205 USB 3G-HF 1-way FLSU followed by MDL multicast protocol sending 3 x BW3-32 Harris Citadel encrypted message (14Mar17)(AAI)
07702.5: PP7: Polish Military, POL 0823 USB MIL 188-141 2G-ALE LQA Report to ZB1 (22Mar17) (AAI)
07761.0: 6006: Iraqi Government, IRQ 1750 USB MIL 188-141 2G-ALE sounding (18Mar17) (AAI)
07770.0: 2001: Unid 1312 USB MIL 188-141 2G-ALE sounding (20Mar17)(AAI)
07774.0: SID: Iraqi border police Sidekan, IRQ 1714 USB MIL 188-141 2G-ALE 2-way LQA exchange w/ DYA2 (17Mar17) (AAI)
07776.0: SB01: Unid (prob. Tunisian net, TUN) 1341 USB MIL 188-141 2G-ALE handshake KW01, voice comms in Arabic (10Mar17) (AAI)
07776.0: WM02: Unid (prob. Tunisian net, TUN) 1348 USB MIL 188-141 2G-ALE LQA Exchange w/ KW01 (10Mar17) (AAI)
07810.0: 2016: Turkish red crescent, TUR 0818 USB MIL 188-141 2G-ALE LQA Report to 1020 (22Mar17) (AAI)
07810.0: 820211: Unid (presumed Kyrgyzstan net, KGZ) 1720 USB MIL 188-141 2G-ALE LQA Report to 820299 (17Mar17)(AAI)
07813.0: X42: Moroccan Military, MRC 1852 USB MIL 188-141 2G-ALE sounding (16Mar17) (AAI)
07822.0: COU: 0841 USB MIL 188-141 2G-ALE calling MIC (16Mar17) (AAI)
07822.0: COU: Unid prob. Moldavian net, MDA 0858 USB MIL 188-141 2G-ALE LQA Report to BRA (23Mar17) (AAI)
07822.0: COU: Unid prob. Moldavian net, MDA 0859 USB MIL 188-141 2G-ALE LQA Report to SAT (23Mar17) (AAI)
07822.0: COU: Unid prob. Moldavian net, MDA 0902 USB MIL 188-141 2G-ALE LQA Report to LAA (23Mar17) (AAI)
07822.0: COU: Unid prob. Moldavian net, MDA 0908 USB MIL 188-141 2G-ALE LQA Report to MIC (23Mar17) (AAI)
07822.0: COU: Unid prob. Moldavian net, MDA 0912 USB MIL 188-141 2G-ALE LQA Report to VOR (23Mar17) (AAI)
07822.0: COU: Unid prob. Moldavian net, MDA 0916 USB MIL 188-141 2G-ALE handshake O7K, followed by voice comms (radio-check ?) (23Mar17) (AAI)
07822.0: COU: Unid prob. Moldavian net, MDA 0921 USB MIL 188-141 2G-ALE LQA Report to PLE (23Mar17) (AAI)
07830.0: 820799: Unid (presumed Kyrgyzstan net, KGZ) 2201 USB MIL 188-141 2G-ALE sounding (14Mar17)(AAI)
07840.0: ---: Unid 0819 USB 3G-HF FLSU handshake followed by traffic in circuit mode (MIL 188-110A) (13Mar17) (AAI)
07840.0: XPU: UK-DHFCS, G 0723 USB MIL 188-141 2G-ALE LQA Exchange w/ SRX (13Mar17) (AAI)
07859.5: DB1: Iraqi Boarder Police Arbil, IRQ 1528 USB MIL 188-141 2G-ALE LQA Exchange w/ DUH (13Mar17) (AAI)
07870.0: 207101: Turkish emergency net, TUR 0907 USB MIL 188-141 2G-ALE sounding (11Mar17) (AAI)
07885.0: 715: Unid (although same channel of SHARK3) 1742 USB USB MIL 188-141 2G-ALE LQA Report to 861 (17Mar17)(AAI)
07885.0: SHARK3: Unid (presumed Egyptian net, EGY) 1742 USB USB MIL 188-141 2G-ALE LQA Report to HQ2 (17Mar17)(AAI)
07885.0: SHARK3: Unid (presumed Egyptian net, EGY) 1752 USB USB MIL 188-141 2G-ALE LQA Report to ST1 (17Mar17)(AAI)
07891.2: ---: Unid 0945 USB STANAG-4285 600bps/L sending KG-84 encrypted messages (22Mar17) (AAI)
07892.0: 332018: Turkish Civil Defense Isparta, TUR 2014 USB MIL 188-141 2G-ALE sounding (16Mar17) (AAI)
07892.0: 363018: Turkish Civil Defense Sanliurfa, TUR 2010 USB MIL 188-141 2G-ALE sounding (16Mar17) (AAI)
07892.0: 400001: Mauretanian Law-Enforcement, MTN 1810 USB MIL 188-141 2G-ALE LQA Report to 400008 (21Mar17) (AAI)
07894.0: 810698: Unid presumed Kyrgyz net, KGZ 1829 USB MIL 188-141 2G-ALE LQA Report to 810613 (21Mar17) (AAI)
07898.0: 049112: German Red Cross, D 0917 USB MIL 188-141 2G-ALE sounding (22Mar17) (AAI)
07898.0: 049112: German Red Cross, D 1815 USB MIL 188-141 2G-ALE sounding (16Mar17) (AAI)
07918.0: 221817: Unid 1753 USB MIL 188-141 2G-ALE sounding (16Mar17) (AAI)
07928.0: ---: Unid 1349 USB 3G-HF FLSU handshake followed by traffic in ciruict mode (MIL 188-110A) (10Mar17) (AAI)
07950.0: ---: Unid 0811 USB 3G-HF FLSU handshake followed by HDL traffic (20Mar17) (AAI)
07954.0: PP7: Polish Military, POL 1738 USB MIL 188-141 2G-ALE LQA Report to ML2 (21Mar17) (AAI)
07959.5: DB1: Iraqi Border Police, IRQ 1837 USB MIL 188-141 2G-ALE LQA report to DYA (15Mar17) (AAI)
07959.5: DB1: Iraqi Border Police, IRQ 1840 USB MIL 188-141 2G-ALE LQA report to DUH (15Mar17) (AAI)
07970.0: 810510: Unid (presumed Kyrgyzstan net, KGZ) 2220 USB MIL 188-141 2G-ALE sounding (14Mar17)(AAI)
07970.0: 820513: Unid (presumed Kyrgyzstan net, KGZ) 2158 USB MIL 188-141 2G-ALE sounding (14Mar17)(AAI)
07973.0: ---: Unid 0821 USB MFSK-11 125Bd/250Hz modem (13Mar17) (AAI)
07987.0: 641: Unid 1823 USB MIL 188-141 2G-ALE calling 861 (15Mar17)(AAI)
08000.5: HBLZDRD1: Roumanian Military, ROU 0814 USB MIL 188-141 2G-ALE LQA Exchange w/ HFJCDRD1 (13Mar17) (AAI)
08002.0: ---: Unid 0410 USB 3G-HF FLSU handshake followed by traffic in circuit mode (MIL 188-110A) (15Mar17) (AAI)
08005.0: 920001: Unid 1800 USB MIL 188-141 2G-ALE sounding (18Mar17) (AAI)
08005.0: 920007: Unid 0732 USB MIL 188-141 2G-ALE sounding (15Mar17)(AAI)
08007.0: DHCNET1: prob. USAREUR (US Army Europe) 0922 USB MIL 188-141 2G-ALE LQA Report to STRIKENET1 (22Mar17) (AAI)
08007.0: STRIKENET1: Unid (NATO PfP exercise ?) 0758 USB MIL 188-141 2G-ALE LQA report to DHCNET1 (15Mar17)(AAI)
08010.0: ---: Ukraine Mil, UKR 0625 USB MFSK-4 (double FSK) 96Bd 500Hz,(tones at -750, -250, +250, +750) (16Mar17) (AAI)
08010.0: ---: Unid 0731 USB 3G-HF FLSU handshake followed by HDL traffic (13Mar17) (AAI)
08016.0: Z01: NPRD Net, Zagreb, HRV 1739 USB MIL 188-141 2G-ALE sounding (21Mar17) (AAI)
08021.0: CENTR3: MFA Bucuresti, ROU 0856 USB MIL 188-141 2G-ALE handshake FQS followed by MIL 188-110A transporting STANAG-5066 protocol (22Mar17) (AAI)
08023.0: FQ40: Algerian Military, ALG 0812 USB MIL 188-141 2G-ALE LQA report to FQ41 (15Mar17)(AAI)
08030.0: 7777: Iraqi Government, IRQ 1826 USB MIL 188-141 2G-ALE calling 7776 (16Mar17) (AAI)
08030.0: 7781: Iraqi Government, IRQ 1826 USB MIL 188-141 2G-ALE calling 7777 (16Mar17) (AAI)
08036.0: 102009: Unid 1832 USB MIL 188-141 2G-ALE sounding (15Mar17)(AAI)
08052.5: 3BDETOC3ABCTNE: US Army 3d brigate ABCT 0813 USB MIL 188-141 2G-ALE LQA report to 410TOC3ABCTNE (14Mar17)(AAI)
08060.0: ---: Unid 2151 USB 3G-HF 2-way encrypted LQA exchange (21Mar17) (AAI)
08061.0: ---: Unid 2209 USB 3G-HF 2-way LQA exchange (14Mar17)(AAI)
08066.0: 077025: Unid 2056 USB MIL 188-141 2G-ALE sounding (21Mar17) (AAI)
08073.0: ---: Unid 1507 USB 3G-HF FLSU handshake followed by half-duplex LDL traffic, Harris Citadel encryption (15Mar17) (AAI)
08083.0: 288: Georgian Border Guards, GEO 2139 USB MIL 188-141 2G-ALE LQA Report to 204 (21Mar17) (AAI)
08083.0: 288: Georgian Border Guards, GEO 2146 USB MIL 188-141 2G-ALE LQA Report to 514 (21Mar17) (AAI)
08083.0: 334: Georgian Border Guards, GEO 2138 USB MIL 188-141 2G-ALE LQA Report to 288 (21Mar17) (AAI)
08132.0: BP25: German Police vessel Bayreuth, D 2108 USB MIL 188-141 2G-ALE handshake BPLEZS followed by R&S GM2100 modem transporting R&S X.25 login procedure (21Mar17) (AAI)
08145.0: R02: Unid 1032 USB MIL 188-141 2G-ALE LQA Report to R05 (23Mar17) (AAI)
08145.0: R09: Unid 1106 USB MIL 188-141 2G-ALE 2-way LQA exchange w/ R04 (23Mar17) (AAI)
08145.0: R09: Unid 1110 USB MIL 188-141 2G-ALE 2-way LQA exchange w/ R07 (23Mar17) (AAI)
08145.0: R09: Unid 1112 USB MIL 188-141 2G-ALE LQA Report to R08 (23Mar17) (AAI)
08145.0: R09: Unid 1114 USB MIL 188-141 2G-ALE LQA Report to R10 (23Mar17) (AAI)
08145.0: R09: Unid 1122 USB MIL 188-141 2G-ALE LQA Report to R05 (23Mar17) (AAI)
08145.0: R09: Unid 1126 USB MIL 188-141 2G-ALE LQA Report to R03 (23Mar17) (AAI)
08145.0: R10: Unid 1011 USB MIL 188-141 2G-ALE LQA Report to R09 (23Mar17) (AAI)
08151.0: TYMT2: Spanish Police Toledo, E 2032 USB MIL 188-141 2G-ALE sounding (16Mar17) (AAI)
08152.0: U01: Swedish Military Unid 1810 USB MIL 188-141 2G-ALE LQA report to D04 (15Mar17)(AAI)
08159.0: 105016: Unid 2044 USB MIL 188-141 2G-ALE sounding (21Mar17) (AAI)
08161.0: XEX: UK-DHFCS (mobile?) station, G 1336 USB MIL 188-141 2G-ALE LQA Report to XSS (17Mar17) (AAI)
08162.0: BZ01: Algerian Military, ALG 1709 USB MIL 188-141 2G-ALE handshake w/ UL01 followed by MIL 188-110A (18Mar17) (AAI)
08174.0: 2169: Unid 1736 USB MIL 188-141 2G-ALE LQA Report to 2117 (21Mar17) (AAI)
08182.0: XNM: UK-DHFCS, G 1426 USB MIL 188-141 2G-ALE handshake w/ XSS followed by MIL 188-110A traffic (15Mar17) (AAI)
08218.0: ---: Unid 0853 USB 3G-HF FLSU handshake followed by HDL traffic (13Mar17) (AAI)
08218.0: ---: Unid 1809 USB 3G-HF FLSU handshake followed by LDL traffic, Harris Citadel encryption (15Mar17) (AAI)
08234.5: 288: Georgian Border Guards, GEO 1730 USB MIL 188-141 2G-ALE calling 571 (21Mar17) (AAI)
08237.0: PP7: Polish Military, POL 1742 USB MIL 188-141 2G-ALE LQA Report to PM3 (21Mar17) (AAI)
08257.0: 121103: Unid 1740 USB MIL 188-141 2G-ALE sounding (21Mar17) (AAI)
08282.0: ---: Unid (US Navy ?) 0825 USB (weak) STANAG-4197 ANDVT transmissions (15Mar17)(AAI)
08282.0: ---: Unid 1157 USB STANAG-4197 short transmission (11Mar17) (AAI)
08315.0: 920: Unid 2103 USB MIL 188-141 2G-ALE sounding (21Mar17) (AAI)
08315.0: 920001: Unid 1803 USB MIL 188-141 2G-ALE calling 920004 (21Mar17) (AAI)
08315.0: 920002: Unid 1803 USB MIL 188-141 2G-ALE sounding (21Mar17) (AAI)
08327.0: ---: Unid 0812 USB 3G-HF FLSU handshake followed by LDL traffic (13Mar17) (AAI)
08630.0: XPU: Polish Military, POL 0818 USB SB MIL 188-141 2G-ALE LQA Report to SRX (20Mar17) (AAI)
08950.0: 123456: Turkish civil defence test call, TUR 2009 USB MIL 188-141 2G-ALE sounding (12Mar17) (AAI)
08989.0: ---: Unid prob. Portuguese Air Force, POR 1220 USB modified STANAG-4197 waveform, second tone library only (75Bd DQPSK, 112.5Hz spaced) (22Mar17) (AAI)
09181.0: XS43: Algerian Military, ALG 1347 USB MIL 188-141 2G-ALE sounding (22Mar17) (AAI)
09200.0: 2417: Moroccan Civil Protection, MRC 1400 USB MIL 188-141 2G-ALE sounding (22Mar17) (AAI)
09205.0: ---: South African Navy, RSA 1653 USB Grintek MHF50 MFSK HF modem (17Mar17) (AAI)
09274.0: ---: Unid 1336 (cf) R&S ALIS 228Bd/170 calling address 560 (22Mar17) (AAI)
09476.0: ---: Unid 1241 (cf) FSK-2 50Bd/500 transmission, ACF: 15-bit preamble, 45-bit data (22Mar17) (AAI)
10150.0: BA6: Polish Military, POL 0735 USB MIL 188-141 2G-ALE LQA report to AV5 (16Mar17) (AAI)
10170.0: ---: Russian Mil/Gov, RUS 0655 USB CIS 3 x 100Bd/1440Hz VFT (16Mar17) (AAI)
10210.0: ---: Russian Mil/Gov, RUS 1340 USB CIS-112 OFDM 112-tone 22.22Bd BPSK modem (20Mar17) (AAI)
10226.8: ---: Unid (prob Finnish Defence) 0605 (cf) Nokia MSG-Terminal M/90 FSK 401Bd/780 & 301Bd/780, prob. ARQ mode (16Mar17) (AAI)
10311.0: XV01: Algerian Military, ALG 0921 USB MIL 188-141 2G-ALE calling AC01 (14Mar17)(AAI)
10345.0: JCU: Saudi Air Force, ARS 1505 USB MIL 188-141 2G-ALE calling RFU (17Mar17) (AAI)
10390.0: 1113: Moroccan Civil Protection, MRC 1845 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
10390.0: 1115: Moroccan Civil Protection, MRC 1840 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
10390.0: 13131: Moroccan Civil Protection, MRC 1830 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
10390.0: 1314: Moroccan Civil Protection, MRC 1913 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
10390.0: 2202: Moroccan Civil Protection, MRC 1847 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
10390.0: 2203: Moroccan Civil Protection, MRC 1857 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
10390.0: 24091: Moroccan Civil Protection, MRC 1843 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
10390.0: 24181: Moroccan Civil Protection, MRC 1849 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
10390.0: 2513: Moroccan Civil Protection, MRC 1834 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
10425.0: GXV: Unid 1052 USB MIL 188-141 2G-ALE LQA report to SWT (14Mar17)(AAI)
10425.0: XPU: Unid G 0801 USB MIL 188-141 2G-ALE LQA report to 1VR (14Mar17)(AAI)
10568.0: ---: Unid 1813 USB 3G-HF FLSU handshake followed by LDL traffic transporting Harris Citadel encrypted data (12Mar17) (AAI)
10600.0: GHARB2: Unid 1119 USB MIL 188-141 2G-ALE calling GHARB5, ][CMD AMD][IFB] (11Mar17) (AAI)
10900.0: 1RZ: Polish Military, POL 0827 USB MIL 188-141 2G-ALE handshake w/ PWB followed by voice comms (20Mar17) (AAI)
10900.0: 1RZ: Polish Military, POL 1135 USB MIL 188-141 2G-ALE handshake w/ ZSD followed by voice comms (20Mar17) (AAI)
10900.0: 2RZ: Polish Military, POL 0859 USB MIL 188-141 2G-ALE handshake w/ 12B followed by voice comms (20Mar17) (AAI)
10900.0: GRZ: Polish Military, POL 0827 USB MIL 188-141 2G-ALE LQA Report to 12B (20Mar17) (AAI)
11130.0: O81: Unid 1320 USB MIL 188-141 2G-ALE sounding (11Mar17) (AAI)
11130.0: S5: Unid (Moroccan Military, MRC ?) 0926 USB MIL 188-141 2G-ALE LQA Report to S301 (20Mar17) (AAI)
11132.0: ---: Unid 0937 USB 3G-HF 2-way LQA exchange (20Mar17) (AAI)
11132.0: ---: Unid 1025 USB 3G-HF 1-way FLSU followed by MDL multicast protocol sending 3 x BW3-416 Harris Citadel encrypted message (16Mar17)(AAI)
11132.0: ---: Unid 1109 USB 3G-HF 1-way FLSU followed by MDL protocol using BW7 waveform (20Mar17)(AAI)
12115.0: RHI: Saudi Air Force, ARS 1421 ISB MIL 188-141 2G-ALE LQA Exchange w/ AAI (11Mar17) (AAI)
12162.0: ---: Russian Intel, RUS 1330 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) 3 mins lasting (21Mar17) (AAI)
12469.5: ---: Unid 1820 USB Thales Systeme-3000 MFSK-8 125Bd/250Hz robust mode (13Mar17) (AAI)
13446.0: FC8FEM: FEMA Region 8 Denver CO, US 1345 USB MIL 188-141 2G-ALE sounding (21Mar17) (AAI)
13552.0: XSX: 1339 USB MIL 188-141 2G-ALE 2-way LQA exchange w/ XGX (21Mar17) (AAI)
14403.2: ---: Unid 1455 USB STANAG-4285 2400bps/L transporting 192 x 8-bit multiplexed channels (1536-bit frame) (21Mar17) (AAI)
16010.0: ---: MFA Cairo, EGY 1445 USB (offset 1700Hz) SiTOR-ARQ, calling TVXS Egyptian embassy Manama (21Mar17) (AAI)
16011.0: 6Y8M5: National Guard unid station, US 1331 USB MIL 188-141 2G-ALE sounding (13Mar17) (AAI)
16103.0: ---: Russian Mil/Gov, RUS 1355 USB CIS-45 HDR modem v1 33.33Bd 62.5Hz BPSK (21Mar17) (AAI)
16106.3: ---: Unid 1405 USB STANAG-4285 1200bps/L transporting 192 x 8-bit multiplexed channels (1536-bit frame) (21Mar17) (AAI)
↧
↧

STANAG-4538, HDL+ and LDL protocols swapping in a bidirectional link

March 24, 2017, 7:07 am
$
0
0

This is a very interesting 3G-HF on-air scenario where as many as 5 burst waveforms and 2 datalink protocols are used, moreover, thanks to the different strength of the signals, it's also possible to notice the swap of the data-flow directions.
In the first part, after the 2-way Fast link setup PDUs exchange, data flows from PU1 to PU2 using HDL+ protocol. Immediately after the HDL+ transfer is complete, ie after the three HDL+ ACK PDUs (BW6) sent by PU1, both stations remain linked and initiate the Fast Traffic Management (FTM) protocol to negotiate further traffic. This gives PU2, which was the called station, the opportunity to send reverse traffic to PU1 (which was the caller) so data now flow from PU2 to Pu1.
After the LDL transfer is complete, ie after the ACK PDU (BW4) sent by PU2, stations wait for possible FTM PDUs and after the link timeout has occurred, the last station to receive an xDL transfer (PU1 in this case) terminates the link with an FLSU_Term PDU request.

Fig. 2
It's important to notice the use of the BW6 waveform for FLSU and FTM protocols PDUs (marked with an "*" in Figure 2) which are usually conveyed using the BW5 waveform. Indeed, as stated in STANAG 4538 Annex-C Edition1 Amendment2, if a link has been established for delivery of packet traffic using the HDL+ data link protocol, all FTM and FLSU PDUs transmitted for the remaining duration of the packet link shall be transmitted using the BW6 burst waveform, up to and including the FLSU_TERM PDU transmitted to terminate the link, and any optional response to the FLSU_TERM.
This means that BW6, other than BW7 header, ACK, and EOT (EOM) PDUs of the HDL+ protocol, is also used to convey PDUs of the fast link setup (FLSU) and fast traffic management (FTM) protocols in HDL+ links. It's worth noting that altough the link is subsequently used for LDL, it was initialized for HDL+ protocol.

Transmission was copied on 9175.0 KHz/USB at 1454 UTC (March, 22): MIL 188-110B traffic from Algerian Army was logged on this QRG, are we facing the same user? 
Fow what concerns the nature of the exchanged data, we can only state that LDL is used by PU2 to send an HARRIS Citadel encryped SMS-like message to PU1 (the sent message is very short, Fig. 3). Most likely it's an already queued message and waiting to be sent once the station is called/linked by PU1. The use of Citadel encryption is a clue in favor of HARRIS sw/hw equipments, e.g.Falcon II RF-5800H radios.

Fig. 3


↧

async FSK-2 50/100 Bd 500 Hz, "5-38" code (prob. CIS source)

March 30, 2017, 5:47 am
$
0
0
Some day ago, me and my friend KarapuZ were talking about some asynchronous 500 Hz shift FSK-2 signals and the way to get a meaningful decoding from the demodulator of SA. The first step is the removal of the START/STOP bits according to the size of the data field  (ie 5, 6, 7 or 8 bits) and then try different alphabet codes in turn, until you find onethat producesan outputthat makes a sense. 
The two analyzed signals have a shift of 500 Hz, a different manipulation speed (50 and 100 Baud) and different ACF (45 and 48 bits) but both exhibit a 5-bit size data field. 
 
Fig. 1 - the FSK 50Bd/500 signal
Once removed the START/STOP bits, we tried the so called 5-38 code, as KarapuZ advised, and we got interesting outputs: groups of 5 figures  in the 50 Baud signals, and more clear groups of 5 letters in the 100 Baud signal. The used procedure, and the results, are shown below for the 100Bd signal.
 
Fig. 2
Fig. 3
Groups of 5 letters/figures is a "format" that is frequently used by several Military and Governative Agencies so in the absence ofotherevidence it's a bit difficult to identify the source, although there are good chances in favour of  CIS/Russia:  I'm not experienced in "numbers" stations, comments are welcome.



↧
Search

xDL PDUs, BW2 & BW3 waveforms, and Harris 'Citadel' encryption

April 2, 2017, 8:52 am
$
0
0
I spent some time to understand where and when the 'Citadel' encryption is applied to a message in the STANAG-4538 xDL implementation by Harris, eg in the RF-5800H transceiver, regardless of whether the message came from STANAG-4406 P-MUL or HMTP/CFTP.
HDL and LDL protocols exist in different variants, and a number n (eg xDLn) specifies the size of one forward transmission. For HDL the number n (24, 12, 6, or 3) should be multiplied by 233 bytes plus a 17-bit sequence number added by the protocol to give the total number of bytes in one forward Tx frame.  If the data segment is of length less than 233 bytes,  a sequence of null data bytes (of value zero) is appended to the data segment so as to extend it to length 233 in constructing the data packet. Fig. 1 shows the formation of two HDL3 forward transmissions.

Fig. 1 (not in scale)
For LDL, the number n (32, 64, 96,…,512) gives the number of bytes explicitly in a tx frame plus 25 bits due to LDL overhead, ie 17-bit sequence number plus 8-bit data reserved for future use. As for HDL, the tx frame length of the LDL protocol has discrete values, so that a data segment will be padded with 0 value bits if ist length is less than the packet length established for the current LDL transfer (32, 64, 96,…,512). Fig. 2 shows the formation of two LDL512 forward transmissions.

Fig. 2 (not in scale)

Now assume that a STANAG-4406 message shall be encrypted and transferred. P-MUL protocol segments a message into UDP/IP packets with a maximum length of the IP packet of 1500 bytes. If the length of the message to be transferred is 15 kbytes, a total of 11 IP consecutive packets are required for the message transfer. Consider now how the STANAG-4538 protocols operate when transferring one IP packet. At the arrival of the first IP packet at the sender station, a link to the destination node is set up by FLSU PDUs. Then, a 1500 byte datagram containing the first IP packet is transferred for example by using two HDL6 Data PDUs or three LDL512 Data PDUs, each related to one segment of the datagram and followed by an ACK in the reverse direction. 
The Citadel engine works on each datagram segment before to construct the xDL PDU, each PDU is encrypted (not each xDL data segment!), as shown inFig. 3. In case of the incoming datagram matches the length established for the current xDL transfer then the encryption could be seen as directly applied to that datagram.

Fig. 3 (not in scale)
The insertion of the encryption is more clear looking at xDL bitstreams from the real world. An HDL12 transfer is shown in Fig. 4: the presence of the Citadel "business card" is well visible just at the beginning of the PDU (Fig. 5).

Fig. 4
Fig. 5
An LDL32 transfer is shown in Fig. 6 : the presence of the Citadel pattern is well visible just ineach LDL PDU (Fig. 7).

Fig. 6
Fig. 7
Looking at Fig.2, the correspondence 1 LDL PDU = 1 data packet could wrongly lead to think to an encryption applied on data packet basis: the encryption insertion is more clear looking at HDLn, where 1 HDLn PDU = n data packets (Figs. 4,5).

Now look carefully at Fig. 6: each packet is indicated with itsindex followed by the dimension of the data segment, 32 bytes in this case (LDL32). That said, why five 8-byte rows, ie 40 bytes, are printed ? The same incongruity is verifiable in HDL packets: 240 bytes printed instead of the expected 233 (fig. 8)
 
Fig. 8
LDL use burst waveform BW3 to transmit its PDUs. The number of payload bits is of the form 8n+25, where n = 32, 64, 96,..., 512 and the additional 25 bits are the overhead consisting of 17 bits of the sequence number + 8 bits for future use. A 32-bit Cyclic Redundancy Check (CRC) value is computed across the payload data bits in the data packet, and is then appended to the data packet. Then, 7 flush bits having the value 0 are appended to the (8n+57) bits of the data packet with CRC. In the example of Fig. 7 (LDL32) we obtain (8 x 32) + 57 + 7 = 320 bits that make the 40 bytes.

For what concerns HDL PDUs, these are transmitted by BW2 burst waveform. Each data packet is composed of a 1864 bits data-segment (233 bytes) + 17 bits of the sequence number. A 32-bit CRCvalue is computed across the 1881 payload data bits in each data packet, and is appended to the data packet. Then, seven encoder flush bits with values of zero are appended to the 1913 payload and CRC bits of each data packet to produce an Extended Data Packet (EDataPkt) of 1920 bits or just 240 bytes (Fig. 9).

Fig. 9
Juts another way to say that HDL is not BW2, and LDL is not BW3: xDL are protocols while BWn are waveforms.

↧

recent Logs

April 8, 2017, 12:47 am
$
0
0

05838.0: ABC7: Croatian Military, HRV 0734 USB USB MIL 188-141 2G-ALE followed by voice radio-check w/ ABF2 ABS5 ABH3 ABK4 (28Mar17) (AAI)
06250.0: ---: Unid (prob. Turkish Mil, TUR) 0713 (cf) FSK 600Bd/840, KG-84C vectors w/out sync (28Mar17) (AAI)
06758.7: ---: Unid (cf) NATO 75Bd/850 RATT, KG-84 encrypted messages (07Apr17) (AAI)
06831.0: D20: HPRD-net Dubrovnik, HRV 0729 USB MIL 188-141 2G-ALE sounding (07Apr17) (AAI)
07401.0: ZRUE: Zollboot Ruegen, D 0739 USB MIL 188-141 2G-ALE calling ZLST (05Apr17) (AAI)
07467.0: SL2: Slovakian Mil, SVK 0639 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to MC1 (07Apr17) (AAI)
07468.0: 01: Unid 1343 USB/J3E Thales skymaster ALE followed by voice call to 085, no reply (03Apr17) (AAI)
07527.0: OWK: OWK: USCGC Dependable (WMEC 626) US 0553 USB MIL 188-141 2G-ALE sounding (07Apr17) (AAI)
07560.0: Z19: Unid 0628 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to Z21 (07Apr17) (AAI)
07630.0: ESH: Algerian Air Force (Ecole de Specialisation sur Helicopters), ALG 0802 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to CM5 (04Apr17) (AAI)
07649.0: ---: Unid 1913 USB 3G-HF 2-way FLSU handshake followed by LDL32 transfer, Harris Citadel encryption (04Apr17) (AAI)
07660.0: ---: Unid 0858 USB 3G-HF 1-way FLSU followed by MDL protocol using LDL128 (BW3 waveform) (20Mar17)(AAI)
07692.0: 6DP: Moroccan Gendarmerie, MRC 1936 USB MIL 188-141 2G-ALE handshake 5YZ followed by MIL 188-110A serial (04Apr17) (AAI)
07692.0: 6DP: Moroccan Gendarmerie, MRC 1939 USB MIL 188-141 2G-ALE handshake Q7E followed by MIL 188-110A serial (04Apr17) (AAI)
07699.0: ---: Unid 1957 USB 3G-HF 2-way FLSU handshake followed by LDL32 transfer, Harris Citadel encryption (04Apr17) (AAI)
07700.0: ---: Unid 0557 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (07Apr17) (AAI)
07762.5: 6007: Unid 1929 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
07762.5: 6010: Unid 1949 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
07770.0: D15: Ukrainian Net, UKR 1859 USB MIL 188-141 2G-ALE 2-way LQA exchange w/ D17 (30Mar17) (AAI)
07803.0: ---: Unid (prob. French Forces Calvi, F) (cf) 0750 ARQ-E, FSK-2 184.6Bd/400, no traffic (27Mar17) (AAI)
07840.0: SWT: Unid 0716 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to SDL (04Apr17) (AAI)
07870.0: 21202: Unid (Turkish Civil Defense?) 1856 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
07892.0: 8411: Turkish Civil Defense Kocaeli, TUR 2110 USB MIL 188-141 2G-ALE sounding (28Mar17) (AAI)
07930.0: ---: Unid 0729 USB 3G-HF 2-way FLSU handshake followed by HDL6 transfer (04Apr17) (AAI)
07935.6: ---: Unid 0749 (cf) (04Apr17) Siemens CHX-200 modem selcall(04Apr17) (AAI)
07944.0: ---: Unid 1859 USB 3G-HF 2-way FLSU handshake followed by LDL32 transfer, Harris Citadel encryption (04Apr17) (AAI)
07945.0: ANOUAL2: Moroccan Military, MRC 0721 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
07956.0: ABC7: Croatian Military, HRV 0938 USB MIL 188-141 2G-ALE calling ABF2 (23Mar17) (AAI)
07961.0: AAA: Israeli Air Force, ISR 0612 MIL 188-141 2G-ALE handshake B28 followed by voice comms (07Apr17) (AAI)
07970.0: 820699: presumed Kyrgyz net, KGZ 1945 MIL 188-141 2G-ALE calling 820xxx (incomplete call) (04Apr17) (AAI)
08005.0: 920001: Unid 2103 USB MIL 188-141 2G-ALE handshake 920004 followed by series of 500Hz beeps (28Mar17) (AAI)
08005.0: 920007: Unid 1933 USB MIL 188-141 2G-ALE sounding (04Apr17) (AAI)
08005.0: 920007: Unid 2103 USB MIL 188-141 2G-ALE calling 920001 (28Mar17) (AAI)
08055.0: 1001: Unid 2031 USB MIL 188-141 2G-ALE calling 1004, followed by Codan ChirpCall 1047571 to 1047574 (28Mar17) (AAI)
08056.5: 106001: Turkish Civil Defense, TUR 2044 USB MIL 188-141 2G-ALE sounding (28Mar17) (AAI)
08090.0: 2159: Unid 1628 USB MIL 188-141 2G-ALE handshake 2167 followed by voice comms in French (31Mar17) (AAI)
08138.0: YDM: Unid 1028 USB MIL 188-141 2G-ALE LQA Report to UDR (24Mar17) (AAI)
08151.0: TYMT2: Spanish Police Toledo, E 0948 USB MIL 188-141 2G-ALE sounding (26Mar17) (AAI)
08162.0: BX01: Algerian Military, ALG 0922 USB MIL 188-141 2G-ALE handshake 123 (07Apr17) (AAI)
08162.0: JP02: Algerian Military, ALG 1017 USB MIL 188-141 2G-ALE LQA Report to PY01 (23Mar17) (AAI)
08178.5: KA2: Polish Military 1138 USB MIL 188-141 2G-ALE handshake MI2 followed by vy weak voice comms (06Apr17) (AAI)
08182.0: XDH: UK-DHFCS station, G 1021 USB MIL 188-141 2G-ALE LQA Report to XSS (23Mar17) (AAI)
08194.0: 280: Chinese Military, CHN 1843 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to 284 (04Apr17) (AAI)
08218.0: ---: Unid 0837 USB 3G-HF 2-way FSLU handshake followed by HDL traffic (23Mar17) (AAI)
08308.7: ---: Unid 0855 USB STANAG-4285 600bps/L KG-84 encrypted messages (25Mar17) (AAI)
08327.0: ---: Unid 2024 USB 3G-HF 2-way FLSU handshake followed by LDL480 transfer, Harris Citadel encryption (04Apr17) (AAI)
08488.0: ---: Unid 0810 USB 3G-HF 2-way FLSU handshake followed by LDL traffic (25Mar17) (AAI)
08850.0: R26577: US Army Helo 94-26577 1013 USB MIL 188-141 2G-ALE sounding (25Mar17) (AAI)
08992.0: ---: Andrews AFB, US 1002 J3E/USB test count (24Mar17) (AAI)
09175.0: ---: Unid 1354 USB 3G-HF 2-way FSLU handshake followed by bidirectional HDL+/LDL traffic (22Mar17) (AAI)
09220.0: GZS: Polish Military, POL 1254 USB MIL 188-141 2G-ALE LQA Report to 12B (25Mar17) (AAI)
09476.0: ---: Unid 1241 (cf) FSK-2 50Bd/500 ACF: 15-bit preamble and 45-bit data, groups of 5 figs (22Mar17) (AAI)
10132.0: ---: Unid 0919 USB 3G-HF 2-way FLSU handshake followed by HDL+ transfer (05Apr17) (AAI)
10150.0: 1RS: Polish Military, POL 1154 USB MIL 188-141 2G-ALE LQA Report to PWB (25Mar17) (AAI)
10150.0: PWB: Polish Military, POL 1155 USB MIL 188-141 2G-ALE LQA Report to GRP (25Mar17) (AAI)
10222.0: ---: Unid 1022 USB Hagelin HC-256 voice scrambler (05Apr17) (AAI)
10225.8: ---: Unid (prob. Finnish Military) 1145 USB Nokia Adaptive MSG-Terminal, FSK 401Bd/301Bd 780Hz shift (28Mar17) (AAI)
10280.0: 1536: Unid 0659 USB MIL 188-141 2G-ALE LQA Report to 8536 (31Mar17) (AAI)
10345.0: JCU: Saudi Air Force, ARS 1423 USB MIL 188-141 2G-ALE calling RFU (25Mar17) (AAI)
10425.0: JAI: Saudi Air Force, ARS 0842 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to BPR (07Apr17) (AAI)
10425.0: JAI: Saudi Air Force, ARS 0846 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to BPN (07Apr17) (AAI)
10539.6: ---: Unid 0826 (cf) (04Apr17) Siemens CHX-200 modem selcall (04Apr17) (AAI)
10627.0: ---: Unid 0931 3G-HF 2-way FLSU handshake followed by HDL6 transfer (04Apr17) (AAI)
10627.0: ---: Unid 1011 USB 3G-HF 2-way FLSU handshake followed by HDL6 transfer (05Apr17) (AAI)
10627.0: ---: Unid 1122 USB 3G-HF 2-way FSLU handshake followed by HDL traffic (28Mar17) (AAI)
11010.0: ---: Unid 0746 USB Arcotel MAHRS-2400 serial modem (05Apr17) (AAI)
11050.0: ST3: presumed Egyptian net, EGY 1331 USB MIL 188-141 2G-ALE LQA REQUEST RESPONSE to SHARK3 (05Apr17) (AAI)
11168.6: KWT94: Unid US DoS station 1322 USB MIL 188-141 2G-ALE sounding (05Apr17) (AAI)
11186.0: ---: Unid 1307 USB 3G-HF 2-way FSLU handshake followed by HDL traffic (28Mar17) (AAI)
11347.0: 9GQK: Ghana Navy, GHA 0904 USB MIL 188-141 2G-ALE sounding (24Mar17) (AAI)
11820.0: AAC: Unid (Israeli Air Force ?) 0746 USB MIL 188-141 2G-ALE calling AAA (05Apr17) (AAI)
14426.8: ---: Russian Diplo/Intel 1235 (cf) mixed mode 5 x MFSK-16 10Bd/20Hz, BPSK 250Bd insertions each 10 secs (04Apr17) (AAI)
16350.6: ---: Russian Diplo/Intel 1215 (cf) mixed mode 5 x MFSK-16 10Bd/20Hz, BPSK 250Bd insertions each 10 secs (06Apr17) (AAI)
18292.8: ---: Russian Diplo/Intel 1140 (cf) mixed mode 5 x MFSK-16 10Bd/20Hz, BPSK 250Bd insertions each 10 secs (04Apr17) (AAI)
18475.0: 1BGQY: Unid US net 1603 SB MIL 188-141 2G-ALE calling 57YMD (30Mar17) (AAI)
18475.0: 5M81G: Unid US net 1624 SB MIL 188-141 2G-ALE calling 5GZ7D (30Mar17) (AAI)
18475.0: 5QMG8: Unid US net 1402 SB MIL 188-141 2G-ALE calling BM57G (30Mar17) (AAI)
18475.0: 5QMG8: Unid US net 1520 SB MIL 188-141 2G-ALE calling 5GZ7D (30Mar17) (AAI)

↧
↧

a possible EMCON retransmission mode for Multicast Data Link protocol ?

April 10, 2017, 6:14 am
$
0
0

This is an MDL-N (Multicast Data Link with NACKs) transfer received on 10958.0 KHz/USB. The transfer begins with an FLSU Point-to-MultiPoint call (BW5) followed by four forward transmissions consisting of LDL288 DATA PDUs (BW3); the ending BW4 burst is the LDL EOM PDU informing the receiving stations that the entire datagram has been transmitted. In MDL-N each forward transmission is followed by a pause, during which receivers that were not able to decode that transmission emit a very robust pseudonoise PSK symbol sequence to request retransmission: in this sample there is no NACK PDUs issued by the receiver stations.

At a first glance, one could say that the incoming datagram at the sender has been splitted in four LDL 288-byte data packets (unless the padding bytes in the last packet) which are then forwarded using four BW3 bursts ...but things are not properly in this way.
Indeed, looking at Figures 1-2,  it's easy to notice that packets #1 and #2 are exactly the same, as well as the packets #3 and #4 (275 bytes length). 

Fig. 1 - packets #1, #2
Fig. 2 - packets #3, #4
This means that each packet is sent twice before to clear the TxFrame buffer, so that the receiver stations have two copy of the same message, each obtained by adding the packets #1, #3 and the packets #2, #4 (Fig. 4)

Fig. 4 - thereceived entire datagram
(note that the encryption is applied before the datagram is segmented).

According to these observations, I try to give an explanation that makes sense to that scenario.
For a reliable transmission of the message, each packet is always sent twice (at leats in this sample): a station that decodes the entire error-free message can deliver the message and discard the copy. Otherwise it must process the copies and attempt to correctly decode the message. Summarizing: each packet is transmitted n-times instead of n-retransmissions of the complete message.  This redundancy mechanism contrasts with the chance of use ACK/NACK PDUs, but it could be a good solution in case of receiver stations which must remain in EMCON mode (radio silence) for extended periods and consequently can't send NACKs neither delayed acknowledgements. Most likely, a sort of 'EMCON retransmission counter' indicates the number of times each packet shall be retransmitted while in the EMCON retransmission mode, accordingly to the established xDL PDUsfor that transmission.

The same behavior has been observed also in a standard PTP LDL ARQ transfer (Fig. 5), but this could be the case of a retransmission requested by the receiver station (in this case the same FEC phase is retransmitted).

Fig. 5

As pointed out, this'retransmission mode' is a my thought, a supposition based on what I see: I do not know if it's  just a coincidence or a sort of implementation of STANAG-4538 MDL since I have not found confirmations in the documentation that is publicy available in the web. Further recordings are needed in order to better understand this kind of scenario. By the way, your comments are welcome.


 https://yadi.sk/d/J8mreWoP3Go2ip



↧

an LDL160 transfer with nine retransmissions

April 15, 2017, 1:11 am
$
0
0

this is a copy of an 10 x LDL160 transfer, heard on 8327.0KHz/USB, with up to nine retransmissions of the same 'Citadel' encrypted  data packet (Fig. 1). Since the LDL forwards are followed by ACKs from the receiver station, although they are faintly visible, the nine retransmissions could be due to repeat requests.

Fig. 1
The analysis of the last 64 bits of each BW3 bursts shows a fixed structure in the Sequence Number field: if the reps had been in the datagram passed to the LDL protocol then the sequence number would have been incremented (Fig. 2)

Fig. 2
As said, since the ARQ ACK mechanism of xDL protocols, it could be that the nine retransmissions are requested by the receiver (bad channel conditions at receiver side?) but it could also be a technique to improve the reliability of the transmission: transmitting the same information more than once (each time encoded using alternate FEC codes) during a particular link increase the probability that user data will be received correctly.






↧

housing of data packets in a HDLn Tx Frame

April 18, 2017, 8:40 am
$
0
0
This recording is nothing special but rather a good example in order to study and verify the way the data packets are housed in an HDLn Tx frame and the mechanisms used to fill the unused room when the length of the outgoing datagram is less than the length of the Tx frame of the used HDLn version (n = 3,6,12,24 packets each of 233 bytes). Particularly, the recording concerns a 1889-byte lenght 'Citadel' encrypted datagram which is sent in one HDL12 PDU, ie using 233 x 12 = 2796 bytes: the protocol shall use the extra space of 907 bytes adding 0-value bytes and reinserting one or more data packets (Fig. 1).

Fig. 1
For what concerns the on-air signal (Fig. 2), the HDL12 PDU is trasmitted within a BW2 waveform across an already-established HF link (FLSU/BW5) and is folowed by three EOM PDUs (BW1) sent by the transmitter station meaning that entire datagram has been successfully delivered. The HDL12PDU is acknownledged by an ACK PDU (BW1) transmitted by the receiver station. The logical link will be terminated by a couple of FLSU exchanged  between the two stations. The transmission was copied on 8327.0 KHz/USB.

Fig. 2
For a better understanding of the way HDL protocol arranges the extra 917 bytes, let's see how the HDL PDU and BW2 are formed (quoting Annex C to NATO STANAG-4538).
For each of the first data packet positions in HDL TxFrame buffer (12 positions in this case), if the data packet position is empty, construct a new outgoing data packet in this position:
1. Get the next data segment (the next 233 consecutive data bytes to be transmitted) from
TxDatagram buffer; place these in the payload field of the data packet. If fewer than 233 data bytes remain to be transmitted, place these bytes at the beginning of the payload field; fill the remainder of the field with zero bytes.
2. Construct a sequence number value and write this value into the packet’s Sequence Number field.
 3. If TxDatagram buffer is completely emptied of payload data before all packet positions in TxFrame buffer have been filled with new packets, fill the remaining packet positions with repetitions of packets already residing in other positions of TxFrame buffer. The HDL transmitter is at liberty to select packets from the current datagram to repeat as it pleases; the HDL receiver must inspect the sequence number of each packet received without errors, and use this information to discard duplicate packets. 
4. Send an HDL PDU containing the tx frame in TxFrame buffer, using BW2 waveform.

Fig. 3 - formation of the HDL12 Tx fame for this example
The 0-value bytes and the packet repetions are well visible in Fig. 1.

During the construction of BW2 waveform structure, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the 1881 payload data bits in each data packet (1864 bits of user data, plus a 17-bit Sequence Number added by the protocol), and is then appended to the data packet. The seven encoder flush bits with values of zero (Flush) are then appended to produce an Extended Data packet of 1920 bit length that will be used for FEC, frame formation, symbol formation, and so on. 

From theory to practice, the way the data packets are housed in TxFrame buffer can be verified by inspecting the  Sequence Number fields in the last 56 bits of the first nine BW2 extended data packets of the copied transmission (Fig. 5).

Fig. 5 - the last 56 bits (Sequence Number + CRC + Flush) of the copied BW2 Extended Packets
As expected, EOM and SOM fields (bits 16,15) show that the positions 0 and 9 of the TxFrame buffer are both filled with the first packet of the datagram, while position 8 of the TxFrame buffer is filled with the last packet of the datagram. Consequently, the Packet Number (bits 5-0) starts from 0 to 8: ie, the useful payload consists of 9 packets (note also that positions 0 and 9 have the same Packet Number).
Consider now the Packet Byte Count (bits 14-6): this filed show the number of user bytes in packet –1. The first eight packets, positions 0-7, contain 233 bytes (011101000 = 232) and the last packet, in position 8, contains 35 bytes (000100010 = 34). The outgoing datagram was then (8 x 233) + 35 = 1899 bytes length.

One could say "since the datagram length is 1899 bytes and fills 9 data packets, why don't use 1 HDL6 PDU + 1 HDL3 PDU?". It would be impossible.
During the link setup phase, the session manager process determines the number of data packets per HDL PDU (3, 6, 12, or 24) shortening the HDL PDU whenever the entire datagram is short enough to fit within the shortened PDU. Once it is determined, the number of data packets per HDL PDU for the current datagram delivery remains unchanged, ie every HDL PDU contains the same number of data packets until the entire datagram has been delivered (so: 3 x HDL3 PDUs, or 2 x HDL6 PDUs, or just 1 HDL12 PDU... btw more PDUs means the more turnaround time).



https://yadi.sk/d/wcvQBJfr3H75uc
https://yadi.sk/i/j0nqeWiC3H75x9 
↧
Viewing all 623 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>