M17_spec/pages/02.part-1/04.data-link-layer/docs.md

title	taxonomy	media_order
Data Link Layer	category docs

Frame

A Frame shall be composed of a frame type specific Synchronization Burst (Sync Burst) followed by 368 bits (184 symbols) of Payload. The combination of Sync Burst plus Payload results in a constant 384 bit (192 symbol) Frame. At the M17 data rate of 4800 symbols/s (9600 bits/s), each Frame is exactly 40ms in duration.

There are four frame types each with their own specific Sync Burst: Link Setup Frames (LSF), Bit Error Rate Test (BERT) Frames, Stream Frames, and Packet Frames.

Figure 5 Frame

SYNC BURST (16 bits / 8 symbols)	PAYLOAD (368 bits / 184 symbols)

Forward Error Correction (FEC)

The Data Link Layer Contents of a specific frame are modified using various Error Correction Code (ECC) methods. Applying these codes at the transmitter allows the receiver to correct some amount of induced errors in a Forward Error Correction (FEC) process. It is this ECC/FEC data that is inserted into the Payload portion of the Frame. The exact ECC/FEC techniques used vary by frame type.

Applying ECC/FEC may be a multi-step process. To distinguish data bits at the various stages of the process, Bit Types are defined as shown in the following table. It is important to note that not all ECC/FEC processes utilize both Type 2 and Type 3 bits. Prior to decoding Data Link Layer contents, a receiver would need to convert incoming bits from Type 4 back to Type 1 bits, which may also include conversion through Type 3 and/or Type 2 bits. The exact ECC/FEC methods and Bit Types utilized will be indicated for each frame type.

Table 2 Bit Types Type | Description ---- | ----------- Type 1 | Data link layer content bits Type 2 | Bits after appropriate encoding Type 3 | Bits after puncturing Type 4 | Interleaved (re-ordered) bits Figure 6 Transmit Contents to Payload [mermaid] graph LR contents[Data Link Layer Contents] -- Type 1 bits --> fec[ECC/FEC Encode] -- Type 4 bits--> payload[Payload] style contents fill:#ffffffff,stroke:#ffffffff,stroke-width:0px style fec fill:#fff,stroke:#000,stroke-width:2px style payload fill:#ffffffff,stroke:#ffffffff,stroke-width:0px [/mermaid] Figure 7 Receive Payload to Contents [mermaid] graph LR payload[Payload] -- Type 4 bits --> fec[ECC/FEC Decode] -- Type 1 bits--> contents[Data Link Layer Contents] style contents fill:#ffffffff,stroke:#ffffffff,stroke-width:0px style fec fill:#fff,stroke:#000,stroke-width:2px style payload fill:#ffffffff,stroke:#ffffffff,stroke-width:0px [/mermaid]

Modes

The Data Link layer shall operate in one of three modes during a Transmission.

• Stream Mode
  Data are sent in a continuous stream for an indefinite amount of time, with no break in physical layer output, until the stream ends. e.g. voice data, bulk data transfers, etc. Stream Mode shall start with an LSF and is followed by one or more Stream Frames.

• Packet Mode
  Data are sent in small bursts, up to 798 bytes at a time, after which the physical layer stops sending data. e.g. messages, beacons, etc. Packet Mode shall start with an LSF and is followed by one to 32 Packet Frames.

• BERT Mode
  PRBS9 is used to fill frames with a deterministic bit sequence. Frames are sent in a continuous sequence. Bert Mode shall start with a BERT frame, and is followed by one or more BERT Frames.

Note: As is the convention with other networking protocols, all values and data structures are encoded in big endian byte order.

Synchronization Burst (Sync Burst)

All frames shall be preceded by 16 bits (8 symbols) of Sync Burst. The Sync Burst definition straddles both the Physical Layer and the Data Link Layer.

Only LSF and BERT Sync Bursts may immediately follow the Preamble, and each requires a different Preamble symbol pattern as shown in the table below.

During a Transmission, only one LSF Sync Burst may be present, and if present, it shall immediately follow the Preamble.

BERT Sync Bursts, if present, may only follow the Preamble or other BERT frames.

Multiple Stream or Packet Sync Bursts may be present during a Transmission, depending on the mode.

Table 3 Frame Specific Sync Bursts Frame Type | Preamble | Sync Burst Bytes | Sync Burst Symbols ---------- | -------- | ---------------- | ------------------ LSF | +3, -3 | 0x55 0xF7 | +3, +3, +3, +3, -3, -3, +3, -3 BERT | -3, +3 | 0xDF 0x55 | -3, +3, -3, -3, +3, +3, +3, +3 Stream | None | 0xFF 0x5D | -3, -3, -3, -3, +3, +3, -3, +3 Packet | None | 0x75 0xFF | +3, -3, +3, +3, -3, -3, -3, -3

