31 May 2017

3G link + S5066: example of Circuit Mode (HF2000, Swedish Army)

Nice example of how to send STANAG-5066 data on a 3G link, using the Circuit Mode service provided by the 3G-HF STANAG-4538 profile.
The link is established with the 1-way FLSU procedure then 188-110A Serial at 1200 bps is used for the data transfer. After the transfer is completed, an FLSU_Term PDU is sent by the caller and the link is terminated (Fig. 1).

Fig. 1
The most interesting aspect is the use of STANAG-5066, which has been detected thanks to the lack of the encryption before the MS110 modem: indeed, STANAG-5066 allows to indentify the Authority/Country by the addresses coded into the Data PDU (D_PDU), unless dummy addresses are used:

Once removed the overhead bits added by MS110, the D_PDUs can be isolated by syncing the resulting bitstream with the sequence 0xEB90 (regardless of type, all the D_PDUs begin with the same sync sequence): the result is displayed in Figure 2.

Fig. 2
The Size-of-Address Field specifies the number of bytes in which the source and destination address are encoded, the address field may be from 1 to 7 bytes in length (as in this case), with the source and destination address of equal length.The first half is the destination address and the second half is the source address:

In this case:
source address:
destination address:
both belonging to the block 6.46.x.y allocated to Sweden (Table N-6 European National Addressing Schema):

Fig. 3
post continues here:

28 May 2017

short log

