use of the radio address format "RSPeer" for direct delivering of messages (R&S PostMan II)

This post can be considered as a continuation of the previous one in which the use of Rohde & Schwarz PostMan was shown: in that post, rsmail sending "classic" email over HF, was analyzed. In order to find other interesting RSX.25 sessions I started to look for my files and old recordings and finally I recovered an interesting transmission of the Italian Coast Guard (Guardia Costiera, say It-GC) on 12270.5 KHz/usb dated January 2016 consisting of the combined RSX.25 and GM-2X00 HF waveform.

 

Fig. 1

I probably went late on that transmission and so I probably lost the initial RSX.25 exchanges but after the demodulation of the signal - although weak - an interesting session came up that uses the Rohde & Schwarz address format "RSPeer" to send a file between two radios. The received signal does not have a good SNR but its interpretation is nevertheless possible, below the file I got after the removal of the GM2X00 HF waveform and RSX.25 demodulation:

...
c„%Ì, TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp v˜ xŸ>"©  ' E €  1 1
CP940 RSPEER:CP940,Administrator   N €  à  1 O   € !  +*V    ,ØCµá ªG )@§Ñd€
+ ¤¾£ n Ý T  ROMA RSPEER ROMA,ROMA   0  'ROMA'  0  0   *)  ì  #  &)

...

file being sent (most likely, see below)
TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp

RSPeer address format addresses
CP940, Administrator = patrol vassel "DATTILO" CP-940, callsign IGUB [1]
ROMA, ROMA = Guardia Costiera HQ Roma, callsign ICI [2]

Quoting the paper ADP010679 [3] "The R&S address format RSPeer ensures the direct delivery of the message to the computer of the addressee, i.e. the message is physically available on the hard disk of the recipient, the usual detour to the SMTP server being avoided. This delivery procedure excludes any misuse of and unauthorized access to the mail traffic of a network and ensures that one's own information is secure. This type of addressing also minimizes the data exchange on the frequencies available and so eases the traffic load of the radio network."

Further and more interesting details emerge if the HDLC protocol decoding is used at data-link layer, i.e. just before the RSX.25 demodulation(!): in particular, the strings related to MicroSoft Exchange  are highlighted

