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 transmitted symbols; this means that also the length of the frames is not fixed but it depends on the number of the frames to be transmitted, and ultimately on 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 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.

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

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

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


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.

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; 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