05825.0: ---: Ukraine Militay, UKR 0618 USB MFSK-4 (double FSK) 100Bd 500Hz,(tones at -750, -250, +250, +750) (18May17) (AAI)
06547.0: SHANWICK: Shanwick MWARA IRL 2023 USB/J3E ATC in comms w/004 (17May17) (AAI)
06873.5: XEN: Unid UK-DHFCS node, UK 2054 USB MIL 188-141A handshake w/XSS followed by MIL 188-110A Serial (17May17) (AAI)
07505.9: XLA: Unid 0808  USB MIL 188-141A call to XLB (19May17) (AAI)
07510.0: HI9: Polish Military, POL 0751 USB MIL 188-141A call to HE5 (19May17) (AAI)
07510.0: HI9: Polish Military, POL 0908 USB MIL 188-141A call TU9 (22May17) (AAI)
07559.0: ---: Unid 0741 3G-HF 2-way FLSU handshake followed by LDL320 sending 591 bytes Citadel encrypted datagram (20May17) (AAI)
07594.5: OEY: Austrian Army, AUT 0848 USB MIL 188-141A call OEY61 (22May17) (AAI)
07605.0: LEONE1: Italian Air Force airborne, I 0754 J3E/USB in comms with ground "take off at 52" (22May17) (AAI)
07628.0: PI: French Navy ODPI Toulon, F 1141 J3E/USB in comms w/FLA, QSLing RATT 75Bd/850 KG-84 encrypted message sent from FLA (QSL de votre message) (20May17) (AAI)
07655.0: RAM: Roumenian Police Ramnicu Valcea, ROU 0831 USB MIL 188-141A call to 1PY (18May17) (AAI)
07655.0: VAS: Roumenian Police Vaslui, ROU 0837 USB MIL 188-141A call to 1PY (18May17) (AAI)
07669.0: ZM55: Unid (presumed Algerian Mil.) 1603 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
07669.0: ZM66: Unid (presumed Algerian Mil.) 1600 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
07669.0: ZM68: Unid (presumed Algerian Mil.) 1608 USB MIL 188-141A  2-way LQA exchange w/NX50 (20May17) (AAI)
07711.6: ---: Unid 0730 (cf) continuous RATT 75Bd/850 (20May17) (AAI)
07754.0: Z01: Unid, prob. Polish Military 0845 USB MIL 188-141A call KA1 (22May17) (AAI)
07765.0: BX80: Unid 0736 USB MIL 188-141A LQA Request Response to NX80 (20May17) (AAI)
07766.5: B10: Unid, prob. Ukrainian net 2012 USB MIL 188-141A sounding (17May17) (AAI)
07830.0: WG01: Algerian Military, ALG 0912 USB MIL 188-141A call NX01 (22May17) (AAI)
07890.0: KB15: Unid (presumed Algerian Mil.) 1546 USB MIL 188-141A 2-way LQA exchange w/NX10 (20May17) (AAI)
07890.0: KB17: Unid (presumed Algerian Mil.) 1545 USB MIL 188-141A 2-way LQA exchange w/NX10 (20May17) (AAI)
07890.0: KB20: Unid (presumed Algerian Mil.) 1543 USB MIL 188-141A 2-way LQA exchange w/NX10 (20May17) (AAI)
07899.0: NX40: Unid (presumed Algerian Mil.) 1247 USB MIL 188-141A LQA Request Response to XS62 (21May17) (AAI)
07899.0: XS54: Algerian Military, ALG 1556 USB MIL 188-141A LQA Request Response to NX40 (20May17) (AAI)
07937.0: EVW: Unid 1508 USB MIL 188-141A handshake w/TJ4 (20May17) (AAI)
07945.5: ANOUAL2: Moroccan Military, MRC 2018 USB MIL 188-141A sounding (17May17) (AAI)
07964.0: ZM60: Unid (presumed Algerian Mil.) 1519 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
07964.0: ZM60: Unid (presumed Algerian Mil.) 1519 USB MIL 188-141A LQA Request Response to ZM40 (20May17) (AAI)
07964.0: ZM64: Unid (presumed Algerian Mil.) 1530 USB MIL 188-141A LQA Request Response to NX50 (20May17) (AAI)
08020.0: 88: Italian Air Force C-27J Spartan "MM62214 46-88", I  0914 USB MIL 188-141A call CHARLY46 (22May17) (AAI)
08023.0: BX80: Unid 0739 USB MIL 188-141A LQA Request Response to NX80 (20May17) (AAI)
08023.0: FQ71: Unid 0813 USB MIL 188-141A LQA Request Response to NX80 (20May17) (AAI)
08034.0: ---: Unid 0808 3G-HF 2-way FLSU handshake followed by Circuit Mode service using MIL 188-110A Serial (20May17) (AAI)
08061.0: RK37: Unid (presumed Algerian Mil.) 1551 USB MIL 188-141A LQA Request Response to NX30 (20May17) (AAI)
08162.0: 035: Ungarian Military, HNG 1514 USB MIL 188-141A LQA Request Response to 093 (20May17) (AAI)
08190.0: CAVATORTO: Italian GdF patrol boat, I 0723 USB MIL 188-141A call to BARBARISI (17May17) (AAI)
08195.0: 1PY: Roumenian Police, ROU 0729 USB MIL 188-141A 2-way LQA exchange with SIB Sibiu (22May17) (AAI)
08582.0: P52: Moroccan Military, MRC 2048 USB MIL 188-141A sounding (17May17) (AAI)
08582.0: X42: Moroccan Military, MRC 2048 USB MIL 188-141A sounding (17May17) (AAI)
09044.0: ---: Unid, prob. Russian Mil/Diplo 1257 (cf) FSK 300Bd/500 360-bit ACF (18May17) (AAI)
09274.0: ---: Unid 1155 (cf) RACAL MA4248 "MEROD" FSK 266.7Bd/800 bursts, call to @VW96G61B (15May17) (AAI)
10225.5: ---: Unid 0929 USB Unid QPSK 2400Bd burst system, 180-bit ACF (modified Stanag-4539 TDMA?) (23May17) (AAI)
10425.0: ---: (no call) Unid 0714 USB MIL 188-141A LQA Request Response to 1VR (20May17) (AAI)
10853.5: XCF: Unid UK-DHFCS node, UK 1318 USB MIL 188-141A call to XSS (18May17) (AAI)
10935.5: ---: Unid 0921 USB MIL 188-141A Linking Protection mode handshake followed by MIL 188-110A Serial modem (23May17) (AAI)
11032.0: ---: Unid (presumed Bulgarian Diplo) 0830 USB RFSM-8000 with data-masking (22May17) (AAI)
11050.0: ND1: Unid 1457 USB MIL 188-141A handshake w/SK1 followed by MIL 188-110A Serial (19May17) (AAI)
11165.0: AOS: Algerian Air Force Ain Oussera, ALG 0802 USB MIL 188-141A call CM1 (22May17) (AAI)
11430.0: ZRO: NATO NCS 0809 USB MIL 188-141A call STM (23May17) (AAI)
11430.0: ZRO: NATO NCS 0828 USB MIL 188-141A call ACR (23May17) (AAI)
11543.0: ---: Unid 0751 USB 3G-HF 2-way FLSU handshake followed by HDL+ (22May17) (AAI)
13110.0: ---: Unid, prob. Russian Mil/Diplo 1330 (cf) FSK 300Bd/500 360-bit ACF (18May17) (AAI)
13560.0: ---: Russian Navy, RUS 0739 (cf) CIS Navy "Akula", FSK 500Bd/1000 (23May17) (AAI)
15040.0: 240: Unid 1342 USB MIL 188-141A sounding (18May17) (AAI)
15858.0: MHFCS network, AUS 1350 ISB, GFSK 600Bd/340 on LSB & FSK 50Bd/340 on USB (17May17) (AAI)
17409.5: ---: Uk Mil/Gov, UK 0728 USB WINDRM modified waveform OFDM 51-tone (23May17) (AAI)