Link Setup Frame (LSF)

The LSF is the initial frame for both Stream and Packet Modes and contains information needed to establish a link.

Table 4 Link Setup Frame Contents Field | Length | Description ----- | ------ | ----------- DST | 48 bits | Destination address - Encoded callsign or a special number (eg. a group) SRC | 48 bits | Source address - Encoded callsign of the originator or a special number (eg. a group) TYPE | 16 bits | Information about the incoming data stream META | 112 bits | Metadata field, suitable for cryptographic metadata like IVs or single-use numbers, or non-crypto metadata like the sender’s GNSS position. CRC | 16 bits | CRC for the link setup data Total: 240 Type 1 bits

LSF DST and SRC

Destination and source addresses may be encoded amateur radio callsigns, or special numbers. See the Address Encoding Appendix for details.

LSF TYPE

The TYPE field contains information about the frames to follow LSF. The Packet/Stream indicator bit determines which mode (Packet or Stream) will be used during the transmission. The remaining field meanings are defined by the specific mode and application.

Table 5 LSF TYPE definition Bits | Content ---- | ------- 0 | Packet/Stream indicator 1..2 | Data type indicator 3..4 | Encryption type 5..6 | Encryption subtype 7..10 | Channel Access Number (CAN) 11..15 | Reserved (don’t care) Table 5a Packet/Stream indicator Value | Mode ---- | ------- 0 | Packet mode 1 | Stream mode Table 5b Data type Value | Content ---- | ------- \(00_2\) | Reserved \(01_2\) | Data \(10_2\) | Voice \(11_2\) | Voice+Data Table 5c Encryption type Value | Encryption ---- | ------- \(00_2\) | None \(01_2\) | AES \(10_2\) | Scrambler \(11_2\) | Other/reserved

For the encryption subtype, meaning of values depends on encryption type.

LSF META

The LSF META field is defined by the specific application.

LSF CRC

M17 uses a non-standard version of 16-bit CRC with polynomial x^{16} + x^{14} + x^{12} + x^{11} + x^8 + x^5 + x^4 + x^2 + 1 or 0x5935 and initial value of 0xFFFF. This polynomial allows for detecting all errors up to hamming distance of 5 with payloads up to 241 bits, which is less than the amount of data in each frame.

As M17’s native bit order is most significant bit first, neither the input nor the output of the CRC algorithm gets reflected.

The input to the CRC algorithm consists of DST, SRC (each 48 bits), 16 bits of TYPE field and 112 bits META, and then depending on whether the CRC is being computed or verified either 16 zero bits or the received CRC.

The test vectors in the following table are calculated by feeding the given message and then 16 zero bits to the CRC algorithm.

Table 6 CRC Test Vectors Message | CRC Output ------- | ---------- (empty string) | 0xFFFF ASCII string "A" | 0x206E ASCII string "123456789" | 0x772B Bytes 0x00 to 0xFF | 0x1C31

LSF Contents ECC/FEC

The 240 Type 1 bits of the Link Setup Frame Contents along with 4 flush bits are convolutionally coded using a rate 1/2 coder with constraint K=5. 244 bits total are encoded resulting in 488 Type 2 bits.

Type 3 bits are computed by P_1 puncturing the Type 2 bits, resulting in 368 Type 3 bits.

Interleaving the Type 3 bits produces 368 Type 4 bits that are ready to be passed to the Physical Layer.

Within the Physical Layer, the 368 Type 4 bits are randomized and combined with the 16-bit LSF Sync Burst, which results in a complete frame of 384 bits (384 bits / 9600bps = 40 ms).

Figure 8 LSF Construction [mermaid] graph TD

lsf_conv_coder["convolutional encoder"] lsf_p1_puncturer["P₁ puncturer"] lsf_interleaver["interleaver"] lsf_randomizer["randomizer"] lsf_sync["prepend LSF Sync Burst"] lsf_flush["add 4 flush bits"]

phy_cont["Physical Layer Continues..."]

classDef default fill:#fff,stroke:#000,stroke-width:2px

subgraph phy["Physical Layer"] lsf_randomizer --> lsf_sync -- 384-bit Frame -->phy_cont end

subgraph data_link["Data Link Layer"] LSF[LSF Contents] -- 240 Type 1 bits--> lsf_flush --> lsf_conv_coder -- 488 Type 2 bits --> lsf_p1_puncturer -- 368 Type 3 bits --> lsf_interleaver -- 368 Type 4 bits --> lsf_randomizer end

