a STANAG-5066 (off-line) dissector

 

S5066 dissector (free software licensed under the GNU General Public License - GPL) is a GNU Octave coded tool that accepts as input a filename.txt file containing a stream of ASCII 0's and 1's (no space between) and, accordingly the input arguments, prints out:
a. filename_out file containing the decoded headers of the STANAG-5066 stack (DTS, CAS, SIS)
b. filename_addr file containing the changes of the traffic flow direction  (change of the source and destination node address)
c. filename_<n> files containing the user-data in ASCII-bits or ASCII-chars format
The output of the decoded headers is also shown on the Octave Command Window (the Command Window anyway does not allow you to browse the whole output).
The STANAG-5066 stack is scanned bottom up (starting from DTS layer)  as if the bistream were being parsed by a receiving node; since the dissector goes back up to the user data, it also shows some informations about the User-to-User Protocol as well as the Client Application type (BFTP, TTHMS, FRAP,...) and the basic transport protocol (RCOP/UDOP).
The input ASCII file being analyzed may be produced by a modem or a decoder (such as sorcerer, k500,...) which have the task of removing the HF waveform overhead (110A, S-4285, S_4539, ...), therefore this dissector is an "off-line" tool: a real-time version needs much more work (and code) other than a pc with the synchronous interface (users' standard pc are equipped with async interfaces).
The dissector is primarily thinked to work on (decoded) on-air symbols, hence its goodness will depend either on the quality of the signal and the precision of the modem/decoder. This is a beta and anyway STANAG-5066 Edition 3 compliant version: bug-fix (and maybe Edition 4 compliant) releases will follow.

Requirements:
1) GNU Octave >= 6.1 (see this post for Octave installation)
2) the input file should contain only '0's and '1's, ie no spaces or some other separator char between the values; preferably without LF/CR: in that case the software will reshape the contents and warn the user with the message "reshaping file, wait..."

Usage:
S5066(fn,i,f,cout,t)
  fn = filename containing a stream of ASCII 0's and 1's
 i,f = range of frames to be processed (i=0 first, f=0 last)
       0,n [1 - n]
       n,0 [n - last]
       n,m [n - m]
       n,n [only n-th frame]
cout = 0 do not extract user data (do not reassembly C_PDUs)
     = 1 extracts the user data in ASCII-bits format (0's and 1's)
     = 2 extracts the user data in ASCII-char format
   t = 1 tracks the changes of the flow direction (0 = no action)

Usage examples (notice that at each run the previous output files are overwritten):
S5066 ("test.txt",0,0,0,0)
process all the frames of the file and prints out the file:
- test_out.txt

S5066 ("test.txt",0,0,2,1)
process all the frames of the file and prints out the files
-  test_out.txt
-  test_addr.txt
- test_<n>.txt files containing the user data (as many files as the reassembled C_PDUs); since the parameter cout has the value 2, the user data files are in ASCII-char format (Extended ASCII code is used, a proper editor is recommended) 

A short report is printed at the end of the headers file along with the "elapsed time"; by the way, the time taken depends on several elements:
- the need to reshape the input file
- if user data extraction is required and its format (bit/char)
- the number of frames to be processed (length of the input file)
- type of data transfer
and - obviously - on the performances of your pc. Below an example of two reports the same input file (s23.txt, 1Mb length) with and w/out reshaping:

Installation
Download S-5066.ZIP and expand it in your Octave directory, usually c/users/<your_name>/octave. Will be created the S-5066 directory containing the files "README.txt" and "test.txt" along with the subdirectory /m which contains the Octave scripts.

Change the working directory to .../octave/S-5066 and run the command addpath ("./m") so that Octave will know where to look for .m files: as usual, the /m subdirectory 

then you can run and try S5066 using the input arguments that you prefer. The test.txt file contains a STANAG-5066 bitstream relating to a real on-air transmission: ie it does not have  a "perfect" protocol layout as if it were captured at the output of a STANAG-5066 server. I also want to remember that S5066 is a passive dissector only and does not simulate a receive node (it does not implement timings, receive windows, and other stuff).
Below some commented examples of output files (headers files): their study may offer some useful insigths to understand how STANAG-5066 works. 