26 May 2017

FSK 100Bd/620, Polish Intel

update (26May17)

This morning I copied a transmission on 10211.6 KHz/USB with same ACF (96 bit) but with different frame structure that exhibits a sort of 24-bit length "preamble" followed  by 16-bit length data blocks (8+8 UK) and resembling, in some way, the Stanag/MIL-STD framing.



FSK 100Bd/620, Polish Intel (10Feb16)

FSK-2 modulation with 620 Hz shift and 100 Baud speed, in use by Polish Intel service.

pic. 1 - baudrate and shift
The signal exhibits clean ACF spikes at 96 bits (~960ms lenght). Looking more closely one can distinguish six periods of 16 bits, most likely they represent a five digits code and a separator between the groups as also shown in the bitstream (pic. 3).

pic. 2 - 96 bits ACF (6 x 16 bits digits)
pic. 3
Looking at the whole demodulated bitstream (pic. 4), although inclusive of the overhead bits, we can get an idea of the signal structure. First of all, note that the ACF is due to the final part "D" and then does not characterize the entire signal but only a part. While the parts A and E can be assumed as the 'start' and 'end' of transmission, it's difficult to fix the roles of the other groups: message, destination address, coded-instructions and so on. Talking with my friend KarapuZ, he says we need much more recordings for statistic comparisons since a previous recording of 2014 just exhibits that same characteristics. And if he says so...

pic. 4

24 May 2017

Doppler spread monitoring in 9 MHz band signals

Looking for "Spectan" software download I come across an interesting  web page  about the "Precision Carrier Doppler Analysis": intrigued by this argument, I tried to replicate the Doppler spread analysys and these are the results of my one-day monitoring of two transmissions in the 9 MHz band (9182.0 and 9115.0 KHz, both in USB).

Due to the time-varying nature of the ionosphere, the propagation path is never static and the received sky-wave signals may suffer distortion in the form of temporal dispersion (delay spread) as well as fluctuation in the signal’s amplitude and phase (Doppler spreading). Recent high latitude measurements have observed multipath signals of more than 10 ms duration and other signals have shown evidence of Doppler spreading greater than 50 Hz. More typical mid-latitude sky-wave channels might show delay spreads of 1 - 4 ms with Doppler spreads of 1 Hz or less.
In a few words, Doppler spread occur because during the day the apparent height at which signals are reflected changes quite markedly, leading to quite easily observable frequency shifts. It is the rate of change of apparent height which is related to the frequency shift. Doppler spread  is commonly defined as the range of frequencies over which the received Doppler spectrum is essentially non-zero. When a pure sinusoidal tone of frequency fc  is transmitted, the received signal spectrum will have components in the range fc – fd to fc + fd , where fd is the Doppler shift. 

Looking for suitable transmissions to monitor, I decided in favor of the continuous B'casts of the Russian Navy on 9 MHz band: such transmissions are on USB and use the AT-3004D modem known as CIS-12. The signal consists of 12 BPSK modulated tones (MPSK), 120 bps per channel, with a Pilot Tone at ~3300 Hz which is just used for Doppler correction at receiving sites.

1) daylight path, 9182.0 KHz CIS-12 transmission (Fig. 1)

Fig. 1
During the daylight path the  the Doppler spread is less than 1 Hz (as expected), since during the day the D layer supposedly absorbs the signal before it reaches the ionosphere. However, the absorbtion is not always complete, and the signal is also propagted via its E-layer daytime reflection. The E layer is relatively stable, and shows little Doppler spread (Fig. 2).
Starting from about 1630 UTC (Fig. 3), the region of the transmitter enters in its Grey Line and the signal starts to be seen from various scatter paths and then reflected from the F-layer. The rise of the Doppler spread is quite easily observable.

Fig. 2
Fig. 3
2) darkness path (after local sunset), 9115.0 KHz CIS-12 transmission (Fig. 4)
Fig. 4
Starting from about 17.30-1800 UTC (summer time, in my area) the D layer stops absorbing completely, and the signal starts to be reflected from the F-layer. At this time the effective height of the F layer is rising as ion density decreases and the Doppler spread reflects the instability of the F layer. I do not know the reason of the drift around 20.00 UTC.

Fig. 5
Fig. 6
It's interesting to see that the two transmissions have Doppler tones which differ of about 10 Hz: most likely it is due to two different transmitters.