[/mermaid]

Stream Mode

In Stream Mode, an indefinite amount of data is sent continuously without breaks in the physical layer. Stream Mode shall always start with an LSF that has the LSF TYPE Packet/Stream indicator bit set to 1 (Stream Mode). Other valid LSF TYPE parameters are selected per application.

Following the LSF, one or more Stream Frames may be sent.

Figure 9 Stream Mode

PREAMBLE

LSF SYNC BURST

LSF FRAME

STREAM SYNC BURST

STREAM FRAME

•••

STREAM SYNC BURST

STREAM FRAME

EoT

Stream Frames

Stream Frames are composed of frame signalling information contained within the Link Information Channel (LICH) combined with Stream Contents. Both the LICH and Stream Contents utilize different ECC/FEC mechanisms, and are combined at the bit level in a Frame Combiner.

Link Information Channel (LICH)

The LICH allows for late listening and independent decoding to check destination address if the LSF for the current transmission was missed.

Each Stream Frame contains a 48-bit Link Information Channel (LICH). Each LICH within a Stream Frame includes a 40-bit chunk of the 240-bit LSF frame that was used to establish the stream. A 3-bit modulo 6 counter (LICH_CNT) is used to indicate which chunk of the LSF is present in the current Stream Frame. LICH_CNT starts at 0, increments to 5, then wraps back to 0.

Table 7 Link Information Channel Contents Bits | Content ---- | ------- 0..39 | 40-bit chunk of full LSF Contents (Type 1 bits) 40..42 | LICH_CNT 43..47 | Reserved Total: 48 bits

The 40-bit chunks start with the most significant byte of the LSF.

Table 8 LICH_CNT and LSF bits LICH_CNT | LSF bits -------- | ------- 0 | 239:200 1 | 199:160 2 | 159:120 3 | 119:80 4 | 79:40 5 | 39:0

LICH Contents ECC/FEC

The 48-bit LICH Contents is partitioned into 4 12-bit parts and encoded using Golay (24, 12) code. This produces 96 encoded Type 2 bits that are fed into the Frame Combiner.

Stream Contents

Table 9 Stream Contents Field | Length | Description ----- | ------ | ----------- FN | 16 bits | Frame Number STREAM | 128 bits | Stream data, can contain arbitrary data Total: 144 Type 1 bits

The Frame Number (FN) starts from 0 and increments every frame to a maximum of 0x7fff where it will then wrap back to 0. The most significant bit in the FN is used for transmission end signalling. When transmitting the last frame, it shall be set to 1 (one), and 0 (zero) in all other frames.

Stream data (STREAM) is obtained by extracting 128 bits at a time from the continuous stream of application layer data. If the last frame will contain less than 128 bits of valid data, the remaining bits should be set to zero.

Stream Contents ECC/FEC

The 144 Type 1 bits of Stream Contents along with 4 flush bits are convolutionally coded using a rate 1/2 coder with constraint K=5. 148 bits total are encoded resulting in 296 Type 2 bits.

These bits are P_2 punctured to generate 272 Type 3 bits that are fed into the Frame Combiner.

Frame Combiner

The 96 Type 2 bits of the ECC/FEC LICH Contents are concatenated with 272 Type 3 bits of the ECC/FEC Stream Contents resulting in 368 of combined Type 2/3 bits.

Table 10 LICH and Stream Combined Field | Length | Description ------ | ------ | ----------- LICH | 96 bits | ECC/FEC LICH Contents Type 2 bits STREAM | 272 bits | ECC/FEC STREAM Contents Type 3 bits Total: 368 Type 2/3 bits

Interleaving the Combined Type 2/3 bits produces 368 Type 4 bits that are ready to be passed to the Physical Layer.

Within the Physical Layer, the 368 Type 4 bits are randomized and combined with the 16-bit Stream Sync Burst, which results in a complete frame of 384 bits (384 bits / 9600bps = 40 ms).

Figure 10 Stream Frame Construction [mermaid] graph TD

lich_chunk_40["chunk 40 bits"] lich_golay_24_12["Golay (24, 12)"] lich_counter["add LICH counter"]

stream_data["Stream Data"] stream_chunk_128["chunk 128 bits"] stream_frame_number["prepend frame number"] stream_flush["add 4 flush bits"] stream_conv_coder["convolutional encoder"] stream_p2_puncturer["P₂ puncturer"]

lich_stream_frame_combiner["Frame Combiner"]

