Looking at the Data Link layer, the many and seemingly boring STANAG-4285 transmissions start to get interesting: the followingis 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 linksare givenat 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 anexample of itsdetection 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 identifyingthe correctsettingsfordata-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 areeasilyidentified looking for the "01111110" sequences (pic. 4) and the "presence" of this protocol has been confirmed (pic.5):![]() |
| pic. 4 |
![]() |
| pic. 5 |
Thingswork 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 removingStanag-4285 and then theHDLC 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, sincesome 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 DataLinkaware so you will just see thoserepetitions and some other garbage due to the HDLC headers, addresses and CRC (pic. 8). Although the output text be consistent, this way isslightly misleadingbecauseyou lose the knowledge of theData 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 