3) setup
As said, the software used for this monitoring is "Spectran" - Current version : Version 2 build 216 - and it can be downloaded from http://www.weaksignals.com/
Spectran is a spectrum analyzer written by Alberto, I2PHD and Vittorio, IK2CZL, members of the PAcket Digital Amateur Network group (PADAN), who created also other weak signal and QRSS programs. Spectran allows real time or deferred spectral analysis / waterfall display, in addition to real time audio filtering (band pass, denoising, band reject and CW peaking) of audio signals, using the PC sound card to digitize the input analog signal, or taking as input a WAV file. Its characteristics are well suited to dig weak signals buried into noise, thanks to a selectable bin size down to 21 millihertz.

The "Doppler mode" settings that I used for this monitoring are shown in Figure 7:

Fig. 7
And... yes, It would be much more interesting to monitor the same transmission for more than one day and in different seasons, but this is not my job :)

17 May 2017

RACAL MA4248 "MEROD", ARQ FSK 266.6Bd/800Hz

The transmission was heard on 9274.0 (cf) and consists of FSK-2 bursts with shift of 800Hz and manipulation speed of 266.67 Baud. Thes features points at the RACAL MA4248 device, also known as MEROD (Message Entry Read Out Device): thanks to my friend KarapuZ for the help in identification.

Fig. 1 - manipulation speed
Fig. 2 - FSK shift
Once demodulated the signal, the measured period is 48 bits:

Fig. 3 - 48-bit period
The RACAL MEROD transmissions can be decoded by Code-300, although the contents are encrypted: 

Fig. 4 - MEROD RAC-ARQ mode running in Code-300

The RACAL MA4248 "MEROD" device was  designed for sending messages in burst transmission mode over HF/VHF/UHF radio links and were therefore used by special forces in combination with a man pack radio, these unit is also known as a tactical data entry device, TDED. MA4248 utilise a complex error correction system that ensures that the message can be correctly received over very poor quality HF links.

Fig. 5 - RACAL MA4248 device

12 May 2017

Logs from Tuscany

