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

No comments:

Post a Comment