stream_interleaver["interleaver"] stream_randomizer["randomizer"] stream_sync["prepend Stream Sync Burst"]

phy_cont["Physical Layer Continues..."]

classDef default fill:#fff,stroke:#000,stroke-width:2px

subgraph phy ["Physical Layer"] stream_randomizer --> stream_sync -- 384-bit Frame --> phy_cont end

subgraph data_link["Data Link Layer"] LSF[LSF Contents] --> lich_chunk_40 -- 40 Type 1 bits --> lich_counter --> lich_golay_24_12 -- 96 Type 2 bits --> lich_stream_frame_combiner stream_chunk_128 --> stream_frame_number -- 144 Type 1 bits --> stream_flush --> stream_conv_coder -- 296 Type 2 bits --> stream_p2_puncturer -- 272 Type 3 bits --> lich_stream_frame_combiner lich_stream_frame_combiner -- 96 Type 2 bits + 272 Type 3 bits = 368 Type 2/3 bits --> stream_interleaver -- 368 Type 4 bits --> stream_randomizer end

subgraph application_layer["Application Layer"] stream_data -- Continuous data --> stream_chunk_128 end

[/mermaid]

Stream Superframes

Stream Frames are grouped into Stream Superframes, which is the group of 6 frames that contain everything needed to rebuild the original LSF packet, so that the user who starts listening in the middle of a stream (late-joiner) is eventually able to reconstruct the LSF message and understand how to receive the in-progress stream.

Figure 11 Stream Superframes 

Packet Mode

In Packet Mode, a Single Packet with up to 798 bytes of Application Packet Data along with an appended two byte CRC may be sent over the physical layer during one Transmission.

Table 11 Single Packet Bytes | Meaning ----- | ------- 1..798 | Application Packet Data 2 | CRC Total: 800 bytes (maximum)

The CRC used here is the same as described in LSF CRC.

Packet Mode shall always start with an LSF that has the LSF TYPE Packet/Stream indicator bit set to 0 (Packet Mode). Following the LSF, one to 32 Packet Frames may be sent.

Packet Mode achieves a base throughput of 5 kbps, a net throughput of approximately 4.7 kbps for the largest data payload, and over 3 kbps for 100-byte payloads. Net throughput takes into account preamble and link setup overhead.

Figure 12 Packet Mode

PREAMBLE

LSF SYNC BURST

LSF FRAME

PACKET SYNC BURST

PACKET FRAME

•••

PACKET SYNC BURST

PACKET FRAME

EoT

Packet Frames

Packet Frames contain Packet Contents after ECC/FEC is applied.

Packet Contents

Table 12 Packet Contents Bits | Meaning ---- | ------- 0..199 | 200-bit chunk of Single Packet 1 | End of Frame (EOF) indicator 5 | Packet Frame/Byte Counter Total: 206 Type 1 bits

The metadata field contains the 1-bit End of Frame (EOF) indicator, and the 5-bit Packet Frame/Byte Counter.

Each Packet Frame Content payload contains up to a 25-byte chunk of the Single Packet. The 25-byte chunks start with the first byte of the Application Packet data, and finally end with the 2 CRC bytes. If fewer than 25 bytes are able to be extracted from the Single Packet (i.e. for the last Packet Frame), the Single Packet chunk is padded with undefined bytes to reach 25 bytes total. This results in a minimum of one to a maximum of 32 Packet Frames per Transmission. The Packet Frame Counter is reset to zero at the start of Packet Mode.

For each Packet Frame where there is at least 1 byte remaining in the Single Packet after removing a 25-byte chunk, the EOF metadata bit is set to zero, the Packet Frame Counter value is inserted into the Packet Frame/Byte Counter metadata field, and the Packet Frame Counter is incremented.

When there are no bytes remaining in the Single Packet after removing a 25-byte (or less) chunk, the EOF metadata bit is set to one, the Packet Byte Counter is set to the number of valid bytes extracted in the last chunk (1 to 25), inserted into the Packet Frame/Byte Counter metadata field, and Packet Mode is ended.

Table 13 Metadata Field with EOF = 0 Bits | Meaning ---- | ------- 0 | Set to 0, Not end of frame 1..5 | Frame number, 0..31
Table 14 Metadata Field with EOF = 1 Bits | Meaning ---- | ------- 0 | Set to 1, End of frame 1..5 | Number of bytes in frame, 1..25

Packet Contents ECC/FEC

The 206 Type 1 bits of the Packet Contents along with 4 flush bits are convolutionally coded using a rate 1/2 coder with constraint K=5. 210 bits total are encoded resulting in 410 Type 2 bits.