07500.0: AI1: Algerian Military, ALG 0721 USB MIL 188-141A LQA Request Response to XV1 (10May17) (AAI)
07509.0: ---: Unid 0714 USB 2-way FLSU handshake followed by HDL+ datagram (10May17) (AAI)
07545.5: ---: Unid 0742 (cf) RATT 75/850 encrypted tfc (10May17) (AAI)
07554.6: FUG: French Navy Saissac, F 0810 USB STANAG-4285 1200bps/L continuous pseudo-random broadcast (10May17) (AAI)
07570.0: KA31: Algerian Military, ALG 1537 USB MIL 188-141A, LQA REQUEST RESPONSE to NX30 (28Apr17) (AAI)
07572.0: MATADOR: Unid Spanish station 0740 J3E/USB radio-check (same for other heard calls such as TIGRE,Arion,PAISAN,...) (25Apr17) (AAI)
07580.0: IN4: Unid 0626 USB MIL 188-141A call to TMR410 (09May17) (AAI)
07626.0: 277: Unid prob. Chinese Diplo, CHN 1745 USB MIL 188-141A, handshake w/ 278 followed by MIL 188-110A serial (28Apr17) (AAI)
07655.0: 1PY: Roumanian MOI/Police, ROU 0733 USB MIL 188-141A LQA Request Response to CAL (10May17) (AAI)
07660.0: ---: Unid 0630 USB 2-way FLSU handshake followed by LDL128 'Citadel' encrypted 628 bytes datagram (09May17) (AAI)
07660.5: ---: Unid USB THALES Skymaster, ALE Skyhopper mode (09May17) (AAI)
07732.5: BM11: Belgian Military - NATO PfP exercise, B 0757 USB/J3E working AM11, SVK1 (Slovakian Mil.) (03May17) (AAI)
07775.0: HA9: Polish Military, POL 0829 USB MIL 188-141A LQA Request Response to DU6 (09May17) (AAI)
07788.0: BD: Algerian Navy "Rais Hamidou" class corvette, ALG 1406 USB STANAG-5066 CFTP test msgs exchange w/ PI, COMTOULON Toulon French Navy, MIL 188-110A as HF carrier (26Apr17) (AAI)
07830.0: MDN: Algerian Ministry of Defense, ALG 1355 USB MIL 188-141A LQA Request Response to NX01 (02May17) (AAI)
07885.0: SAZ: Unid (Swedish Military?) 0652 USB MIL 188-141A LQA Request Response to WWX (09May17) (AAI)
07890.0: NX10: Unid 0826 USB MIL 188-141A call to KB11 (09May17) (AAI)
07899.0: XS61: Algerian Military, ALG 1343 USB MIL 188-141A handshake w/ NX40 followed by (likely Harris AVS) scrambler (02May17) (AAI)
07964.0: ZM53: Unid 0919 USB MIL 188-141A 2-way LQA exchange with NX50 (10May17) (AAI)
08010.0: ---: Ukraine Militay, UKR 0652 USB MFSK-4 (double FSK) 100Bd 500Hz,(tones at -750, -250, +250, +750) (03May17) (AAI)
08054.0: BX02: Algerian Military, ALG 0622 USB MIL 188-141A LQA Request Response to BX01 (05May17) (AAI)
08061.0: RK37: Algerian Military, ALG 1336 USB MIL 188-141A call to NX30 (02May17) (AAI)
08066.0: CO1: Unid 0650 USB MIL 188-141A LQA Request Response to BE1 (long scanning call) (10May17) (AAI)
08066.0: CO1: Unid 0802 USB MIL 188-141A LQA Request Response to BE1 (long scanning call) (09May17) (AAI)
08067.0: ---: Unid 0746 (cf) BELL 103 compatible modem (10May17) (AAI)
08073.0: ---: Russian Intel/Diplo, RUS 0735 USB MFSK-64 (32+32) 45Bd modem (10May17) (AAI)
08083.5: ---: Unid 0833 USB 2-way FLSU handshake followed by HDL+ datagram (09May17) (AAI)
08092.0: 343013: Turkish Civil Defense, TUR 0819 USB MIL 188-141A sounding (09May17) (AAI)
08125.0: OS5: Polish Military, POL 0707 USB MIL 188-141A LQA Request Response to A9 (10May17) (AAI)
08128.2: ---: Unid 0816 USB STANAG-4285 1200bps/L continuous pseudo-random broadcast (10May17) (AAI)
08132.0: BP26: German Police vessel, D 0604 USB MIL 188-141A handshake w/ BPLEZS followed by R&S GM2100 modem transporting R&S X.25 login procedure (03May17) (AAI)
08182.0: XJJ: UK-DHFCS, G 0834 USB MIL 188-141A, several handshakes w/ XSS followed by MIL 188-110A serial (28Apr17) (AAI)
08195.0: ---: Russian Military, RUS 0825 (cf) FSK 40.5Bd/500 (CIS 81-81 single channel variant), no traffic (10May17) (AAI)
08204.5: ---: Unid 0740 (cf) RATT 75/850 encrypted tfc (10May17) (AAI)
08327.0: ---: 0729  USB 2-way FLSU handshake followed by HDL6 sending 'Citadel' encrypted datagram (29Apr17) (AAI)
08327.0: ---: Unid 1545 USB 2-way FLSU handshake followed by LDL32 sending 139 bytes 'Citadel' encrypted datagram (28Apr17) (AAI)
10539.6: ---: Unid 0844 (cf) Siemens CHX-200 modem selcall (02May17) (AAI)
10601.0: ---: Unid 1529 USB MIL 188-141A running in Linking Protection mode (28Apr17) (AAI)
10751.0: ---: Unid 1407 (cf) FSK 300Bd/500 messages, 360-bit ACF (28Apr17) (AAI)
10833.0: ---: Unid 1511 USB MIL 188-141A running in Linking Protection mode (28Apr17) (AAI)
10900.0: ---: Unid 0913 USB 3G-HF 2-way FLSU handshake followed by 2 x HDL12 data transfer (04May17) (AAI)
10935.0: 830NETIP: Unid 1355 USB MIL 188-141A call SORIA06NETIP (05May17) (AAI)
10935.0: SORIA06NETIP: Unid 1355 USB MIL 188-141A call 830NETIP (05May17) (AAI)
11010.0: ---: Unid 1619 USB ARCOTEL MAHRS 2400Bd serial modem (10May17) (AAI)
11125.0: ---: Unid 1615 Hagelin HC-256 voice scrambler (10May17) (AAI)
11132.0: ---: Unid 0935 USB 3G-HF 2-way FLSU handshake followed by HDL+ data transfer using BW7 QAM-16 bursts (Stanag-4539 HF waveform) (04May17) (AAI)
11132.0: ---: Unid 1051 USB 3G-HF MDL transfer using LDL416 sending 'Citadel' encrypted datagram (30Apr17) (AAI)
11135.0: HQ4: Unid 0710 USB MIL 188-141A LQA Request Response to GANOB8, AMD "IFBUIFSHSBIBN" (05May17) (AAI)
11156.0: LAG: Algerian Air Force Laghaout, Alg 0900 USB MIL 188-141A handshake CM4 followed by MIL 188-110A Serial (07May17) (AAI)
11168.6: KWX57: US DoS Ankara, TUR 0829 USB MIL 188-141A LQA Request Response to WNG767 US DoS Pristina/Kosovo (04May17) (AAI)
13373.0: ---: Russian Mil, RUS 1130 USB CIS-45 HDR modem v2, OFDM 45-tone 40Bd DQPSK (03May17) (AAI)
13555.0: ILZ: Algerian Air Force, ALG  0913 USB MIL 188-141A, LQA REQUEST RESPONSE to CM4 (30Apr17) (AAI)
14623.0: D78: Unid, prob. Chinese net 1304 USB MIL 188-141A, LQA REQUEST RESPONSE to A98 (30Apr17) (AAI)
15957.0: ---: Russian Air Force, RUS 1256 (cf) FSK 50Bd/500, encrypted messages (02May17) (AAI)

