28 August 2017

a weird 3G-2G scenario or a likewise weird coincidence?

For interoperation with legacy systems, STANAG-4538 stations must be capable of accepting and establishing logical links using the second generation Automatic Link Establishment (2G-ALE) protocol specified in MIL-STD-188-141B Appendix A (188-141A). Indeed, STANAG-4538 #4.6.5 "Dual Demodulation" allows this scenario while stations are in the "scanning" state (Fig. 1)
Fig. 1
Looking at the waterfall in Figure 2, it seems that a calling station transmits its FLSU_Request PDU and then, after about 2.6 seconds, it sends a 188-141 2G-ALE call on that same channel.

Fig. 2
Assuming that the heard station can operates in 2G/3G way, and assuming that the FLSU_Confirm response was not sent or not received, this is a violation of S4538. Indeed, since the caller PU did not receive the FLSU_Confirm response, it must send up to N “xDL_Terminate” PDU’s (to abort the ARQ protocol) followed by the FLSU_Terminate PDU. If this were a Circuit Traffic scenario, the “xDL_Terminate” PDU’s would not be necessary, and the caller could send the FLSU_Terminate PDU immediately after the failed call response.

As shown in Figure 2, there is a FLSU_Request PDU only! So:

- or this is a weird way to operate (no Terminate PDUs before the 2G call) for a S4538/S5066 switch

Fig. 3

- or it's a likewise weird coincidence, ie two different stations (and different networks too?) putting their calls in the same channel. 
Anyway, no reply was heard.

Fig.4
BTW, the 2G-ALE Addresses in the play were: XPU (the caller station) and 1VR (the called station).

It's useful to note that you can forward S5066 data link protocols into a 2G-ALE or a 3G-ALE established logical link, BUT you can't do the same when using S4538 xDL data link protocols: in this case the logical link shall be establieshed using 3G ALE (LSU,FLSU).


https://yadi.sk/d/yJRmcMJa3MPpJ7 

25 August 2017

Logs

