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 re
moved 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
No comments:
Post a Comment