LINK-11 SLEW, Systematic CRC check matrix

In Link-11 SLEW the error detection encoding is applied to all 48-bit data words within each type of field with the exception of the EOM field. The encoding scheme uses Cyclic Redundancy Check (CRC) H(60,48) which is generated using a 12-bit Shift Register defined by the polynomial x¹² + x¹⁰ + x⁸ + x⁵ + x⁴ + x³ + 1, and producing the Link-11 SLEW 60-bit (48+12) encoded frames.

Quoting STANAG-5511 Annex-B §11.1.1.1 "The data is shifted serially into the Shift Register starting with the most significant bit (MSB) until the least significant bit (LSB) has been applied to the input stage of the Shift Register. This accomplishes a division of the data by the polynomial that defines the Shift Register. The remainder of the division is represented by the values in each stage of the Shift Register: these 12 values are appended to the data bits as parity, creating a systematic code".

Systematic codes have the advantage that the parity data can simply be appended to the source block, and receivers do not need to recover the original source data if received correctly since they are located in the leftmost bits of the received data (this explains because systematic code is also called “Separable”). The standard CRC encoder is different from the Systematic CRC encoder in the way the encoded word is calculated, therefore the data bits cannot be separated from encoded word before decoding takes place. 

In my opinion, actually STANAG-5511 seems to describe the "systematic CRC decoder" rather than the "systematic CRC encoder": indeed, the decoder just works by getting the input encoded word, which might contain errors, and dividing it by the generator polynomial to get the remainder (i.e. calculating E(x) mod G(x) and getting R(x)). If remainder of division is zero then the encoded word has no errors, otherwise error is detected with a non-zero remainder [1]. 

That said, the systematic generator matrix is obtained by selecting as rows the codewords associated with the 12-bit fields 100000000000, 010000000000, ..., and 000000000001. Well, my friend cryptomaster worked on the 4095-bit maximum-length sequence produced by the generator polynomial x¹² + x¹⁰ + x⁸ + x⁵ + x⁴ + x³ + 1 obtaining the 12-row 60-column parity-check matrix that is shown below

                                
111100110100011000110111111001001001110101100010 100000000000
011110011010001100011011111100100100111010110001 010000000000
110011111001011110111010000111011011101000111010 001000000000
111001111100101111011101000011101101110100011101 000100000000
100000001010001111011001011000111111001111101100 000010000000
110000000101000111101100101100011111100111110110 000001000000
011000000010100011110110010110001111110011111011 000000100000
010000110101001001001100110010001110001100011111 000000010000
110100101110111100010001100000001110110011101101 000000001000
100110100011000110111111001001001110101100010100 000000000100
110011010001100011011111100100100111010110001010 000000000010
111001101000110001101111110010010011101011000101 000000000001

If an error is detected with a non-zero remainder, the error can be corrected just using the check matrix. 
Code verification is carried out by comparing each line of encoded data in turn with all rows of the check sub-matrix: the vertical correspondences of the "ones" locations in the encode line and in the row #n of the check sub-matrix are counted. If the matches are even then the CRC bit #n will be "0", otherwhise (ie matches are a odd number) the CRC bit #n will be "1".

Let's try a verification for the first 48-bit data in Fig.1

Fig. 1

48-bit data                                                                    12-bit CRC
111011100101011011110011001001101010001000010100 011000011001
111100110100011000110111111001001001110101100010 check sub-matrix row #1
14 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
011110011010001100011011111100100100111010110001 row #2
11 matches (odd), CRC bit value:  1

111011100101011011110011001001101010001000010100 011000011001
110011111001011110111010000111011011101000111010 row #3
17 matches (odd), CRC bit value:  1

111011100101011011110011001001101010001000010100 011000011001
111001111100101111011101000011101101110100011101 row #4
16 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
111001111100101111011101000011101101110100011101 row #5
16 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
100000001010001111011001011000111111001111101100 row #6
12 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
011000000010100011110110010110001111110011111011 row #7
10 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
010000110101001001001100110010001110001100011111 row #8
11 matches (odd), CRC bit value:  1

111011100101011011110011001001101010001000010100 011000011001
110100101110111100010001100000001110110011101101 row #9
11 matches (odd), CRC bit value:  1

111011100101011011110011001001101010001000010100 011000011001
100110100011000110111111001001001110101100010100 row #10
16 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
110011010001100011011111100100100111010110001010 row #11
12 matches (even), CRC bit value: 0

111011100101011011110011001001101010001000010100 011000011001
111001101000110001101111110010010011101011000101 row #12
13 matches (odd), CRC bit value:  1

as expected, the 12-bit CRC added to the first 48-bit frame is: 011000011001.

If you want try by yourself, the last 60-bit sequence consisting of all "ones" could be a segment of the picket EOM and no error detection or correction bits are applied to this field! (Link-11 fileds will be treated in a next post).
Notice that Link-11 SLEW uses also 1/2 rate and 2/3 rate convolutional encoders to improve the reliability of the system, while CLEW does not use convolutional encoders and employs Hamming (30,24) encoding with the overall parity bit:
https://i56578-swl.blogspot.com/2018/08/link-11-clew-hamming-check-matrix.html 

