NILE/Link-22 168-bit packets (STANAG-4539 TDMA WF2 waveform)

(updated)

For background it might be helpful to read the posts:
TDMA waveforms, Annex D to STANAG4539 
NILE/Link-22 traffic waveform #2 

In the sample being analyzed, the 270 symbols of the Media Code Frames are transmitted at the modulation rate of 2400 baud and follow the QPSK waveform #2 structure that consists of 8 sections with 18 symbols DATA blocks and 15/16 symbols Mini Probes (MP). 

Fig. 1

Table 1 - Modulation Type and Contents for WF2 (Annex D to STANAG-4539 Edition 1)

The number of Media Code Frames to be transmitted per TDMA slot (i.e. a burst) is specified to the modem by the Link-22 System Network Controller (SNC) based on the Data Link Processor (DLP) supplied parameters and hence the size of the number of network packets that shall be used to accomodate the incoming messages.
In this sample each slot is composed of 9 frames each consisting of 168 bits, as specified in Annex D to S4539 (WF2, RS(36,21) in Table 2) and in a Link-22 publication [1] about the minimun size of a network packet (Table 3). Both the Tables refer to HF Fixed Frequency operations (HF FF).

Table 2 - Waveform Summary (Annex D to STANAG-4539 Edition 1)

Table 3 - Link-22 transmission media types (Understanding voice and data link networking [1])

My friend YING coded a sofware to demodulate and decode Link-22 WF2 samples, he kindly sent me a decoded bitstream and gave me some interesting insights: "I also found that (1) most of waveforms meet the RS(36,21), and seems only a little meets the RS(36,30). (2) all the RS decode bits have the byte 0x0B, which is strange" YING says. Indeed, the bitstream has a very interesting pattern (Fig. 2):

Fig. 2- Link-22 decoded stream (168 bits window)

Even more interesting is the hex representation of a single TDMA slot (9 frames) which exhibits features that are not immediately visible at glance in the bitwise representation:

-  48-bit fields A and A' has the same contents
-  4-bit fields marked with "*" differ by 0x8
-  4-bit fields B and B' has the same contents
-  4-bit fields C and C' has the same contents
- fixed position of the byte 0x0B (as noted by YING)

         A          B             C          A'         B'   C'
 ----------------- *-             -  ----------------- *-    -
 29 FB 1F A9 44 20 A9 C4 9F 96 C4 1F 29 FB 1F A9 44 20 29 0B 1E
 5F CA E1 95 32 11 57 F8 E9 A7 3A 23 5F CA E1 95 32 11 D7 0B 22
 DB A6 9E 99 B6 7D 28 F4 6D CB 45 2F DB A6 9E 99 B6 7D A8 0B 2E
 8C F5 65 E3 E1 2E D3 8E 3A 98 BE 55 8C F5 65 E3 E1 2E 53 0B 54
 22 D4 3F A6 4F 0F 89 CB 94 B9 E4 10 22 D4 3F A6 4F 0F 09 0B 10
 3E CB AC CD 53 10 1A A0 88 A6 77 7B 3E CB AC CD 53 10 9A 0B 7A
 7A A0 B0 DD 17 7B 06 B0 CC CD 6B 6B 7A A0 B0 DD 17 7B 86 0B 6A
 FE F5 04 CE 93 2E B2 A3 48 98 DF 78 FE F5 04 CE 93 2E 32 0B 78
 3C B6 D0 A7 51 6D 66 CA 8A DB 0B 11 3C B6 D0 A7 51 6D E6 0B 10

(each 168-bit row is a 112.5ms Media Code Frame)

Quoting STANAG-5522 TACTICAL MESSAGE CONSTRUCTION: "Link-22 tactical messages are functionally oriented, variable length strings of an integer number of up to eight 72-bit words (Tactical Message Words).  These 72 bits words are formatted into network packets by the System Network Controller.  Parity bits for Forward Error Correction are applied at the Network Packet level". This means that what we see are network packets and not solely Link-22 messages.
If it's easy to verify that the number of Media Code Frames carried by a burst is 9, it is however difficult to establish the number of 72-bit words and hence the possible format of the message (from 72 up to 576 bits long). Help in this direction comes from the hex stream. Link-22 traffic is usually encrypted by KIV-21/LLC, a stand-alone in-line network crypto device: the stream, however, does not seem encrypted. Looking at the Link-22 Functional Diagram in Fig. 3, the NETSEC FUNCTION block provides akso an unencrypted interface for the transfer of control and status information (C&S):

Fig. 3 - Link-22 Functional Diagram (STANAG-5522 Edition 1)

