12-23-2020, 05:50 PM
(This post was last modified: 12-23-2020, 07:08 PM by WX9O.
Edit Reason: Remove KISS extensions
)
I am starting to document an implementation of M17 over KISS. This entails using a KISS TNC (modem) for M17 baseband modulation and demodulation.
This is very much a work in progress at the moment, and major design decisions are still to be worked out.
Please refer to the KISS protocol documentation here: http://www.ax25.net/kiss.aspx
We will discuss both audio streaming mode and packet mode.
There are a number of design trade-offs. KISS is an acronym for "Keep it simple, stupid." And it's hallmark is that very little protocol work is actually done in the KISS TNC. Only layer 1 (physical layer, baseband modulation) and layer 2 (HDLC framing and CSMA) is typically done in a KISS TNC. The packet, typically an AX.25 packet, is sent over a SLIP-encoded channel with a 1-byte header. The lower nibble of the header defines the KISS data frame type. A data frame is represented by frame type 0. There are 5 control frames defined.
The upper nibble of the header byte defines the modem identifier for systems with multiple modems. The default is 0. We can consider different M17 interfaces as distinct modems in a KISS TNC implementation.
M17 is a bit more complex than AX.25 over AFSK or FSK using HDLC framing. M17 defines 3 frame types (link setup, stream, packet), and the stream frame contains two data channels, the LICH and the payload (possibly 3 channels if you consider V/D mode). The data link layer requires both a source and destination identifier. The first issue we run into is that KISS modems handle the physical and data link layer, and there is no protocol defined for setting things like source, destination or, should it be used, encryption nonce.
We are going to define three (3) modem types. Two for packet and one for streaming. We are also going to define extended KISS commands for setting source, destination and nonce.
BASIC M17 KISS MODEM
In order to provide the most backwards-compatible implementation, packet mode using TNC identifier 0 will send packets with the source identifier set to a device type identifier, similar to the APRS TOCALL identifier. The destination address is "M17PACKET". Packet type 0, RAW, will be used for the packet payload. The TNC will be responsible for constructing the packet frame, attaching the type field and computing the CRC. It is also responsible for unwrapping received packet frames, dropping packets with invalid CRCs and passing received raw data back to the host, discarding the packet type identifier and CRC.
The goal of this mode is that all applications that currently function with KISS TNCs can use M17 as the physical and link layer. Station identification must be done inside the payload, such as with an AX.25 MYCALL identifier.
FULL-FEATURED KISS MODEMS
For M17 modems, modem identifier 1 is the full-featured M17 packet interface. It expect to receive a single frame of data containing a 30-byte link setup frame followed immediately by a 3-800-byte payload. The payload includes the type field and CRC. It returns the same data to the host when packet data is received.
STREAM INTERFACE
Modem identifier 2 is the M17 stream interface. It expects to receive a single 30-byte LSF frame, followed by a series of 20-byte data frames. The last frame in the sequence must have the end-of-stream bit set.
Received stream packets are sent to the host in the same manner. The TNC must provide a packet every 40ms. The host must be able to handle missing/dropped packets or streams that end without an EOS bit set, possibly due to loss of signal mid-stream. [This needs to be more fully fleshed out.]
The LSF is 30 bytes.
Stream data is 20 bytes (FN, payload, CRC).
For host to TNC:
In streaming mode, the TNC receives a single 30-byte LSF payload.
It verifies that the CRC is correct and that the packet/stream bit indicates "STREAM".
It starts transmitting the preamble, then LSF.
The host sends 20-byte data frames containing Codec2 audio payload, frame number and CRC.
The TNC checks the FN for the end-of-stream indicator, and optionally checking the CRC.
The TNC will have a backlog of up to 2 frames of audio data, collected while sending the preamble and LSF.
The TNC can insert up to 2 frames with empty payload data (and proper CRC) if the stream is interrupted. (What to do with FN?)
The TNC will end the stream if 3 or more frames have been missed. It will end the stream by sending an empty payload with the EOS bit set.
PACKET INTERFACE
For packet mode, the TNC will receive a 33-830 byte packet containing LSF and packet payload.
It will send the preamble, LSF and split the packet into frames.
For TNC to host:
For packet mode, the TNC will capture the LSF and payload.
It will verify the CRC on both the LSF and the payload.
By default, the full-featured M17 packet modems (id 2) should operate in PASSALL mode, allowing the host to drop packets with bad checksums.
This is very much a work in progress at the moment, and major design decisions are still to be worked out.
Please refer to the KISS protocol documentation here: http://www.ax25.net/kiss.aspx
We will discuss both audio streaming mode and packet mode.
There are a number of design trade-offs. KISS is an acronym for "Keep it simple, stupid." And it's hallmark is that very little protocol work is actually done in the KISS TNC. Only layer 1 (physical layer, baseband modulation) and layer 2 (HDLC framing and CSMA) is typically done in a KISS TNC. The packet, typically an AX.25 packet, is sent over a SLIP-encoded channel with a 1-byte header. The lower nibble of the header defines the KISS data frame type. A data frame is represented by frame type 0. There are 5 control frames defined.
The upper nibble of the header byte defines the modem identifier for systems with multiple modems. The default is 0. We can consider different M17 interfaces as distinct modems in a KISS TNC implementation.
M17 is a bit more complex than AX.25 over AFSK or FSK using HDLC framing. M17 defines 3 frame types (link setup, stream, packet), and the stream frame contains two data channels, the LICH and the payload (possibly 3 channels if you consider V/D mode). The data link layer requires both a source and destination identifier. The first issue we run into is that KISS modems handle the physical and data link layer, and there is no protocol defined for setting things like source, destination or, should it be used, encryption nonce.
We are going to define three (3) modem types. Two for packet and one for streaming. We are also going to define extended KISS commands for setting source, destination and nonce.
BASIC M17 KISS MODEM
In order to provide the most backwards-compatible implementation, packet mode using TNC identifier 0 will send packets with the source identifier set to a device type identifier, similar to the APRS TOCALL identifier. The destination address is "M17PACKET". Packet type 0, RAW, will be used for the packet payload. The TNC will be responsible for constructing the packet frame, attaching the type field and computing the CRC. It is also responsible for unwrapping received packet frames, dropping packets with invalid CRCs and passing received raw data back to the host, discarding the packet type identifier and CRC.
The goal of this mode is that all applications that currently function with KISS TNCs can use M17 as the physical and link layer. Station identification must be done inside the payload, such as with an AX.25 MYCALL identifier.
FULL-FEATURED KISS MODEMS
For M17 modems, modem identifier 1 is the full-featured M17 packet interface. It expect to receive a single frame of data containing a 30-byte link setup frame followed immediately by a 3-800-byte payload. The payload includes the type field and CRC. It returns the same data to the host when packet data is received.
STREAM INTERFACE
Modem identifier 2 is the M17 stream interface. It expects to receive a single 30-byte LSF frame, followed by a series of 20-byte data frames. The last frame in the sequence must have the end-of-stream bit set.
Received stream packets are sent to the host in the same manner. The TNC must provide a packet every 40ms. The host must be able to handle missing/dropped packets or streams that end without an EOS bit set, possibly due to loss of signal mid-stream. [This needs to be more fully fleshed out.]
The LSF is 30 bytes.
Stream data is 20 bytes (FN, payload, CRC).
For host to TNC:
In streaming mode, the TNC receives a single 30-byte LSF payload.
It verifies that the CRC is correct and that the packet/stream bit indicates "STREAM".
It starts transmitting the preamble, then LSF.
The host sends 20-byte data frames containing Codec2 audio payload, frame number and CRC.
The TNC checks the FN for the end-of-stream indicator, and optionally checking the CRC.
The TNC will have a backlog of up to 2 frames of audio data, collected while sending the preamble and LSF.
The TNC can insert up to 2 frames with empty payload data (and proper CRC) if the stream is interrupted. (What to do with FN?)
The TNC will end the stream if 3 or more frames have been missed. It will end the stream by sending an empty payload with the EOS bit set.
PACKET INTERFACE
For packet mode, the TNC will receive a 33-830 byte packet containing LSF and packet payload.
It will send the preamble, LSF and split the packet into frames.
For TNC to host:
For packet mode, the TNC will capture the LSF and payload.
It will verify the CRC on both the LSF and the payload.
By default, the full-featured M17 packet modems (id 2) should operate in PASSALL mode, allowing the host to drop packets with bad checksums.