10 May 2017

CIS 81-81 single channel variant, FSK 40.5Bd/500Hz

this is a single channel variant of CIS T-206-3M (3M1) modem that operates at a speed of 81 Baud in case of two stations are worked (two distinct channels). It's a quite "old" system, most likely in use by some ex USSR republic. 
The recordered transmission has been copied on 08195.0 KHz (cf) during an idling cycle.

8 May 2017

interesting paper about IP Multicasting in HF Radio Networks

I recently found in the web the interesting paper titled IP Multicasting in HF Radio Networks (2008) that proposes a multicast data link protocol for third generation (3G) high frequency (HF) radio networks:
I have a doubt about the "MDL Operation" paragraph and the related Figure 3 of the paper:

According to §4.6.5 "Dual Demodulation" of Annex-C to STANAG-4538 Ed.1: under no circumstances shall PUs be required to simultaneously demodulate more than two waveforms.
Well, at time "tn" in Figure 3 the receiving PUs expect an LDL_DATA PDU (BW3) or an LDL_EOM/TERM PDU (BW4): sending a FLSU PDU (BW5) would impose a triple demodulation requirement. 

Thus, the calling PU shall send an LDL_EOM PDU (BW4) to indicate that the entire datagram has been transferred and the FEC Phase 0 session is terminated; then the following FSL PDU (BW5) will be sent to announce the repetition of the datagram in the alternate FEC code:

Anyway, since the multicast scenarios proposed in the paper have been evaluated using the DoD-validated HF Network Simulator (NetSim-SC), and then not implemented in real radios, the procedure depicted in Figure 3, although wrong, could be a simplification.

6 May 2017

NATO "copy-and-paste" ...and errors

Computer-based editing can involve very frequent use of copy-and-paste operations but sometimes these operations can lead to significant errors. I came across a case by reading the Annex C to STANAG-4538 Ed.1, more precisely the Amendment 21. The problem arises in "TABLE LDL actions", where is specified (litterally):
"Note: The LDL transmitter can send duplicate packets either as a result of missing an LDL_ACK PDU, or at the end of a datagram, in order to fill the (otherwise unused) packet positions of an LDL_DATA PDU. The LDL receiver is required to inspect the sequence number of each data packet received without errors, and to use the sequence numbers to identify and discard duplicate packets." (highlighted in Figure 1).
Fig. 1
This text is clearly a copy-and-paste from "TABLE HDL actions", unless the the term HDL (Figure 2):
Fig. 2

Well, the statement "The LDL transmitter can send duplicate packets either [...] or at the end of a datagram, in order to fill the (otherwise unused) packet positions of an LDL_DATA PDU."  (Fig .1) is wrong since LDL protocol, contrary to HDL, does not provide 'packet positions' in its DATA PDU but rather one single packet at a time! (each HDL_DATA PDU is a sequence of 24, 12, 6, or 3 data packets, in which each packet is composed of 233 bytes of payload data; each LDL_DATA PDU is a single data packet composed of 32, 64, 96,..., 512 bytes of payload data).

It's an oversight that hopefully will be edited in the next edition :)

5 May 2017

STANAG-4538 HDL+, BW7 QAM-16 waveform