These bits are P_3 punctured to generate 368 Type 3 bits.

Interleaving the Type 3 bits produces 368 Type 4 bits that are ready to be passed to the Physical Layer.

Within the Physical Layer, the 368 Type 4 bits are randomized and combined with the 16-bit Packet Sync Burst, which results in a complete frame of 384 bits (384 bits / 9600bps = 40 ms).

Figure 13 Packet Frame Construction [mermaid] graph TD

packet_data["Packet Data"] packet_crc["add CRC"] packet_chunk_200["chunk 200 bits"] packet_frame_number["add metadata"] packet_flush["add 4 flush bits"] packet_conv_coder["convolutional encoder"] packet_p3_puncturer["P₃ puncturer"] packet_interleaver["interleaver"] packet_randomizer["randomizer"] packet_sync["prepend Packet Sync Burst"]

phy_cont["Physical Layer Continues..."]

classDef default fill:#fff,stroke:#000,stroke-width:2px

subgraph phy ["Physical Layer"] packet_randomizer -->packet_sync --> phy_cont end

subgraph data_link["Data Link Layer"] packet_crc --> packet_chunk_200 --> packet_frame_number -- 206 Type 1 bits --> packet_flush --> packet_conv_coder -- 420 Type 2 bits --> packet_p3_puncturer -- 368 Type 3 bits --> packet_interleaver -- 368 Type 4 bits --> packet_randomizer end

subgraph application_layer["Application Layer"] packet_data -- 798 bytes max per packet --> packet_crc end [/mermaid]

Packet Superframes

A Packet Superframe consists of up to the 32 Packet Frames used to reconstruct the original Single Packet.

BERT Mode

BERT mode is a standardized, interoperable mode for bit error rate testing. The preamble is sent, followed by an indefinite sequence of BERT frames. Notably, an LSF is not sent in BERT mode.

The primary purpose of defining a bit error rate testing standard for M17 is to enhance interoperability testing across M17 hardware and software implementations, and to aid in the configuration and tuning of ad hoc communications equipment common in amateur radio.

Figure 14 BERT Mode

PREAMBLE

BERT SYNC BURST

BERT FRAME

•••

BERT SYNC BURST

BERT FRAME

EoT

BERT Frames

BERT Frames contain BERT Contents after ECC/FEC is applied.

BERT Contents

The BERT Contents consists of 197 bits from a PRBS9 generator. This is 24 bytes and 5 bits of data. The next BERT Contents starts with the 198th bit from the PRBS9 generator. The same generator is used for each subsequent BERT Contents without being reset. The number of bits pulled from the generator, 197, is a prime number. This will produce a reasonably large number of unique frames even with a PRBS generator with a relatively short period.

See the Appendix for BERT generation and reception details.

Table 15 BERT Contents Bits | Meaning ---- | ------- 0-196 | BERT PRBS9 Payload Total: 197 Type 1 bits

BERT Contents ECC/FEC

The 197 Type 1 bits of the Packet Contents along with 4 flush bits are convolutionally coded using a rate 1/2 coder with constraint K=5. 201 bits total are encoded resulting in 402 Type 2 bits.

These bits are P_2 punctured to generate 368 Type 3 bits.

Interleaving the Type 3 bits produces 368 Type 4 bits that are ready to be passed to the Physical Layer.

This provides the same error ECC/FEC used for Stream Frames.

Within the Physical Layer, the 368 Type 4 bits are randomized and combined with the 16-bit BERT Sync Burst, which results in a complete frame of 384 bits (384 bits / 9600bps = 40 ms).

Figure 15 BERT Frame Construction [mermaid] graph TD

bert_data["BERT PRBS9 Data"] bert_chunk_197["chunk 197 bits"] bert_flush["add 4 flush bits"] bert_conv_coder["convolutional encoder"] bert_p2_puncturer["P_2 puncturer"] bert_interleaver["interleaver"] bert_randomizer["randomizer"] bert_sync["prepend BERT Sync Burst"]

phy_cont["Physical Layer Continues..."]

classDef default fill:#fff,stroke:#000,stroke-width:2px

subgraph phy ["Physical Layer"] bert_randomizer --> bert_sync --> phy_cont end

subgraph data_link["Data Link Layer"] bert_data --> bert_chunk_197 -- 197 Type 1 bits --> bert_flush --> bert_conv_coder -- 402 Type 2 bits --> bert_p2_puncturer -- 368 Type 3 bits --> bert_interleaver -- 368 Type 4 bits --> bert_randomizer end [/mermaid]

Issues to address...

• Stream FN rollover - allowed or not?