That said, and if me and cryptomaster are right, STANAG-5511 is not so clear in the pages related to CRC Data Encoding.

⬇ https://yadi.sk/d/C-GO-nbl3aBYKr
⬇ https://yadi.sk/d/l_2IQJrP3aBYbV

[1] http://www.ecs.umass.edu/.../SystematicCRChelp.html

LINK-11 CLEW, doubts about the generator polynomial x^5+x+1

I have some doubts about the description at page 19 of MIL 188-203-1A (Tadil-A/Link-11) [1]: the document states that the Start Code and the Address Code frames " [...] are equivalent to 60-bit portions of the maximum-length shift register sequence with generator polynomial G(x) =  x⁵+x+1" ...but such a fifth grade polinomyal has a maximum length sequence (MLS) of 31 bits (2⁵-1). Indeed, I found the generator polymonial x⁶+x+1, whose MLS is 63, for both start and address frames:

 

111100101000110000100000111111
101100110111011010010011100010
100001000001111110101011001101
110100100111000101111001010001

Using a GNU Octave script [2] I also checked the three fundamental properties of LFSR maximum length sequences: Balance Property, Runlength Property, and Autocorrelation Property [3]: verification fails for x⁵+x+1

• The Code does NOT satisfy Balance Property: number of 1s and 0s are 17 14
• The code does NOT satisfy RUN LENGTH property: the run length is 10    2    1    1    2
• The Code does NOT satisfy the Autocorrelation Property

  while verification is ok for x⁶+x+1 

• The Code satisfies Balance Property: number of 1s and 0s are 32 31
• The code satisfies RUN LENGTH property: the run length is 16    8    4    2    1    1
• The Code satisfies the Autocorrelation Property

So I do not know if I'm wrong or if there's a typo in 188-203-1A, comments are welcome.

[1] https://www.sigidwiki.com/wiki/File:MIL-STD-188_203-1A.pdf

[2] https://github.com/Nikeshbajaj/Linear_Feedback_Shift_Register 

[3] https://en.wikipedia.org/wiki/Maximum_length_sequence 
 

interesting paper about IP Multicasting in HF Radio Networks

I recently found in the web the interesting paper titled IP Multicasting in HF Radio Networks (2008) that proposes a multicast data link protocol for third generation (3G) high frequency (HF) radio networks:

http://mac-ee211.nmsu.edu/hf/papers/3g_mdl.pdf
I have a doubt about the "MDL Operation" paragraph and the related Figure 3 of the paper:

According to §4.6.5 "Dual Demodulation" of Annex-C to STANAG-4538 Ed.1: under no circumstances shall PUs be required to simultaneously demodulate more than two waveforms.
Well, at time "tn" in Figure 3 the receiving PUs expect an LDL_DATA PDU (BW3) or an LDL_EOM/TERM PDU (BW4): sending a FLSU PDU (BW5) would impose a triple demodulation requirement. 

Thus, the calling PU shall send an LDL_EOM PDU (BW4) to indicate that the entire datagram has been transferred and the FEC Phase 0 session is terminated; then the following FSL PDU (BW5) will be sent to announce the repetition of the datagram in the alternate FEC code:

Anyway, since the multicast scenarios proposed in the paper have been evaluated using the DoD-validated HF Network Simulator (NetSim-SC), and then not implemented in real radios, the procedure depicted in Figure 3, although wrong, could be a simplification.

NATO "copy-and-paste" ...and errors

Computer-based editing can involve very frequent use of copy-and-paste operations but sometimes these operations can lead to significant errors. I came across a case by reading the Annex C to STANAG-4538 Ed.1, more precisely the Amendment 21. The problem arises in "TABLE 7.2.5.2-1. LDL actions", where is specified (litterally):

"Note: The LDL transmitter can send duplicate packets either as a result of missing an LDL_ACK PDU, or at the end of a datagram, in order to fill the (otherwise unused) packet positions of an LDL_DATA PDU. The LDL receiver is required to inspect the sequence number of each data packet received without errors, and to use the sequence numbers to identify and discard duplicate packets." (highlighted in Figure 1).

Fig. 1

This text is clearly a copy-and-paste from "TABLE 7.1.5.2-2. HDL actions", unless the the term HDL (Figure 2):

Fig. 2

Well, the statement "The LDL transmitter can send duplicate packets either [...] or at the end of a datagram, in order to fill the (otherwise unused) packet positions of an LDL_DATA PDU."  (Fig .1) is wrong since LDL protocol, contrary to HDL, does not provide 'packet positions' in its DATA PDU but rather one single packet at a time! (each HDL_DATA PDU is a sequence of 24, 12, 6, or 3 data packets, in which each packet is composed of 233 bytes of payload data; each LDL_DATA PDU is a single data packet composed of 32, 64, 96,..., 512 bytes of payload data).

It's an oversight that hopefully will be edited in the next edition :)