- Burst Waveform 6 (BW6) is used to convey the HDLP_DHDR, HDLP_ACK, and HDLP_EOT PDUs of the HDL+ data link protocol, and to convey PDUs of the FLSU and FTM protocols on a packet link established for delivery of data traffic using HDL+ (note the Link terminate PDU that is conveyed by a BW6 burst). BW6 PDUs bursts have 51 bits of payload, an on-air duration of 386.67 ms, and are transmitted using a PSK-8 modulation.
- Burst Waveform 7 (BW7) is used for transfers of traffic data by the HDL+ protocol. The HDL+ protocol combines high data rate waveforms similar to those of STANAG 4539 or MIL-STD-188-110C Appendix C with incremental redundancy techniques. 

- La burst waveform 6 (BW6) viene utilizzata per trasmettere le PDU HDLP_DHDR, HDLP_ACKe HDLP_EOT del protocollo HDL+ e per trasmettere le PDU dei protocolli FLSU e FTM su link che utilizzano HDL+ (notare che la PDU che termina il link viene infatti trasmessa da un burst BW6 e non da un bust BW5 come avviene nel caso di link che utilizzano HDL e LDL). Le PDU BW6 dispongono di 51 bit di carico utile (payload), una durata in aria di 386,67 msec e vengono trasmesse usando una modulazione PSK-8.
- La burst waveform 7 (BW7) è invece utilizzata dal protocollo HDL+ per il trasferimento dei dati. Per BW7, il protocollo HDL+ combina forme d'onda simili a quelle specificate da STANAG 4539 o MIL-STD-188-110C Appendice C, ma con differenti tecniche di ridondanza incrementale.

Given the variable lengths and modulation formats of HDL+ data, it's necessary to include a header at the beginning of each BW7 PDU (which was unnecessary in LDL and HDL) that announces the number of packets and modulation format of the following payload section of the transmission (HDLP_Data PDU). For this header, the HDL+ uses a BW6 PDU (HDLP_DHDR PDU). 
Since BW6 symbols are modulated using a PSK-8 constellation, the structure composed of BW6-BW7 PDUs
will be clearly visible in those cases where BW7 use a different constellation for its symbols, such as QAM-16 or QAM-64 (BPSK and QPSK are scrambled to appear on-air as a PSK-8 constellation). 

Date le lunghezze variabili e i diversi formati di modulazione dei dati HDL +, è necessario includere una "intestazione" (header) all'inizio di ogni PDU BW7 (che non era necessaria in LDL e HDL) che annuncia il numero di pacchetti e il formato di modulazione della seguente sezione dati della trasmissione (PDU HDLP_Data). Per questa intestazione, HDL+ utilizza una PDU BW6 (PDU HDLP_DHDR). Poiché i simboli di BW6 sono modulati usando una costellazione PSK-8, la struttura composta dalle PDU BW6-BW7 sarà chiaramente visibile nei casi in cui BW7 utilizza una costellazione diversa per la modulazione dei suoi simboli, come ad esempio QAM-16 o QAM-64 (BPSK e QPSK vengono sottoposti a scrambler per apparire in-aria come simboli PSK-8).

Just yesterday, I copied a such HDL+ data transfer on 11132.0 KHz/USB. As displayed in Figure 1, the 8th power harmonics are present for all the duration of the BW5 and BW6bursts, but only in the initial segments of the BW7 bursts, ie in the BW6 PDUs that work as headers. The HDLP_DATA PDUs are instead modulated using a QAM-16 constellation (12 points in the outer ring, 4 in the inner ring).

Proprio ieri, ho copiato una simile trasmissione HDL+ su 11132.0 KHz/USB. Come mostrato in Figura 1, le armoniche di ottavo grado (segno di una modulazione PSK-8) sono presenti per tutta la durata dei bursts BW5 e BW6, ma solo nei segmenti iniziali dei bursts BW7, cioè nelle PDU BW6 che fungono come intestazione. Le PDU dati (HDLP_DATA) sono invece modulate usando una costellazione QAM-16 (12 punti nell'anello esterno, 4 nell'anello interno).

Fig. 1

For what concerns the analysis of the BW7 waveform, no initial synchronization preamble is required since this role is filled by the BW6 HDLP_DHDR PDU. Instead, an initial probe sequence containing two repetitions of a 32-symbol Frank-Heimiller sequence (a total of 64 known symbols) is transmitted.
The following section is used to convey between one and fifteen (inclusive) packets. Each packet is composed of a sequence of unknown/known (“UK”) frames. Each UK frame contains a data block, a sequence of 256 unknown symbols modulated with payload data, followed by a 32-symbol mini-probe. The number of UK frames used to convey each data packet depends on the signal constellation, the code rate, and the payload size.