06233.0: ---: Unid 0622 USB 3G-HF 2-way FLSU handshake / LDL128 tranfser, Harris "citadel" encrypted 811 bytes file (03Ago17) (AAI) (AAI)
06247.4: HWK01: Swedish Armed Forces, S 0632 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, S-5066 Circuit Mode service, unid RCOP client sending data to VJL (01Ago17) (AAI)
06721.0: ADW: Andrews AFB, US 0506 USB MIL 188-141A sounding (28Jul17) (AAI)
06888.5: ---: Unid 2150 USB (cf +1500Hz) R&S ALS 228.6Bd/170, continuous selcall to 210 (16Ago17) (AAI)
06957.0: ---: Unid German Red Cross stn, D 2223 ISB (cf +/- 1700Hz) PacTor-I, selcall DEK25 (14Ago17) (AAI)
06957.0: 049118: German Red Cross, D 2153 LSB USB MIL 188-141A sounding (14Ago17) (AAI)
07450.0: ABC7: Croatian Military, HRV 0745 USB MIL 188-141A call ABH3 (24Ago17) (AAI)
07467.0: PO1: Slovakian Military, SVK 0720 USB MIL 188-141A call SL2 (04Ago17) (AAI)
07509.0: ---: Unid 0711 USB 3G-HF 2-way FLSU / MIL 188-110A Serial, Circuit Mode service (25Ago17) (AAI)
07520.0: ---: Unid 0610 USB 3G-HF FLSU async call, no reply (25Ago17) (AAI)
07545.5: ---: Unid 0815 (cf) Unid encrypted FSK 75Bd/850, // 8204.5 (26Jul17) (AAI)
07594.5: IEA23: Carabinieri Milano,I 0632 LSB radiocheck with IEA20 (25Ago17) (AAI)
07606.0: WK1: US DoS unid station 0527 USB MIL 188-141A call WK2 (18Ago17) (AAI)
07641.0: NX40: Algerian Military, ALG 0654 USB MIL 188-141A call XS74 (03Ago17) (AAI)
07647.0: ---: Russian Intel/Diplo, RUS 0735 USB MFSK-64 (32+32) 45Bd modem (24Ago17) (AAI)
07650.0: ---: Unid 0710 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (04Ago17) (AAI)
07665.0: ---: Unid 0620 USB 3G-HF FLSU request / MDL LDL128 transfer, sending 515 bytes 'Citadel' encrypted file (05Ago17) (AAI)
07713.0: ---: Unid 0738 USB STANAG-4197 ANDVT (24Ago17) (AAI)
07720.0: ASB01D: French Naval Network, F 1013 USB MIL 188-141A call LMP03D, CMD AMD "TEST AMD ASTROLABE" (26Jul17) (AAI)
07830.0: TZ0: Algerian Military, ALG  0755 USB MIL 188-141A call AT01 (24Ago17) (AAI)
07840.0: ---: Unid 0752 USB 3G-HF FLSU call followed by 188-141A XPU call to 1VR, just a perfect coincidence or a mixed 3G/2G ALE system? (24Ago17) (AAI)
07860.0: 123: Algerian Military, ALG 2250 USB MIL 188-141A call AT20 (14Ago17) (AAI)
07860.0: PC20: Algerian Military, ALG 2254 USB MIL 188-141A call NX20 (14Ago17) (AAI)
07860.0: XEN: Unid UK-DHFCS node, UK 0726 USB MIL 188-141A call XSS (05Ago17) (AAI)
07868.0: 2014: Turkish Red Crescent, TUR 1556 USB MIL 188-141A call 40113 [CMD AMD][//A05 4011] (04Ago17) (AAI)
07868.0: 2020: Turkish Red Crescent, TUR 0551 USB MIL 188-141A sounding (12Ago17) (AAI)
07890.0: PE11: Unid 0536 USB MIL 188-141A call to NX10 (18Ago17) (AAI)
07890.0: RS003: Unid CS/RS-Net 0708 USB USB MIL 188-141A handshake RS004 / MIL 188-110A Serial, sending Harris "Citadel" encrypted file using FED-1052 DLP (27Jul17) (AAI)
07898.5: ---: Unid 0709 USB (cf +1500Hz) R&S-ARQ 228.6Bd/170 (ALIS), calling address 478 (14Ago17) (AAI)
07930.0: ---: Unid 0429 USB 3G-HF 2-way FLSU handshake / HDL12 tranfser (28Jul17) (AAI)
08083.5: ---: Unid 0710 USB (cf +1500Hz) R&S-ARQ 228.6Bd/170 (ALIS), calling address 69 (14Ago17) (AAI)
08086.5: ICI: Italian Coast Guard MRCC Roma, I 1037 J3E/USB radio check w/ IGNS patrol vessel CP 277 (04Ago17) (AAI)
08092.0: 83401: Turkish Emergency Net, TUR 1428 USB MIL 188-141A sounding (13Ago17) (AAI)
08132.0: BP21: Bundespolizei Küstenwache Patrol Vessel 'Bredstedt', D 1503 USB MIL 188-141A calling BPLEZS (05Aug17) (AAI)
08132.0: BP24: Bundespolizei Küstenwache Patrol Vessel 'Bad Bramstedt', D 1530 USB MIL 188-141A calling BPLEZS (05Aug17) (AAI)
08132.0: BP25: Bundespolizei Küstenwache Patrol Vessel 'Bayreuth', D 1506 USB MIL 188-141A calling BPLEZS (05Aug17) (AAI)
08132.0: BP26: Bundespolizei Küstenwache Patrol Vessel 'Eschwege', D 1543 USB MIL 188-141A calling BPLEZS (05Aug17) (AAI)
08151.0: TYMT2: Spanish Police Toledo, E 0514 USB USB MIL 188-141A sounding (12Ago17) (AAI)
08182.0: XJM: DHFCS (unid) station, UK 0733 USB MIL 188-141A call XSS (24Ago17) (AAI)
08184.0: PEGASO: EVA (Escuadrón Vigilancia Aérea) Spanish AF Torrejón de Ardoz, S 0910 J3E/USB, voice-comms with TIGRE then data using 188-110A Serial modem (24Ago17) (AAI)
08196.5: ICI40: Italian Coast Guard Compamare Rimini, I 0703 J3E/USB calling ICI08 8^ MRSC Ravenna for radio check (03Ago17) (AAI)
08207.0: ABA: Maltese Navy, MLT 0617 USB MIL 188-141A call AB3 [CMD AMD][/>A2001  ] (01Ago17) (AAI)
08218.0: ---: Unid 0739 USB 3G-HF 2-way FLSU handshake / HDL12 transfer (14Ago17) (AAI)
08327.0: ---: Unid 0645 USB 3G-HF FLSU async call, no reply (25Ago17) (AAI)
10964.0: ---: Russian Navy, RUS 1610 (cf) CIS Navy "Akula", FSK 500Bd/1000 (04Ago17) (AAI)
11090.0: FIRST: Unid Russian net, RUS 1325 USB MFSK-17 126Bd/125Hz burst system (prob. a selcall waveform) / Russian male voice call "FIRST calling TWENTIETH" (27Jul17) (AAI)
11135.0: GANOB8: Unid (presumed Egyptian net) 0723 USB MIL 188-141A call HQ4, AMD "IFBUIFSHS" (21Ago17) (AAI)
11226.0: GUA: USAF AFB Guam, GUM 1538 USB MIL 188-141A sounding (02Ago17) (AAI)
11226.0: PLA: USAF Lajes Fields, AZR 1002 USB MIL 188-141A calling ICZ [HOWS MY DATA?], handshake / voice radio-check  "Sigonella this is Lajes for early voice check, how copy?" (28Jul17) (AAI)
11430.0: ---: Unid 0810 USB 3G-HF 2-way FLSU handshake / HDL12 transfer (21Ago17) (AAI)
11476.0: 2307: Unid 1514 USB MIL 188-141A call 2302 (04Ago17) (AAI)
11500.0: 2014: Turlish Red Crescent, TUR 1533 USB MIL 188-141A call 40113 [CMD AMD][//A05 4017] (04Ago17) (AAI)
11555.5: HBZ: Unid 0704 USB USB MIL 188-141A handshake HFC / MIL 188-110A Serial, sending Harris 'Citadel' encrypted file (28Jul17) (AAI)
14570.0: ---: Unid Ukrainian MIL station, UKR 0605 USB/VFT ITU-T R.38A, channels 1,2,3,4 in stdby - 5,6 active (21Ago17) (AAI)
14581.5: Russian Navy, RUS 1345 T600 50Bd/40 (04Ago17) (AAI)
14969.5: ---: Unid Prob Ukrainian Net 0535 (cf) FSK 100Bd/2000 T-207 encryption (21Ago17) (AAI)
15055.0: ---: Unid 0630 USB STANAG-4197 ANDVT (21Ago17) (AAI)
16986.0: ---: South African Navy, RSA 1421 USB MHF50 HF modem (04Ago17) (AAI)
7669.0: ZM53: Unid 0927 USB USB MIL 188-141A call NX50 (30Jul17) (AAI)
7685.0: ZM62: Unid 0925 USB USB MIL 188-141A call NX50 (30Jul17) (AAI)



24 August 2017

eavesdropping the wheels, a close look at TPMS signals

(ANgazu, Rapidbit, i56578)
My friend ANgazu encouraged me to have a more close look at the signals that populate the V/UHF world and possibly begin to analyze some of them. He invited me to collaborate in the study of TPMS (Tire Pressure Monitoring System) signals: an interesting "in-car" wireless network  designed to monitor the air pressure inside the pneumatic tires on various types of vehicles. Indeed, my collaboration was limited to do a "parallel" study, confirming and commenting the results obtained by ANgazu and his colleague Rapidbit (both from radiofrecuencias.es).


Briefly, "TPMS uses battery-powered pressure sensors inside each tire to measure and transmit tire pressure. Each sensor module communicates its data via a UHF transmitter, commonly the 315 MHz or 433 MHz bands are used. The receiving tire pressure control unit, in its turn, analyzes the data and sned results or commands to the central car computer to trigger warning messages on the vehicle dashboard. The tire pressure sensors will wake up in response to two triggering mechanisms: a speed higher than 40 km/h, detected by an on-board accelerometer, or an LF (125 KHz) RFID activation signal". 
You may find in the web a lot of tech and legal informations about these systems (just to mention United States and European Union which mandates TPMSs on all new vehicles), although, as far as we know, SIGINT-style approaches are quite few: so we decided in favour of this post.

Actually there is not an outright TPMS standard: communications protocols are proprietary, data transmissions commonly use the 315 MHz or 433 MHz bands, and ASK as well as  FSK modulation. Frame structures are different and depend on the manufacturers, mainly the data sent by a TPM sensor are: the sensor ID, temperature and pressure of the associated tire,  sensor status and a CRC field. There is no authentication between sensor and remote control unit, neither encryption of data.
In our case, the system uses the 433 MHz & FSK modulation and each sensor sends a 8-burst train every about 60 seconds, in Figure 1 the dead times between signalings have been deleted.

Fig. 1 - 8-burst trains
Each TPM sensors repeats 8 times the same message at not regular time intervals to avoid collision problems, although collisions and overlappings are frequent, as in Figure 2 (note how the sensors use two slightly different frequencies).

Fig. 2
The on-air FSK waveform have a shift of ~ 550 KHz and a speed of 20.150 KBaud (Fig. 3), once decoded it exhibits a 150-bit length frame consisting of a 10-bit length preamble followed by 140-bit data using Manchester encoding (Figs. 4,5).

Fig. 3 - FSK parameters
Fig. 4 - Auto Correlation Function
Fig. 5 - 150-bit period (4 bursts)
In Figures 6a/b, 1-out-of-8 bursts for every TPM sensor during 10 trains were decoded and ordered: the resulting bitstream are the 70 bits info that each wheel sends during about the firts ten minutes from start. In normal use, tx are every 60 seconds bat can be more frequent if  some parameter is not right or vary, eg at the start of car motion as in this case; more over, the car can ask for tx using LF (RFID).
There are some bitfields with exhibit regular repetitions of patterns (at every 4 bursts), static patterns and variable ones. Particularly, note that the second and third field reach almost constant values after 3-4 minutes: these are the temperature and pressure values (the capture begins when the car is stationary).

Fig. 6a - 70 bits info that each wheel sends in ~10 minutes
Fig. 6b - 1-0 view
Most likely, the structure is: 8-bit sync, 8-bit temperature, 8-bit pressure, 32-bit sensor ID, 5-bit flags (sensor status), 8-bit CRC, and 1-bit EOM. Perhaps  some bits are used as field sync, but there are no info about that. In this case, using the bit sequence "10" as field separator, we get: 6-bit sync, 6-bit temperature, 6-bit pressure, 32-bit sensor ID, 3-bit sensor status, 8-bit CRC, and 1 bit EOM (Figs. 7a/b).

Fig. 7a
Fig. 7-b

At least this protocol, and most likely all the others, does not use encryption or a form of authentication, and the car implementation does not perform basic input validation. Moreover, TPMS messages can be correctly received up to 10m from the car with a cheap antenna and up to 40m with a basic low noise amplifier, so the cited shortcomings  allow for remote spoofing of TPM sensor messages and may cause security and privacy vulnerabilities. 
Could it be used as feasible way to track cars? Think that each TPM sensor sends its 32-bit static identifier in every message and the length of the identifier field could render the IDs sufficiently unique to track cars, in these case using the 4-upla: 
01101011101001000010011011101101
01101010100101111010111110111101
01101010100101111010001110111101
01101010101001010000001100000101
On the other hand, just the choice of the "open-protocol" solution allows to use aftermarket products or multi-protocol sensors that come “pre-loaded” with many sensor protocols in a single sensor body; this way the TPM sensors are not so tightly linked to the car manufacturer and ultimately to the car. But, who knows how it will evolve?
 
At present we decided to not mention car and sensors manufacturers, anyway - for study purposes only - you could send your recordings along with the manufacturers of the "copied" TPM sensors so to build up a sort comparison table. Why not?

We know there are some pieces of software which are able to decode and identify TPMS such as:
https://github.com/jboone/tpm differents 
https://github.com/merbanan/rtl_433 
but what we'd like to do  is a bit more "radio" approach rather than a purely software approach. As suggested by ANgazu, there are many 433 files here:
github.merbanan/rtl_433_tests
Files are .dat but after some analysis, format for SA is 8U and sample rate is 250000. There are about 4 TPMS models that can be a good reference for us. We think that join these two approaches will offer two different views of the same signals!




20 August 2017

Rohde & Schwarz ALIS (RS-ARQ): pool size and frame length

Like in other ALE systems, during an ALIS call [1] the caller station transmits a defined number of "calling" frames so that the called station could have enough time to scan the frequencies of the current pool and, in case of late entry, could ever receive at least three frames for synchronization and data acquisition (Fig. 1).
Fig. 1 - ALIS late entry support to facilitate data acquisition
Thus, the number of the transmitted frames during an ALIS call is not fixed but depends on the size of the current pool of frequencies: roughly it is = (3 x number of pool frequencies) + 1. Don't know what is the maximum of frequencies for each pool and the maximum of different pools which are allowed by the ALIS processor.
I had a look at some ALIS calls and surprisingly found different ACF results, eg (Fig. 2): 

~358.6 ms for a pool size = 6
~376.1 ms for a pool size = 8
~402.2 ms for a pool size = 9
~402.8 ms for a pool size = 10
~415.5 ms for a pool size = 11
(although there are some decoder indecisions about pool sizes 9 and 10).

Fig. 2 - pool sizes and ACFs
Since the system operates at constant speed (228.6 symbols/sec), the higher is ACF and the greater the number of symbols per frame and so also the length of the frames is not fixed but it depends on the the pool size.
This dependence is even more neat looking at the demodulated stream in Figure 3, in which you can highlight a fixed 61-bit data block, following a variable length block consisting of a single field (here termed as "FC").

Fig. 3 - pool sizes and frame lengths
82-bit period for a pool size = 6
86-bit period for a pool size = 8
95-bit period for a pool size = 11

It's easy to note that the extra-lenght (period length - 61) matches the number of the frames to be transmitted for each pool size, according to the relation:
number of frames ~ (3 x pool size) + 1

Figure 4 shows the "vertical" comparison of the 61-bit block for three different pool sizes (6,8,11) and a my rough reading of their bitfields structure; the decoder outputs in the right boxes help to identify values and differences.
It's easy to see that the first 15-bit field (0-14) is the address of the called station, while the 23-bit last field (38-60) is probably transmitted for sync/correlation since this field exhibits the same pattern in all the 3 frames; if so, the rightmost bit should be the first to be transmitted. The 23-bit middle field (15-38) is the "status" of the caller station (FSK, voice, data, ARQ, adaptive reaction, fixed operation on a single frequency, frequency hopping mode, message key for frequency hopping mode, ...).
It's worth noting that, despite other ALE waveforms, the caller address is never transmitted.
(Note that the 3 bitfields structure "15 + 23 + 23" is only a my reading, since, for example, it could also be described as "15 + 24 + 22" or using a different number of bitfields!) 

Fig. 4 - 61-bit block structure
As you see, no field contains informations for the pool size (the middle field can't store the pool size because the first two frames have diffrent pool sizes and same value for this field!).  

Given the above, the fact that the decoder prints out the size of the selected pool of frequencies (as in Fig. 1), means that this information is obtained from the "parsing" of the variable lenght block (FC block) of the frame. I just wrote "parsing" because in this block, rather than a numeric value, they adopted a "positional" rapresentation by using the lenght of the block and the position of the 1-value bit, which is right-shifted in each received frame (Fig. 5).

Fig. 5 - FC blocks
One could say that the FC block looks like a function table of a n-bit shift register, in which each received frame acts as a transition of the clock input. 
Besides enumerate and identifiy the received frames, and consequently the pool size, the implementation of the FC block could also be used as a timing logic for re-sync the receive modem. But that's just a my opinion.

Please note that I do not own professional analysis tool so the numbers could be a bit inaccurate or different, anyway I think the underlaying reasoning remains valid. Who knows? maybe someone from R&S will read and comment... 



[1] quoting Hoka Electronic: "Some people call RS-ARQ (Rohde & Schwarz simplex ARQ) as ALIS but strictly speaking, ALIS is only the automatic link processor and frequency management system. It is not responsible for generating the traffic. ALIS is therefore somewhat of a misnomer. The modems generating the traffic are the GM857 and GM2000. Our suggestion is to stick with RS-ARQ as the system name."

16 August 2017

unid 3-of-6 multitone system (tentative)


Recently I copied an interesting multitone signal on 14642.0 KHz and 16114.0 KHz on USB. The signal uses 6 tones, 400Hz spaced, starting from 650Hz, and it sounds just like a frog. Tranmissions do not have a preamble, last for a few minutes (the longer I heard last up to 16 minutes) and consists of 820ms blocks: 500ms data block followed by 320ms interval (Fig. 1)

Fig. 1
Transmissions end with the sending of the 6 carriers in a special sequence (Fig. 2)

Fig. 2
Three of the six tones are used to form the code symbols, ie they are sent simultaneously (Fig. 3): since given six tones there are twenty combinations of three that can be drawn without repetitions, this system use a 20 symbols alphabet set. It's important to note in Fig. 3 that each data block always consists of the ordered sequence of all the possible symbols (!) that makes a speed of 40 symbols/sec that is - in some way - coherent with the used shift (40Bd/400hz).

Fig. 3
123,124,125,126,134,135,136,145,146,156,
234,235,236,245,246,256,345,346,356,456

Many "exotic" coding could be derived from this set (as 123=A,124=B,... or 123=0,124=1,...) and a 6-bit representation is one of these: e.g. using the lower tone as the LSB we get the sequences:

000111 001011 010011 100011 001101 010101 100101 011001 101001 110001 
001110 010110 100110 011010 101010 110010 011100 101100 110100 111000

Fig. 4
or a per-line reading:

Fig. 5

(you may play around it inverting the order, changing polarity, differential decoding,...)

I don't know who they are and where the signals come from, anyway the fact of sending all the alphabet symbols leads to think that it could be a test of a new system, maybe aimed to Intel/Diplo services... but it's only a my supposition and - if that is the case - we should wait for further transmissions from the "production" frog-modem.







 

13 August 2017

BPOL R&S X.25 packet radio network on HF


Bundespolizei See (here simply termed "BPOL") is the maritime component of the Federal Police and is responsible for the border protection of the German state on the maritime border of the North Sea and Baltic Sea (Schengen external border). Since July 1994, BPOL has been part of the "Coast Guard", a coordinating organization of the executive forces of the Federation at sea, which includes customs, water and shipping administration and fishery protection. Since January 2007, BPOL is also represented as a security partner in the joint location center (GLZ-See) of the maritime safety center (MSZ) in Cuxhaven [1].
I consulted the UDXF logs (a collection of logs since year 2008) and for more than one week I watched one of their HF channels (8132.0 KHz/USB): with the exception of rare and sporadic transmissions between ships, all the traffic is structured in a star-shaped HF network in which the coastal HQ is the net control station (Fig. 1).


Fig. 1 - BPOL star-shaped network
ALE Address - name (HF node name)
BPLEZS, BPL -
BPLEZSEE Operations Center HQ Cuxhaven (BPOLBPLEZSEE_HF)
BP21 - patrol vessel "Bredstedt" (BPOLBP21_HF)
BP24 - patrol vessel "Bad Bramstedt" (BPOLBP24_HF)

BP25 - patrol vessel "Bayreuth" (BPOLBP25_HF)
BP26 - patrol vessel "Eschwege" (BPOLBP26_HF)


(*) patrol vessels BP22 "Neustrelitz" and BP23 "Bad Düben" are out of service since 28 June 2017 [2]. Just a curiosity: BP22 and BP23 are also known from the ZDF Television series "Küstenwache", where they were alternated under the name "Albatros II" [3] .

The way they operate these HF channels (8132, 5258, 4618, 3850,... KHz/USB)  is based on link establishment, using MIL 188-141A 2G-ALE, followed by data transfer, using a Rohde&Schwarz proprietary PSK-8 2400Bd waveform  and GM2100/GM2200 serial HF modem (Fig. 2a); anyway, the most large part of the heard transmissions consists of routine ALE scanning calls. 

Fig. 2a
The most interesting aspect is that data exchange is performed by means of RSX.25 ARQ protocol (Fig. 2b), a Rohde&Schwarz adaptation of the wired X.25 packet protocol to the HF radio channel. 
 
Fig. 2b

Quoting R&S papers: "The RSX.25 protocol is a modified AX.25 packet radio protocol. RSX.25 organizes the data to be transmitted in packets, which are successively transferred to the data modem. The packets contain a variable number  of  frames, the number perpacket depending on radio-link quality and being adapted at regular intervals.
The data transmitted in a packet are distributed among the frames. The length of the frame data is variable and also depends on radio-link quality: in channels of very good quality, a frame contains up to 250 data  bytes, in strongly disturbed channels 4 bytes. The HF Modem GM2100 is integrated in an optimized RSX.25 protocol that controls modulation and redundancy adaptation. With 8PSK the net data rate of the serial modem is 5400 bit/s. Errors are at first corrected by FEC, which reduces net data rate to 2700 bit/s. Errors escaping FEC are eliminated by the ARQ procedure of the RSX.25 protocol."
[4][5][6] 


Fig. 3 - RSX.25 data after GM2100 removal
Fig. 3b - the same data synched on 0x7E (01111110) flag (AX.25)

A second interesting point is that each 188-141A three-way handshake always includes the command User Unique Function (UUF) in the message section [7]:

[TO][BPLEZS][TIS][BP24]
[TO][BP24][TIS][BPLEZS]
[TO][BPLEZS][CMD USER UNIQUE WORD][TIS][BP24]

UUFs are for special uses, as coordinated with specific users or manufacturers, which use 188-141A in conjunction with non-ALE purposes. There are 16384 specific types of UUF codes available, as indicated by a 14-bit (or two-character) Unique Index (UI) which is always included in UUF when sent (Fig. 4); in this case they always use the index "00000000000111" and most likely it's closely related to the upper RSX.25 protocol:

(to)BPLEZS (cmd)|[nul][bel] (tis)BP24
1111100 00000000000111 

 
Fig. 4 - User unique functions structure

Unfortunately, linking handshakes & following RSX.25 exchanges are not as frequent as the great amount of scanning calls, indeed data exchanges are few and not all are carried by good signals: probably because of the varying propagation and the distances from my QTH, or maybe because links are performed in other channels and I do not own a scanner. 
Probably there is also another reason due to the use of HF only when a vessel exceeds the V/UHF range of coastal HQ, or exceeds the area covered by their TETRA "BOSNet" network infrastructure (the German nationwide TETRA radio system), assuming that these vessels already have this technology.  

Given the above, what is the nature of the RSX.25 exchanged data? Here is where things get a bit difficult.
As said, RSX.25 is a packet radio protocol and is meant to share tactical information and short messages. It has a typical period of 8 bits and may convey BZIP compressed files (eml, txt and others...) as well as IP frames.

Fig. 5
Email files (.eml BZIP compressed) are just simple messages and consist of "position reports", as the transmission logged on August 10 at 0806 in which vessel Bayreuth (PB25), comunicates its coordinates at 0737 and 0757 (all times in CEST). Emails are probably managed by R&S Postman software running at upper layer.

2017-08-10 07:37:48 +02, BPOLBP25, 54.023927, 10.800935
2017-08-10 07:57:47 +02, BPOLBP25, 54.023125, 10.800987



The transmitted coordinates can be easily imported into Google Earth using klm files (Fig. 6a).

Fig. 6a
Moreover, using web sites such as: vesselfinder or marinetraffic you could verify a received position report or just "track" the calls as in Fig. 6b.


Fig. 6b - tracking ALE calls

Back to captures, looking at txt files (Fig. 7) there are some interesting sequences that are easily recognizable (maybe related to a protocol built on top of packets?) as well as messages like "login, connected, closed" which are exchanged between the nodes. Also note that sometimes 188-141A links are terminated by the called station rather than the caller. 
What is even more interesting is the sending of one or more text strings in the format:

[yyyy-mm-dd] [hh:mm:ss UTC-offset], [vessel name]


where vessel name usually is not the one which sends the message (except when an email is also sent) and date-time is always before the transmission time. These kind of "announcing lists" are separated by semicolons and seem enclosed in <MPL></MPL> tags when sent by a vessel, and in <SPL></SPL> tags when sent by BPLEZSEE. It may also happen that these lists are empty, in this case only the tags are transmitted e.g. <MPL></MPL>.

Fig. 7
One could say that, in some way, these strings resemble the DX-Cluster spots, while the vessel positions reported in emails resemble APRS (Automatic Packet Reporting System); anyway, such messages seem related to situational awareness purposes. 

Probably this is one of the few existing packet-radio networks in HF and, the way things are these days, will be soon replaced by TETRA/SatCom systems.

update
Below an interesting example recordered on 26 August: the sent email reports BPOL21 positions every 10 mintues:

2017-08-26 09:02:08 +02, BPOLBP21, 54.4225, 12.271833
2017-08-26 09:12:09 +02, BPOLBP21, 54.414833, 12.252
2017-08-26 09:22:09 +02, BPOLBP21, 54.4075, 12.2325
2017-08-26 09:32:09 +02, BPOLBP21, 54.4, 12.212833
2017-08-26 09:42:09 +02, BPOLBP21, 54.3925, 12.193167
2017-08-26 09:52:09 +02, BPOLBP21, 54.385, 12.173

9 August 2017

crowd funded experiment for HAARP



This is an amateur's approach to a science experiment. It may not be in a typical fashion one would see from a physics student or a scientist. Even if my experiment doesn't provide any insightful information, as happens quite often in real scientific experiments - it will be a great opportunity to test a hypothesis! I hope this will have a positive effect of inspiring and motivating others to pursue their interests in science!
You're help is greatly appreciated. I can't do it without you!

Jeff, KL4IU

3 August 2017

short bit-analysis of a STANAG-4538 LDLn transfer (BW3 bursts)


Each LDLn transfer consists of a TX Frame consisting of one data packet; A data packet is defined as a fixed-length sequence of n-byte data segment (n = 32,64,96,...,512) followed by a 17-bit Sequence Number plus an 8-bit Control Field (presently unused), both added by the LDL protocol. Each TX Frame is sent using burst waveform BW3.
During the construction of BW3, a 32-bit Cyclic Redundancy Check (CRC) value is computed across the  data bits of each data packet (8n+25 bits) and is then appended to the data packet. Then, 7 flush bits having the value 0 are appended to the data packet with CRC (8n+57 bits) to ensure that the encoder is in the all-zero state upon encoding the last flush bit. 
That said, we can go back to the original datagram by inspecting the last 64 bits (17-bit Sequence Number + 8-bit Control Field + 32-bit CRC + 7 flush bits) of the ten BW3 bursts  (Fig. 1):

Fig. 1
 Some aspects must be first considered:

a) the 8-bit reserved field is added after the CRC field and not after the Sequence Number, as specified in Annex C to STANAG-4538; I don't know if it's the modus operandi of the decoder;
b)  following the last bit of the Payload field-value, the bits of the Sequence Number field are transmitted starting with the least significant bit (bit 0) rather than the most significant bit (bit 16). Most likely it's the modus operandi of the decoder, as above;
c) as in the Sequence Number of HDL Tx frames (see the previous post), the bits 14-6 of the first packet in datagram contain the number of user bytes in packet -1 and this contrasts what specified in Table 7.1.4.1-2; it depends on the particular STANAG-4538 implementation?

