03-27-2021, 07:19 PM

Now that we have removed the CAN from the FICH and agreed to include a 4-bit CRC. This means that we have one spare bit in each FICH. This leads to the following layout for the FICH:

0..39 40-bits of full LSF

40..42 A modulo 6 counter (LICH_CNT) for LSF reassembly

43 Reserved (set to 0)

44..47 4-bit CRC

It takes six fragments to get a full LSF. however when there is no encryption, which is common, this is just zero bytes and a waste. It would be better if we could send a shorter LSF and so we could decode the information from less frames when the link setup frame is not decoded. With no encryption the NONCE data can be removed. Therefore only the DST, SRC, TYPE and CRC are needed, that is 128 bits instead of 240. With 128 bits we can send all of the data in four fragments instead of six. The use of this shorter LSF can be indicated by this reserved bit. Leading to:

0..39 40-bits of full LSF

40..42 A modulo 6 (Long LSF), module 4 (Short LSF), counter (LICH_CNT) for LSF reassembly

43 Type of LSF, 0 = Short, 1 = Long

44..47 4-bit CRC

The long version is the same as we currently have with six fragments. The short version is the LSF without the NONCE. In the short version there are some unused bits in the final fragment, these are ignored and should be set to zero. I have a question, should the CRC in the short LSF be only for the DST, SRC, and TYPE, or should it also include the missing zero filled NONCE? The latter would make life easier for sending this data over the network where the NONCE will always be included.

The 4-bit CRC would use a standard polynomial, and I can give example code for the M17 specification once I have coded it. For efficiency, this CRC would be over the fill 48 bits of the LICH with the space for the CRC being set to zeroes. This would allow for an efficient byte wise implementation of the CRC algorithm.

Jonathan G4KLX

0..39 40-bits of full LSF

40..42 A modulo 6 counter (LICH_CNT) for LSF reassembly

43 Reserved (set to 0)

44..47 4-bit CRC

It takes six fragments to get a full LSF. however when there is no encryption, which is common, this is just zero bytes and a waste. It would be better if we could send a shorter LSF and so we could decode the information from less frames when the link setup frame is not decoded. With no encryption the NONCE data can be removed. Therefore only the DST, SRC, TYPE and CRC are needed, that is 128 bits instead of 240. With 128 bits we can send all of the data in four fragments instead of six. The use of this shorter LSF can be indicated by this reserved bit. Leading to:

0..39 40-bits of full LSF

40..42 A modulo 6 (Long LSF), module 4 (Short LSF), counter (LICH_CNT) for LSF reassembly

43 Type of LSF, 0 = Short, 1 = Long

44..47 4-bit CRC

The long version is the same as we currently have with six fragments. The short version is the LSF without the NONCE. In the short version there are some unused bits in the final fragment, these are ignored and should be set to zero. I have a question, should the CRC in the short LSF be only for the DST, SRC, and TYPE, or should it also include the missing zero filled NONCE? The latter would make life easier for sending this data over the network where the NONCE will always be included.

The 4-bit CRC would use a standard polynomial, and I can give example code for the M17 specification once I have coded it. For efficiency, this CRC would be over the fill 48 bits of the LICH with the space for the CRC being set to zeroes. This would allow for an efficient byte wise implementation of the CRC algorithm.

Jonathan G4KLX