(OHDLC-layer.bin)
...
940a7d1.tmp v˜   xŸ>"©      •þÿÿÿþÿû(F°€œøÞÿÿÿ6(F°àš›Þÿÿÿ
ÿ(F¿ 2   Ì, TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp v˜  
xŸ>"©    tÑ(F°   ä    è € IPM.Microsoft Mail.Note 1 € €    
PIM 291000A GEN 16 ô €    à 6 (F± ' E €  1 1 CP940 RSPEER:CP940,Administrator
O € ! h›(F² 74F1198C47C6E511AB22000C2940A7D1 ý  þ    ÿ Z µ;ÂÀ,w ¡¼ 
 Úµ(F³ +*V    ,ØCµá ªG )@§Ñd€  Ñd€ + ¤¾£ n%Ý T ROMA RSPEER:ROMA,ROMA 'ROMA'
...

I believe the CP940 user is sending an outlook message in rich text format (RTF) encapsulated into Microsoft "Transport Neutral Encapsulation Format"(TNEF) [4] instead of sending an SMTP (HTML or Plain Text mode) email. The original filename is probably 940a7d1.tmp while the filename TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp and the 32-char lenghth string 74F1198C47C6E511AB22000C2940A7D1 are something related to MS-Exchange TNEF encapsulation (I believe the TNF converted file and the key/identifier of the message).
For what concerns PIM 291000A GEN 16, it is probably the time when the message was prepared, expressed in the format: DayHourMinuteAnte(Post)Meridiem Month Year (something like PIM = Product Information Management ???), i.e. 29 January 2016 10.00 AM; indeed it matches the time I recorded the transmission, i.e. 29 Jan 2016 at 10.25 or sent 25 mins after its preparation (Fig. 2).

Fig. 2

That said, PostMan performs an "address gateway" to email networks (SMTP, X.400, MS-Mail) with different address formats (Fig. 3).

Fig.3

So far, I never heard 188-141 ALE messages form It-GC ships and ashore stations but I have a guess about it. Several times I copied on 12270.5 and 8196.5 KHz (frequencies operated by It-GC) R&S-ARQ 228.6Bd/170 "ALIS" selcalls such as:

Called address: 40
Pool size: 8
ALIS 2000: No
Ack: true
Followon type: External modem
ECC: PRP
Spectral diversity: Adaptive
Data rate: Fast
Data encryption: No (clear)
Rephase: false
Sending counter: 1

Assuming that 40 is the ALIS address of CP940, it could be that they use the ALIS selcall instead of the 188-141 mode, but it is only a speculation of mine without any confirmation.


https://yadi.sk/d/Zbdfvc_punPUWw
https://yadi.sk/d/liJWgfG8jZGqXQ (OHDLC-layer.bin)

[1]  http://www.guardiacostiera.gov.it/.../scheda-dati-nave-dattilo-cp-940
[2]  http://www.mediasuk.org/archive/ici.html
[3]  http://www.dtic.mil/dtic/tr/fulltext/u2/p010679.pdf
[4]  http://www.fiction.net/blong/programs/tnef2txt/apptnef.txt 

Ital-HDLC/QUEDRE (High Level Data Link Control)

Looking at the Data Link layer, the many and seemingly boring STANAG-4285 transmissions start to get interesting: the following is an example about the pair S-4285 and HDLC.
The HDLC (High Level Data Link Control) is a group of protocols for transmitting synchronous data packets between Point-to-Point nodes and operates at the data link layer of the OSI reference model. The protocol uses the services of a physical layer (for example STANAG-4285 or MS188-110 waveforms) , and provides either a best effort or reliable communications between the transmitter and receiver (i.e. with acknowledged data transfer as ARQ). The type of service provided depends upon the HDLC mode which is used.

Each piece of data is encapsulated in an HDLC frame (pic. 1) by adding a trailer and a header. The header contains an HDLC address and an HDLC control field. The trailer is found at the end of the frame, and contains a Cyclic Redundancy Check (CRC) which detects any errors which may occur during transmission. The frames are separated by HDLC flag sequences which are transmitted between each frame and whenever there is no data to be transmitted (idle phase).
There is much documentation about it in the web, some links are given at the bottom.

pic. 1 - HDLC Frame Structure showing flags, header 
(address and control), data and trailer (CRC-16)

Sample HDLC data signal follows, when not sending data, a hardware generated idle pattern is present on the data signal:

[... idle pattern ...][Flag][...Data...][CRC][Flag][... idle pattern...]

As said, HDLC can be met in STANAG-4285 and MS188-110 as "secondary" (transported) protocol: the following is an example of its detection just in a STANAG-4285 transmission (pic. 2).

pic. 2 - a common STANAG-4285 transmission as seen by SA

Since I'm investigating the Data Link, I need a bitstream after having de-interleaved and removed the overhead bits added by the underlaying waveform; in other words, I need a STANAG-4285 decoded output. After identifying the correct settings for data-rate and interleaver, 1200bps/short in this case, I ran a k500 session and got the bitstream coming from the upper layer (pic. 3) which I then saved in a ASCII-bits file.

pic. 3 - bistream of that same transmisssion after stanag-4285 removal

The HDLC flags are easily identified looking for the "01111110" sequences (pic. 4) and the "presence" of this protocol has been confirmed (pic.5):

pic. 4

pic. 5

Things work in the same "logical" way TCP/IP stack does: as the data bits (the payload) flows down along a layer (transmitting-phase), they are encapsulated by (one of) the protocol running at that layer and this packet, data and protocol overhead, just forms the payload for the protocol that works at the next  layer. In this sample it's something like:

In the receiving-phase the packets go up the stack and are progressively de-encapsulated in order to return the starting payload, ie.e the original user-data.
That said, after removing Stanag-4285 and then the HDLC stuff, I got the sent messages (pic. 6).

pic. 6 - HDLC messages

Frames are recognized as idle sequences (idle lin) and are characterized by the repetitions of the string "QUEDRE" closed by "XT". Other than the frame type, the bitstream analyzer correctly detects the HDLC blocks, sizes and computes CRC (pic. 7).

pic. 7

The word "QUEDRE" does not belong to the embedded commands of HDLC, rather it seems a sort of an agreed string used for the idle sequences (at least here). That string is anyway one of the distinctive signs, since some bit analyzers tools use indifferently both the terms Ital-QUEDRE and Ital-HDLC just to indicate this feature in respect of the standard HDLC protocol. Difficult to say what QUEDRE means, perhaps a sort of acronym or most likely an agreed term, as said above, but in lack of a safe source these are only speculations. Since there are no (encrypted) messages in the HDCL data fields, these are almost surely some test transmissions.

It is worth noting that the QUEDRE string is clearly visible also in the output of any STANAG-4285 decoders by enabling the synchronous mode with 8N1 framing: probably the decoder will be Data Link aware so you will just see those repetitions and some other garbage due to the HDLC headers, addresses and CRC (pic. 8). Although the output text be consistent, this way is slightly misleading because you lose the knowledge of the Data Link.

pic. 8

http://www.interfacebus.com/HDLC_Protocol_Description.html 
http://www.synclink.com/html/hdlcmode.htm 
http://www.erg.abdn.ac.uk/users/gorry/eg3567/dl-pages/hdlc-framing.html