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 

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!

https://yadi.sk/d/_ngTZE473MHZhs

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, thus the length of the frames is not fixed  and it can be presumed(!) that it depends on the the pool size.

This dependence is even more neat looking at the demodulated streams shown in Figure 3: you can notice a constant 61-bit pattern which follows a variable length field 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 computing  period length - 61, the result matches the number of the frames to be transmitted for each pool size according 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 the bitfields structure; the decoder outputs in the right boxes help to identify values and differences:

• the first 15-bit field (0-14) is the address of the called station;
• 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.

Fig. 4 - 61-bit block structure
(Note that the format "15 + 23 + 23" is only a my guess)

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 (Fig. 1), means that this information is obtained from the "parsing" of the variable lenght field 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."

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" .

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 GM2x00 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." [3]

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 [4]:

[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.  

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.

[1] https://www.bundespolizei.de/Web/DE/05Die-Bundespolizei/.../see_node.html

[2] http://www.presseportal.de/blaulicht/pm/70256/3671789

[3] https ://cdn.rohde-schwarz.com/pws/../n155_shortwave.pdf

[4] MIL-STD 188-141B Appendix A, A.5.6.9 User unique functions (UUFs)

crowd funded experiment for HAARP

https://www.indiegogo.com/projects/amateur-radio-science-experiment-at-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

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. Sumarizing, the on-air length of a LDLn burst is given by:

total on-air LDLn bits (n = 32,64,96,...,512) = 8n + 64

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

https://yadi.sk/d/P0BIYELb3Lg5ex