Figure 1 is related to the simple ARQ service (type 0 D_PDU), the frames from 141 to 152 allow to follow the transfer of a segmented C_PDU.

 

Figure 1

A) The C_PDU START flag of the frame #142 is set to indicate the start of a newly segmented C_PDU; the C_PDU segment contained within this D_PDU is the first segment of the C_PDU; the C_PDU END flag is clear. In frame #152 the C_PDU START is clear and the C_PDU END flag is set to indicate the end of a segmented C_PDU.

 

B) The first segment is conveyed by the D_PDU with sequence number #22, the last segment by the D_PDU with sequence number #32, ie eleven D_PDUs. As expected from the encapsulation (each sublayer adds its header), only the D_PDU with the initial C_PDU segment (sequence number #22) is followed by the other sublayer headers (CAS, SIS, and user protocol) while the following D_PDUs contain only a C_PDU segment.

C) The EOT (End Of Transmission) field provides an approximation of the time remaining in the current transmission interval from the beginning of the current D_PDU. More precisely, the number in this field is a binary number expressing the number of half (1/2) second intervals, thus the flow controll allows a maximum transmission interval of about 2 minutes.

 

D) As you can see in the size of segmented C_PDU field, each segment has a size of 200 bytes, except the last segment which is 26 bytes length. The whole C_PDU is then composed of (200x10)+46 = 2046 bytes; adding the headers of the (11) D_PDUS needed to convey the segments we get a total of 2246 Bytes. Since that the needed transmission time is about 15 seconds (difference of the EOT fields), the transfer speed is 1200 bps.

If all D_PDUs between and including the C_PDU START and C_PDU END (frames from 142 to 152) are received completely error free the link layer will assemble the C_PDU segments and deliver the result to the higher sublayers.

 

C_PDU Re-assembly for ARQ Delivery Services

 

Figure 2 is related to the NON-ARQ service (type 7 D_PDU), the frames 1-6 allow to follow the transfer of a segmented C_PDU.

 

Figure 2

 

A) Instead of the start/end flags mechanism seen in ARQ service, the NON-ARQ service signals the start and the end of a segmented C_PDU by means of the C_PDU segment offset field and the (unsegmented) C_PDU size field; the D_PDU with the C_PDU segment offset = 0 indicates the first segment (ie the the start of a newly segmented C_PDU). The end of a segmented C_PDU is reached when the sum of the received segments sizes is equal to the C_PDU size field (ie 1078 in this example). Notice also that all D_PDUs containing segments from the same C_PDU have the same C_PDU ID number (in this case 2570).

B) The EOT field has obviously the same meaning seen in the ARQ service example (time remaining in the current transmission interval).

Each segment has a length of 200 bytes, except the last which is 78 bytes length. The whole C_PDU consists of 1078 bytes; adding the headers of the (6) D_PDUS needed to convey the segments we get a total of 1222 Bytes. Since that the needed transmission time is about 6 seconds (difference of the EOT fields), the transfer speed is 1600 bps.
The re-assembly process for Non-ARQ C_PDUs uses the C_PDU ID Number, Segment-Offset field, C_PDU-Segment-Size field, and C_PDU-Size field to determine when all segments of a C_PDU have been received.The segments that are reassembled are expected to have passed the CRC error-check and have no detectable errors.

 

C_PDU Re-assembly for NON-ARQ Delivery Services

Figure 3 is related to the tracking of the traffic flow direction, still in experimental version. That feature coud be useful in case of a recording of a ARQ-type session which comprises both data and ACKs sendings. At present, it simply records the changes of the SENDER/DESTINATION address along with the D_PDU type and frame number. 

 

Figure 3

Although the dissector does not care the user data, it also provides a raw(!) extraction and reassembly of the C_PDU segments.

 

 

Some features as the tracking of the traffic flow direction, controls/checks of inconsistencies and some other ones as the CRC check and C_PDUS segments reassembly, will be implemented in next releases.

Comments, suggestions and bugs reports are welcome!