Thus, an easy conclusion could be that each 112.5ms frame transports two unencrypted Link-22 words (144 bits) plus 24 bits low-level overhead (Error Detection And Correction (EDAC) bits, flags, spare, etc.?). Table 4 confirms my guess:

Table 4 - Waveforms, RS code rate, and Link-22 words
("Technical handbook for radio monitoring HF", Roland Proesch)

Table 5 is the result of a my comparison between Tables 2 and 4: it turns out that a fixed length of 24 bits is always appended. Curiously, this length is 1/3 (24 bits) of the length of a Link-22 word (unfortunately Table 5 is limited to the waveforms WF1-3 since the new annexes to STANAG-4539 are not at my disposal).

TABLE 5

Just as a test I tried a quite raw suddivision in which the fields that have the same values occupy the same positions within two Link-22 words:

 71                      00           71                       00
 --------------------------            --------------------------   
 29 FB 1F A9 44 20 A9 C4 9F  96 C4 1F  29 FB 1F A9 44 20 29 0B 1E
 5F CA E1 95 32 11 57 F8 E9  A7 3A 23  5F CA E1 95 32 11 D7 0B 22
 DB A6 9E 99 B6 7D 28 F4 6D  CB 45 2F  DB A6 9E 99 B6 7D A8 0B 2E
 8C F5 65 E3 E1 2E D3 8E 3A  98 BE 55  8C F5 65 E3 E1 2E 53 0B 54
 22 D4 3F A6 4F 0F 89 CB 94  B9 E4 10  22 D4 3F A6 4F 0F 09 0B 10
 3E CB AC CD 53 10 1A A0 88  A6 77 7B  3E CB AC CD 53 10 9A 0B 7A
 7A A0 B0 DD 17 7B 06 B0 CC  CD 6B 6B  7A A0 B0 DD 17 7B 86 0B 6A
 FE F5 04 CE 93 2E B2 A3 48  98 DF 78  FE F5 04 CE 93 2E 32 0B 78
 3C B6 D0 A7 51 6D 66 CA 8A  DB 0B 11  3C B6 D0 A7 51 6D E6 0B 10

However, the byte-oriented view is misleading and actually makes a poor sense since the words and overheads are structured in bits rather than in bytes. (1)
Moreover, it should be noted that we do not have to deal with clean and reassembled packets but just with decoded on-air symbols. I mean that Link-22 network packets may undergo a fragmentation and probably that is what we are facing: indeed, the autocorrelation of the bitstream exhibits a strong value of 96 bits i.e. just one 72-bit word plus 24-bit overhead (Fig. 4). 

Fig. 4 - TDMA slot autocorrelation

Summary
Based on the above, we think that the analyzed sample consists of unencrypted Link-22 F-series C&S messages, although it could also be 70-bit Link-16 messages which are encapsulated in Link-22 structure. At least for waveforms WF1-3, the network controller always adds 24 bits overheads to the incoming Link-22 messages: we need more time to study this block and find the CRC sequence (if any).

24-bit overheads update (October, 4)
The packets after WF2 RS(36,21) decoding consist of 144 bits which are needed to convey two words, plus 24 bits of overhead. Referring to Figure 3, these packets are somewhere inside the Signal Processing Controller block which performs modulation and demodulation, as well as error detection and correction (EDAC). Well, I think the 24 bits overhead partly consist of CRC bits (I do not think a CRC-24 is used).
As STANAG-5522 seems to suggest, Link-22 applies the CRC to the whole of words of each packet (i.e. not to each word). Although actually I do not know neither the length of the CRC neither its positioning inside a packet, most likely Link-22 uses a CRC-16 parity check. The remaining 8 bits could be used to accomodate the needed bits for the packet header and maybe one or more additional spare bits so to match the numbers of the k-bytes used for Reed Solomon encodings.
Indeed, as you can see in table 5, the value of k in RS(n,k) codings is 3 bytes longer than the room needed to convey the words. According to the waveform being used, SPC will package words, header, and CRC bits into a packet of the appropriate number of bits for modulation and transmission. 

(to be continued)

(1)
The data fields used are of 3 types: binary, logical, and numeric. Binary data fields are one bit fields containing a 0 or 1. The meaning of the value of each field is described in the applicable message definition. Logical data fields are multibit fields whose bit configurations represent logical values as described in the applicable message definition. Numeric data fields are multibit fields whose bit configurations represent actual numeric values. Spare fields are included in some messages. When transmitted, these spare fields will be encoded as zero and shall not be processed upon receipt. 

[1] https://www.northropgrumman.com/.../UVD.pdf

2018-10-09T09_44_33Z_7606.00_usb.wav 
2018-10-09T09_44_33Z_7606.00_usb_168bits_2_slots.bin