BPol vessels tracking using RSX.25 and GM2X00 waveforms (R&S PostMan II)

Quoting R&S PostMan II brochure "[...] another feature is the capability to track mobile stations by using the global positioning system (GPS). If a station is equipped with a GPS receiver, position data can be transmitted in addition to the actual data after analysis of the National Marine Electronics Association (NMEA) 0183 protocol [1]. The current position of and the route covered by each mobile station can thus be tracked from a command center".  The standard package includes an interface with scanned maps as below: in the left side a screenshot from PostMan and in the right side the correspondent map available from the web [2].

Fig. 1

After analyzing some recordings, I think this system is the one used by BPol (Bundespolizei See) for tracking their patrol vessels: positions are transmitted on HF to the ashore command center using RSX.25 protocol over GM-2X00 waveforms as discussed here.

After removing the GM-2X00 waveform and decoding the RSX.25 bitstream, it is possible to see the UUCP commands that are responsible for transferring a Bzipped file from BPOLBP23 (patrol vessel "Bad Düben", now out of service) to BPOLBPLEZSEE_HF (Operations Center HQ Cuxhaven).

Fig. 2 - RSX.25 bitstream

login: UBPOLBPLEZSEE_HF <MPL>2016-11-28 15:49:52+01,BPOLBP23;2016-11- BPOLBPLEZSEE_HF 15:49:52+01,BPOLBP23; 2016-11-28 15:47:45+01,BPOLBP26</MPL> Connected
Shere=BPOLBP23_HF SBPOLBPLEZSEE_HF -pz -vgrade=z -R -N07 ROKN07 Pyie
Uy  ¸ HN = #E D.05PK D.BPOLBP2C05PK uucp -C D.05PK 0666 "" 0x66 rsgpsadd
ƒ!Z)vL@¬“4m˜ßÐ{ f ã BZh91 ...

The UUCP session has been described in detail in this post, here it's more interesting to dwell on the piped commands uucp file | rsgpsadd: 

D.05PK D.BPOLBP2C05PK uucp -C D.05PK 0666 "" 0x66 
D.05PK = file to send
D.BPOLBP2C05PK = file name on slave (should be D.BPOLBP2505PK)
uucp = application requesting the file transfer
-C = file has been copied to the spool directory
0666 = mode of file on master for outgoing files
0x66 = 102 Bytes file size
 
rsgpsadd 
rsgpsadd = command to be executed after the transfer, most likely stands for "R&S GPS Add". This program  will process the sent file D.05PK, probably unpacking it and store the lines into a database for the further graphic elaboration (map display).

BZh9
here starts the D.05PK file which is sent in Bzip compressed way:
BZ = Signature (0x425A magic number)
h = Bzip2 (h is for Huffman coding)
9 =  increments of 100 kB block-size uncompressed

The compressed file, once unpacked, consists of two lines, each consisting of four values separated by commas "timestamp, vessel, latitude, longitude" as in the transmission heard on August 10 at 0806 in which the vessel Bayreuth (BPOLBP25), comunicates its position at times 0737 and 0757 (CEST):

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

Some comments about these files.
GPS Devices can create a file saving the route they are taken and these files are usually stored in a format called NMEA 0183. Now, as can be seen from the mentioned brochure ("... after analysis of the National Marine Electronics Association (NMEA) 0183 protocol") I believe the 0183 format files cannot be read directly by PostMan so they must be converted into a new file format. Well, the format of the files piped to rsgpsadd command looks like the Waypoint file format. In the waypoint format each line contains a triplet of values separated by commas, these values are a text string (optional), a latitude value and a longitude value.  In the rsgpsadd files it seems that each waypoint line, consisting of the triplet "vessel, latitude, longitude", is preceded by a timestamp string that could be a header value added during the 0183-waypoint conversion. By the way, notice that R&S already developed the "GPS Route Converter" program (NMEA 0183 to waypoint files) to be used by the R&S SMU200A Vector Signal Generator [3]: maybe parts and knowledges from that software is used/embedded in this PostMan application, who knows?

Fig. 3

I tried to use some rsgpsadd commands, recordered on 26 August (2017), to trace the patrol vessel BPOL21 by using a .kml file and google Earth application [4]: these rsgpsadd commands update the position with a resolution of 10 minutes

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

below the map I obtained, the vessel was moving from right to left

Fig.4

[1]  https://www.nmea.org/.../nmea_0183_v_410.asp 
[2]  http://fishing-app.gpsnauticalcharts.com
[3]  https://cdn.rohde-schwarz.com/...GPS_route_converter.pdf
[4]  http://www.gpsvisualizer.com/map_input?form=googleearth
 

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)