In this sample the values of the Packet Number fields are: 0,0,1,1,2,2,3,3,4,4: maybe the destination station requested a retransmissions or, most likely, each TX Frame is sent twice so to improve the reliability of the transfer (also note the values of the CRC fields). Correspondly, the Packet Byte Count fileds are: 128,128,...,67,67, this means it's a LDL128 transfer.
Note that the bytes contained in the packet #4 is less than 128 bytes because it includes the last data byte of the original datagram (the remaining 128-67 bytes are filled with "0" value bytes). That said, the original datagram of this sample is composed of the single packet numbers 0,1,2,3,4 (ie BW3 #0, #2, #4, #6, #8) and its length is (128 x 4) + 67 = 579 bytes (Fig. 2); the receive station shall discard the duplicated packet numbers.

It's worth noting that in this sample there are no BW4 ACK bursts returned back: it could be an MDL (Multicast Data Link protocol) transmission or maybe I did not heard these bursts!

Fig. 2
Back to the whole bitstream, once structured in a 1088-bit period ((8 x 128) + 64), the original datagram can be extracted by isolating the firts 4 rows and removing the overhead bytes: the resulting is an HARRIS "Citadel" encrypted file (Fig. 3).
 
Fig. 3
The ten LDL128 bursts, the retransmitted packets, and the "0" value bytes fillers can be noted looking at the whole bitstream in Figure 4.

Fig. 4