13378.0 KHz/USB, 0848z: S5066 data transfer using HF waveforms 110A & S4539 which scale from 3200bps (QPSK/PSK-8 on air) up to 9600bps (QAM-64); unid user/location. Notice in Figure 1 that QAM-32 constellation use multiple PSK rings to maintain good peak-to-average ratios, and the QAM-64 constellation is a variation of the standard square QAM constellation, which has been modified to improve the peak-to-average ratio.
 |
| Fig. 1 . HF waveforms constellations |
The typical 1776 bits structure of S5066 is obtained after the removal of the HF waveforms overhead, in Figure 2 the bitstream is synchronized on the sync sequence 0x90EB.
 |
| Fig. 2 - STANAG-5066 bitstream synched on 0X90EB |
Looking at the 16-byte headers of the Data Transfer Protocol Data Units (D_PDU), we see that #0 (Data only) is the used D_PDU type: this type is used for simplex data transfer of segmented C_PDUs with a Selective Repeat-Request (SRQ) service protocol. The peers in the link have the S5066 addresses: 001.005.005.105 and 001.001.001.101.
0x90EB D_PDU sync sequence
04 D_PDU type
10 50 56 91 01 01 65source & destination address
0x90EB D_PDU sync sequence
04 D_PDU type
10 50 56 91 01 01 65source & destination address
90 EB04 F6 3C E9 10 50 56 91 01 01 65 48 BA 85 ...
90 EB04 F6 3B E9 10 50 56 91 01 01 65 08 C8 87 ...
90 EB04 F6 3A E9 10 50 56 91 01 01 65 08 C8 88 ...
90 EB04 F6 39 E9 10 50 56 91 01 01 65 08 C8 89 ...
90 EB04 F6 39 E9 10 50 56 91 01 01 65 08 C8 8A ...
90 EB04 F6 38 E9 10 50 56 91 01 01 65 08 C8 8B ...
90 EB04 F6 37 E9 10 50 56 91 01 01 65 48 BA 8C ...
90 EB04F6 36 E9 10 50 56 91 01 01 65 08 C8 8E ...
90 EB04F6 35 E9 10 50 56 91 01 01 65 08 C8 8F ...
90 EB04 F6 34 E9 10 50 56 91 01 01 65 08 C8 90 ...
90 EB04 F6 3B E9 10 50 56 91 01 01 65 08 C8 87 ...
90 EB04 F6 3A E9 10 50 56 91 01 01 65 08 C8 88 ...
90 EB04 F6 39 E9 10 50 56 91 01 01 65 08 C8 89 ...
90 EB04 F6 39 E9 10 50 56 91 01 01 65 08 C8 8A ...
90 EB04 F6 38 E9 10 50 56 91 01 01 65 08 C8 8B ...
90 EB04 F6 37 E9 10 50 56 91 01 01 65 48 BA 8C ...
90 EB04F6 36 E9 10 50 56 91 01 01 65 08 C8 8E ...
90 EB04F6 35 E9 10 50 56 91 01 01 65 08 C8 8F ...
90 EB04 F6 34 E9 10 50 56 91 01 01 65 08 C8 90 ...
The D_PDUs payloads originate a group of files which have the same 38 bytes length initial structure consisting of a 33-byte pattern followed by a progressive 0xnn number and four 0x00 bytes:
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 18 00 00 00 00 4F ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 19 00 00 00 00 5A ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 1A 00 00 00 00 CC ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 1B 00 00 00 00 53 ...
In my opinion the first six bytes are the headers of C (Channel Access Sublayer) and S (Subnetwork Interface Sublayer) Protocol Data Units:
00079942 EF 44
00 C_PDU type (0 = data)
07 S_PDU type (0 = data)
99 S_PDU source & destination SAP IDs (1001 & 1001)
42 EF 44 S_PDU control and TDD fields
and the remaining 32 bytes, from 0x45 to 0x4F, could be the headers of the User Protocol data Units (U_PDUs) incoming from the client/application upper layer (Figure 3). Since the presence of a progressive number (0x18, 0x19,0x1A,...) it could be that the client message has been segmented into smaller U_PDUs before the subnet interface, but it's only a my guess.
SAP_ID stands for Service Access Point Identifier, it's a number in the range 0-15 and is equivalent to the “port” of the TCP protocol. In this case - according to S5066, the used Service Access Point should be the IP port (1001).
https://yadi.sk/d/ZFTNRhiPkoT1HQ
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 18 00 00 00 00 4F ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 19 00 00 00 00 5A ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 1A 00 00 00 00 CC ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 1B 00 00 00 00 53 ...
In my opinion the first six bytes are the headers of C (Channel Access Sublayer) and S (Subnetwork Interface Sublayer) Protocol Data Units:
00079942 EF 44
00 C_PDU type (0 = data)
07 S_PDU type (0 = data)
99 S_PDU source & destination SAP IDs (1001 & 1001)
42 EF 44 S_PDU control and TDD fields
and the remaining 32 bytes, from 0x45 to 0x4F, could be the headers of the User Protocol data Units (U_PDUs) incoming from the client/application upper layer (Figure 3). Since the presence of a progressive number (0x18, 0x19,0x1A,...) it could be that the client message has been segmented into smaller U_PDUs before the subnet interface, but it's only a my guess.
 |
| Fig.3 - sublayers within STANAG-5066 |
SAP_ID stands for Service Access Point Identifier, it's a number in the range 0-15 and is equivalent to the “port” of the TCP protocol. In this case - according to S5066, the used Service Access Point should be the IP port (1001).
https://yadi.sk/d/ZFTNRhiPkoT1HQ