Per quanto riguarda l'analisi della forma d'onda BW7, non è richiesto alcun preambolo iniziale di sincronizzazione poiché questo ruolo viene svolto dalla PDU BW6 HDLP_DHDR. Invece, viene trasmessa una sequenza iniziale (probe) contenente due ripetizioni di una sequenza Frank-Heimiller a 32 simboli (per un totale di 64 simboli noti). La seguente sezione di viene utilizzata per trasmettere tra uno e quindici pacchetti. Ogni pacchetto è composto da una sequenza di frame sconosciuti/noti (Unknown/known, "UK"). Ogni frame UK contiene un blocco dati, una sequenza di 256 simboli con i dati di payload (sconosciuti), seguito da un mini-probe a 32 simboli (noti). Il numero di frames UK utilizzati per trasmettere ogni pacchetto di dati dipende dalla costellazione del segnale, dalla velocità di codifica e dalla dimensione del payload che deve essere trasmesso.

Fig. 2
Fig. 3
Other than the recording of the transmission, a short video (from my YouTube channel) that illutrates the analysis with SA  is also available.


3 May 2017

STANAG-5066, ARQ & non-ARQ PDUs in a real-world HF radio link

The STANAG-5066 standard, and its second generation Data Link Protocol, provides data transfer using ARQ as well as non-ARQ point-to-point, broadcast or multicast data transfer. The Data Transfer Sublayer (DTS) is responsible for the efficient data transfer across the radio link and use the D_PDU types displayed in Figure 1 to support both ARQ and Non-ARQ services:

Fig. 1 - D_PDU types used by STANAG-5066 DTS
For what concerns the I-frame D_PDUs: 

- the NRQ (No Repeat-Request or non-ARQ) Protocol, commonly known as broadcast mode, only operates in a simplex mode since the local node, after sending I-frames, does not wait for an indication from the remote node as to whether or not the I-frames were correctly received. Multiple repetitions of I-frames can be transmitted in order to increase the likelihood of reception under poor channel conditions, in accordance with the requested service characteristics.

- the SRQ (Selective Repeat-Request) Protocol operates in a half or full duplex mode since the local node, after sending I-frames, waits for an indication in the form of a selective acknowledgement from the remote node as to whether the I-frames were correctly received or not. The local node then either sends the next I-frames, if all the previous I-frames were correctly received, or retransmits copies of the previous I-frames that were not. The local node will retransmit copies of the previous I-frames if no indication is received after a predetermined time interval.

Pinpointing D_PDUs in a real-world HF radio link is not difficult since, regardless of type, they all begin with the same Maury-Styles 16-bit sync sequence 0xEB90, with the least significant bit (LSB) transmitted first
 (MSB) 1 1 1 0 1 0 1 1 1 0 0 1 0 0 0 0 (LSB)
The D_PDU type field occupies the 4 most significant bits of the 3rd byte (Figure 2).

Fig. 2 - Generic D_PDU Frame Structure
The chosen example is a S-5066 data transfer that uses MIL 188-110A Serial as HF waveform (Fig. 3):

Fig. 3- 188-110A over-the-air symbols
Once removed the overhead bits added by 188-110A, the D_PDUs can be isolated by syncing the resulting bitstream with the sequence 0xEB90 (the DS_PDU SYNC sequence): the result is displayed in Figure 4.

Fig. 4
The NON-ARQ DATA (type 7) and EXPEDITED NON-ARQ DATA (type 8) D_PDUs are used to send segmented data when the transmitting node needs no explicit confirmation the data was received (NRQ mode).

Fig. 5 - type 8 D_PDU
The DATA-ONLY (type 0) D_PDU is used to send segmented data when the transmitting node needs an explicit confirmation the data was received. The DATA-ONLY D_PDU is used in conjunction with a basic selective automatic repeat request type of protocol.

Fig. 6 - type 0 D_PDU

The ACK-ONLY (type 1) D_PDU is used to selectively acknowledge received DATAONLY or DATA-ACK D_PDUs when the receiving station has no segmented C_PDUs of its own to send.

Fig. 7 - type 1 D_PDU

As indicated in Figure 2, the header of every D_PDU includes an end-of-transmission (EOT) field. This 8-bit field specifies how much of the current transmission remains, in units of one-half second. This elegantly eliminates the end-of-transmission ambiguity that arises during an extended channel fade. If even a single header is received error-free, the receiver knows when it will be safe to send an ACK. Note that this field bounds the duration of STANAG 5066 transmissions at just over two minutes. This field is also used in case of non-ARQ (type 8) D_PDUS, as displayed in Figure 8

Fig. 8 - the (decreasing value) EOT field

in some cases, the shown results could suffer of the lack of error-frames which have not been correctly demodulated or discarded.