kopia lustrzana https://github.com/M17-Project/M17_spec
Steve Miller
GitHub
commit
59a28ac50d
|
|
@ -15,8 +15,8 @@ title: Welcome
|
|||
* [Packet Mode](/part-1/data-link-layer#packet-mode)
|
||||
* [BERT Mode](/part-1/data-link-layer#bert-mode)
|
||||
* [Application Layer](/part-1/application-layer)
|
||||
* [Packet Superframes](/part-1/application-layer#packet-superframes)
|
||||
* [Encryption Types](/part-1/application-layer#encryption-types)
|
||||
* [Amateur Radio Voice Application](/part-1/application-layer#m17-amateur-radio-voice-application)
|
||||
* [Packet Application](/part-1/application-layer#packet-application)
|
||||
|
||||
## Part II - Internet Interface
|
||||
* [M17 Internet Protocol (IP) Networking](/part-2/ip-networking)
|
||||
|
|
|
|||
|
|
@ -25,9 +25,9 @@ There are four frame types each with their own specific Sync Burst: [Link Setup
|
|||
#### 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 distinquish 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.
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> Bit Types</center>
|
||||
<center><span style="font-weight:bold">Table 2</span> Bit Types</center>
|
||||
Type | Description
|
||||
---- | -----------
|
||||
Type 1 | Data link layer content bits
|
||||
|
|
@ -35,7 +35,7 @@ Type 2 | Bits after appropriate encoding
|
|||
Type 3 | Bits after puncturing
|
||||
Type 4 | Interleaved (re-ordered) bits
|
||||
|
||||
<center><span style="font-weight:bold">Figure 1</span> Transmit Contents to Payload</center>
|
||||
<center><span style="font-weight:bold">Figure 6</span> Transmit Contents to Payload</center>
|
||||
[mermaid]
|
||||
graph LR
|
||||
contents[Data Link Layer Contents] -- Type 1 bits --> fec[ECC/FEC Encode] -- Type 4 bits--> payload[Payload]
|
||||
|
|
@ -44,7 +44,7 @@ graph LR
|
|||
style payload fill:#ffffffff,stroke:#ffffffff,stroke-width:0px
|
||||
[/mermaid]
|
||||
|
||||
<center><span style="font-weight:bold">Figure 2</span> Receive Payload to Contents</center>
|
||||
<center><span style="font-weight:bold">Figure 7</span> Receive Payload to Contents</center>
|
||||
[mermaid]
|
||||
graph LR
|
||||
payload[Payoad] -- Type 4 bits --> fec[ECC/FEC Decode] -- Type 1 bits--> contents[Data Link Layer Contents]
|
||||
|
|
@ -83,7 +83,7 @@ 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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 2</span> Frame Specific Sync Bursts</center>
|
||||
<center><span style="font-weight:bold">Table 3</span> Frame Specific Sync Bursts</center>
|
||||
Frame Type | Preamble | Sync Burst Bytes | Sync Burst Symbols
|
||||
---------- | -------- | ---------------- | ------------------
|
||||
LSF | +3, -3 | 0x55 0xF7 | +3, +3, +3, +3, -3, -3, +3, -3
|
||||
|
|
@ -95,7 +95,7 @@ Packet | None | 0x75 0xFF | +3, -3, +3, +3, -3, -3, -3, -3
|
|||
|
||||
The LSF is the intial frame for both Stream and Packet Modes and contains information needed to establish a link.
|
||||
|
||||
<center><span style="font-weight:bold">Table 3</span> Link Setup Frame Contents</center>
|
||||
<center><span style="font-weight:bold">Table 4</span> Link Setup Frame Contents</center>
|
||||
Field | Length | Description
|
||||
----- | ------ | -----------
|
||||
DST | 48 bits | Destination address - Encoded callsign or a special number (eg. a group)
|
||||
|
|
@ -114,7 +114,7 @@ Destination and source addresses may be encoded amateur radio callsigns, or spec
|
|||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 4</span> LSF TYPE definition</center>
|
||||
<center><span style="font-weight:bold">Table 5</span> LSF TYPE definition</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0 | Packet/Stream indicator, 0=Packet Mode, 1=Stream Mode
|
||||
|
|
@ -138,7 +138,7 @@ The input to the CRC algorithm consists of DST, SRC (each 48 bits), 16 bits of T
|
|||
|
||||
The test vectors in the following table are calculated by feeding the given message and then 16 zero bits to the CRC algorithm.
|
||||
|
||||
<center><span style="font-weight:bold">Table 5</span> CRC Test Vectors</center>
|
||||
<center><span style="font-weight:bold">Table 6</span> CRC Test Vectors</center>
|
||||
Message | CRC Output
|
||||
------- | ----------
|
||||
(empty string) | 0xFFFF
|
||||
|
|
@ -156,6 +156,7 @@ Type 3 bits are computed by [\(P_1\) puncturing](../../04.appendix/05.code-punct
|
|||
|
||||
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).
|
||||
|
||||
<center><span style="font-weight:bold">Figure 8</span> LSF Construction</center>
|
||||
[mermaid]
|
||||
graph TD
|
||||
|
||||
|
|
@ -188,7 +189,7 @@ In Stream Mode, an *indefinite* amount of data is sent continuously without brea
|
|||
Following the LSF, one or more Stream Frames may be sent.
|
||||
|
||||
<table>
|
||||
<caption><span style="font-weight:bold">Figure 3 </span><span>Stream Mode</span></caption>
|
||||
<caption><span style="font-weight:bold">Figure 9 </span><span>Stream Mode</span></caption>
|
||||
<tbody style="text-align:center;border:none;">
|
||||
<tr style="font-weight:bold; color:black;">
|
||||
<td style="border:3px solid black;">PREAMBLE</td>
|
||||
|
|
@ -241,7 +242,7 @@ The 48-bit LICH Contents is partitioned into 4 12-bit parts and encoded using [G
|
|||
|
||||
##### Stream Contents
|
||||
|
||||
<center><span style="font-weight:bold">Table 6</span> Stream Contents</center>
|
||||
<center><span style="font-weight:bold">Table 9</span> Stream Contents</center>
|
||||
Field | Length | Description
|
||||
----- | ------ | -----------
|
||||
FN | 16 bits | Frame Number
|
||||
|
|
@ -262,7 +263,7 @@ These bits are [\(P_2\) punctured](../../04.appendix/05.code-puncturing) to gene
|
|||
|
||||
The 96 Type 2 bits of the ECC/FEC LICH Contents are concatenated with 272 Type 3 bits of the ECC/FEC Stream Contents resuting in 368 of combined Type 2/3 bits.
|
||||
|
||||
<center><span style="font-weight:bold">Table N</span> LICH and Stream Combined</center>
|
||||
<center><span style="font-weight:bold">Table 10</span> LICH and Stream Combined</center>
|
||||
Field | Length | Description
|
||||
------ | ------ | -----------
|
||||
LICH | 96 bits | ECC/FEC LICH Contents Type 2 bits
|
||||
|
|
@ -273,6 +274,7 @@ Total: 368 Type 2/3 bits
|
|||
|
||||
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).
|
||||
|
||||
<center><span style="font-weight:bold">Figure 10</span> Stream Frame Construction</center>
|
||||
[mermaid]
|
||||
graph TD
|
||||
|
||||
|
|
@ -317,14 +319,14 @@ end
|
|||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 6</span> Stream Superframes</center>
|
||||
<center><span style="font-weight:bold">Figure 11</span> Stream Superframes</center>
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 9</span> Single Packet</center>
|
||||
<center><span style="font-weight:bold">Table 11</span> Single Packet</center>
|
||||
Bytes | Meaning
|
||||
----- | -------
|
||||
1..798 | Application Packet Data
|
||||
|
|
@ -338,7 +340,7 @@ Packet Mode shall always start with an LSF that has the LSF TYPE Packet/Stream i
|
|||
Packet Mode acheives 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.
|
||||
|
||||
<table>
|
||||
<caption><span style="font-weight:bold">Figure 3 </span><span>Packet Mode</span></caption>
|
||||
<caption><span style="font-weight:bold">Figure 12 </span><span>Packet Mode</span></caption>
|
||||
<tbody style="text-align:center;border:none;">
|
||||
<tr style="font-weight:bold; color:black;">
|
||||
<td style="border:3px solid black;">PREAMBLE</td>
|
||||
|
|
@ -360,7 +362,7 @@ Packet Frames contain Packet Contents after ECC/FEC is applied.
|
|||
|
||||
#### Packet Contents
|
||||
|
||||
<center><span style="font-weight:bold">Table 10</span> Packet Contents</center>
|
||||
<center><span style="font-weight:bold">Table 12</span> Packet Contents</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0..199 | 200-bit chunk of Single Packet
|
||||
|
|
@ -378,7 +380,7 @@ When there are no bytes remaining in the Single Packet after removing a 25-byte
|
|||
|
||||
<br/>
|
||||
|
||||
<center><span style="font-weight:bold">Table 11</span> Metadata Field with EOF = 0</center>
|
||||
<center><span style="font-weight:bold">Table 13</span> Metadata Field with EOF = 0</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0 | Set to 0, Not end of frame
|
||||
|
|
@ -386,7 +388,7 @@ Bits | Meaning
|
|||
|
||||
<br/>
|
||||
|
||||
<center><span style="font-weight:bold">Table 12</span> Metadata Field with EOF = 1</center>
|
||||
<center><span style="font-weight:bold">Table 14</span> Metadata Field with EOF = 1</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0 | Set to 1, End of frame
|
||||
|
|
@ -402,6 +404,7 @@ These bits are [\(P_3\) punctured](../../04.appendix/05.code-puncturing) to gene
|
|||
|
||||
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).
|
||||
|
||||
<center><span style="font-weight:bold">Figure 13</span> Packet Frame Construction</center>
|
||||
[mermaid]
|
||||
graph TD
|
||||
|
||||
|
|
@ -447,7 +450,7 @@ interoperability testing across M17 hardware and software implementations, and t
|
|||
configuration and tuning of ad hoc communications equipment common in amateur radio.
|
||||
|
||||
<table>
|
||||
<caption><span style="font-weight:bold">Figure X </span><span>BERT Mode</span></caption>
|
||||
<caption><span style="font-weight:bold">Figure 14 </span><span>BERT Mode</span></caption>
|
||||
<tbody style="text-align:center;border:none;">
|
||||
<tr style="font-weight:bold; color:black;">
|
||||
<td style="border:3px solid black;">PREAMBLE</td>
|
||||
|
|
@ -475,7 +478,7 @@ frames even with a PRBS generator with a relatively short period.
|
|||
|
||||
See the Appendix for [BERT generation and reception details](../../04.appendix/07.bert-details).
|
||||
|
||||
<center><span style="font-weight:bold">Table X</span> BERT Contents</center>
|
||||
<center><span style="font-weight:bold">Table 15</span> BERT Contents</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0-196 | BERT PRBS9 Payload
|
||||
|
|
@ -493,6 +496,7 @@ 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).
|
||||
|
||||
<center><span style="font-weight:bold">Figure 15</span> BERT Frame Construction</center>
|
||||
[mermaid]
|
||||
graph TD
|
||||
|
||||
|
|
@ -522,5 +526,5 @@ end
|
|||
### Issues to address...
|
||||
|
||||
* Stream FN rollover - allowed or not?
|
||||
*
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,30 +5,64 @@ taxonomy:
|
|||
- docs
|
||||
media_order: 'LFSR_8.svg,LFSR_16.svg,LFSR_24.svg'
|
||||
---
|
||||
### M17 Amateur Radio Voice Application
|
||||
|
||||
### M17 Voice Application
|
||||
This section defines the application layer parameters for an audio stream containing low bit rate speech encoded using the open source [Codec 2](http://rowetel.com/codec2.html) codec. It is intended to be used over the air by amateur radio operators worldwide. Implementation details for M17 clients, repeaters, and gateways ensure that an M17 Amateur Radio Voice Application is legal under all licencing regimes.
|
||||
|
||||
This section defines the application layer parameters for an audio stream containing low bit rate speech encoded using the open source [Codec 2](http://rowetel.com/codec2.html) codec.
|
||||
Definitions
|
||||
- M17 Client - an end station that transmits and receives M17 voice
|
||||
- M17 Repeater - a station that receives and retransmits (repeats) M17 voice
|
||||
- M17 Gateway - a station that receives and transmits M17 voice, converting to and from different formats (e.g. D-Star, DMR, EchoLink, etc.)
|
||||
|
||||
Credit to Jonathan Naylor (G4KLX) for [documenting and implementing](#references-acknowledgements) the details included here.
|
||||
|
||||
[Data Link Layer Stream Mode](../04.data-link-layer/#stream-mode) is used for this application.
|
||||
|
||||
#### M17 Voice Application LSF Parameters
|
||||
|
||||
A Stream Mode Transmission begins with an [LSF](../04.data-link-layer/#link-setup-frame-lsf).
|
||||
|
||||
<center><span style="font-weight:bold">Table 3</span> Link Setup Frame Contents</center>
|
||||
#### LSF/LICH
|
||||
|
||||
<center><span style="font-weight:bold">Table 16</span> Link Setup Frame Contents</center>
|
||||
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)
|
||||
DST | 48 bits | Destination address
|
||||
SRC | 48 bits | Source address
|
||||
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.
|
||||
META | 112 bits | Metadata field
|
||||
|
||||
Destination (DST) and source (SRC) addresses may be encoded amateur radio callsigns, or special numbers. See the [Address Encoding Appendix](../../appendix/address-encoding) for details.
|
||||
##### Address fields
|
||||
|
||||
Destination (DST) and source (SRC) addresses may be encoded amateur radio callsigns, or special identifiers. See the [Address Encoding Appendix](../../appendix/address-encoding) for details on how up to 9 characters of text can be encoded into the 6-byte address value.
|
||||
|
||||
The source address is always the callsign of the station transmitting, be it a client, repeater, or gateway. This is not a problem for a client, but for a repeater/gateway this raises issues about identifying the original source of a transmission. Having a repeater/gateway always use its own callsign for the source field does ensure that there are no issues with licensing authorities. To retain identification of the original source for a repeater/gateway, an extended callsign data field will be encoded in the LSF META field.
|
||||
|
||||
The destination address used by a client may simply be a callsign for a point to point contact, or may be one of the following special identifiers in the table below.
|
||||
|
||||
<center><span style="font-weight:bold">Table 17</span> Client destination address</center>
|
||||
Identifier | Address Value | Description
|
||||
---------------- | -------------- | -----------
|
||||
(Callsign) | varies | Destination callsign for a point to point contact
|
||||
ALL | 0xFFFFFFFFFFFF | Broadcast and any transmission is relayed to any connected reflector
|
||||
ECHO | 0x0000000ED87D | Enable the local echo function in a repeater/gateway
|
||||
INFO | 0x0000000ECDB9 | Trigger a voice and text announcement of the current linked status of the repeater/gateway
|
||||
UNLINK | 0x0000454F7745 | Unlink from a reflector and trigger an INFO response
|
||||
(Reflector Name) | varies | Link to a reflector and trigger an INFO response (if valid and not already linked)
|
||||
|
||||
The destination address of locally repeated radio transmission retains its original destination address, and the originator's callsign is encoded in the extended callsign data. For other transmissions, one of the following special identifiers may be used.
|
||||
|
||||
<center><span style="font-weight:bold">Table 18</span> Repeater/gateway destination address</center>
|
||||
Identifier | Address Value | Description
|
||||
---------------- | -------------- | -----------
|
||||
(Callsign) | varies | Destination callsign for a locally repeated radio transmission
|
||||
ALL | 0xFFFFFFFFFFFF | All transmitted reflector traffic, originator's callsign and the currently linked reflector are encoded in the extended callsign data
|
||||
ECHO | 0x0000000ED87D | Reply of the built-in echo function, originator's callsign is encoded in the extended callsign data
|
||||
INFO | 0x0000000ECDB9 | Voice and text announcement of the current linked status of the repeater/gateway
|
||||
|
||||
##### TYPE field
|
||||
|
||||
The TYPE field contains information about the frames to follow LSF.
|
||||
|
||||
<center><span style="font-weight:bold">Table 4</span> LSF TYPE definition</center>
|
||||
<center><span style="font-weight:bold">Table 18</span> M17 Voice LSF TYPE definition</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0 | Packet/Stream indicator
|
||||
|
|
@ -40,9 +74,7 @@ Bits | Meaning
|
|||
<nbsp> | $01_2$ = Scrambling
|
||||
<nbps> | $10_2$ = AES
|
||||
5..6 | Encryption subtype
|
||||
<nbsp> | foo
|
||||
7..10 | Channel Access Number (CAN)
|
||||
<nbsp> | foo
|
||||
11..15 | Reserved (don’t care)
|
||||
|
||||
This application requires Stream Mode.
|
||||
|
|
@ -57,29 +89,85 @@ Encryption is **optional**. The use of it may be restricted within some radio se
|
|||
|
||||
Encryption type = $00_2$
|
||||
|
||||
The “Encryption SubType” bits in the Stream Type field then indicate what data is stored in the 112 bits of the LSF META field.
|
||||
When no encryption is used, the 14-byte (112-bit) META field of the LSF and corresponding LICH of the stream can be used for transmitting relatively small amounts of extended data without affecting the bandwidth available for the audio. The full 14 bytes of META extended data is potentially decodable every six stream frames, at a 240 ms update rate. The extended data is transmitted in a simple round robin manner, with the only exception being GPS data which should be transmitted as soon as possible after the GPS data is received from its source.
|
||||
|
||||
Encryption SubType bits | LSF META data contents
|
||||
The "Encryption SubType" bits in the Stream Type field indicate what extended data is stored in the META field.
|
||||
|
||||
<center><span style="font-weight:bold">Table 19</span> Null encryption subtype bits</center>
|
||||
Encryption subtype bits | LSF META data contents
|
||||
----------------------- | ----------------------
|
||||
$00_2$ | UTF-8 Text
|
||||
$00_2$ | Text Data
|
||||
$01_2$ | GNSS Position Data
|
||||
$10_2$ | Reserved
|
||||
$10_2$ | Extended Callsign Data
|
||||
$11_2$ | Reserved
|
||||
|
||||
All LSF META data must be stored in big endian byte order.
|
||||
##### Text Data
|
||||
|
||||
The first byte of the Text Data is a Control Byte. To maintain backward compatability, a Control Byte of 0x00 indicates that no Text Data is included.
|
||||
|
||||
Up to four Text Data blocks compose a complete message with a maximum length of 52 bytes. Each block may contain up to 13 bytes of UTF-8 encoded text, and is padded with space characters to fill any unused space at the end of the last used Text Data block.
|
||||
|
||||
The Control Byte is split into two 4-bit fields. The most significant four bits are a bit map of the message length indicating how many Text Data blocks are required for a complete message. There is one bit per used Text Data block, with $0001_2$ used for one block, $0011_2$ for the two, $0111_2$ for three, and $1111_2$ for four.
|
||||
|
||||
The least significant four bits indicate which of the Text Data blocks this text corresponds to. It is $0001_2$ for the first, $0010_2$ for the second, $0100_2$ for the third, and $1000_2$ for the fourth. Any received Control Byte is OR-ed together by the receiving station, and once the most significant and least significant four bits are the same, a complete message has been received.
|
||||
|
||||
It is up to the receiver to decide how to display this message. It may choose to wait for all of the Text Data to be received, or display the parts as they are received. It is not expected that the data in the text field changes during the course of a transmission.
|
||||
|
||||
##### GNSS Data
|
||||
|
||||
Unlike Text and Extended Callsign Data, GNSS data is expected to be dynamic during the course of a transmission and to be transmitted quickly after the GNSS data becomes available. To stop the LSF/LICH data stream from being overrun with GNSS data relative to other data types, a throttle on the amount of GNSS data transmitted is needed. It is recommended that GNSS data be sent at an update rate no faster than once every five seconds.
|
||||
|
||||
The GNSS data fits within one 14-byte META field, which equates to six audio frames, and takes 240ms to transmit. This is a simple format of the GNSS data which does not require too much work to convert into, and provides enough flexibility for most cases. This has been tested on-air and successfully gated to APRS-IS, showing a location very close to the position reported by the GPS receiver.
|
||||
|
||||
GNSS Position Data stores the 112 bit META field as follows:
|
||||
|
||||
Size in bits | Format | Contents
|
||||
------------ | ------ | --------
|
||||
8 | 8-bit signed integer | Latitude - degrees, integer part (-90..+90, positive values for northern hemisphere)
|
||||
16 | 16-bit unsigned integer | Latitude - degrees, fractional part (eg. 0.5 -> 32,768)
|
||||
16 | 16-bit unsigned integer | Longitude - degrees, integer part (-180..+180, positive values for eastern hemisphere)
|
||||
16 | 16-bit unsigned integer | Longitude Longitude - degrees, fractional part (eg. 0.5 -> 32,768)
|
||||
16 | unsigned integer | Altitude, in feet MSL. Stored +1500, so a stored value of 0 represents -1500 MSL. Subtract 1500 feet when parsing.
|
||||
10 | unsigned integer | Course in degrees true North
|
||||
10 | unsigned integer | Speed in miles per hour
|
||||
20 | reserved values | Transmitter/Object description field
|
||||
<center><span style="font-weight:bold">Table 20</span> GNSS Data encoding</center>
|
||||
Size in bits | Format | Contents
|
||||
------------ | ------ | --------
|
||||
8 | unsigned integer | Data Source
|
||||
<nbsp> | <nbsp> | Used to modify the message added to the APRS message sent to APRS-IS
|
||||
<nbsp> | <nbsp> | 0x00 : M17 Client
|
||||
<nbsp> | <nbsp> | 0x01 : Open RTX
|
||||
8 | unsigned integer | Station Type
|
||||
<nbsp> | <nbsp> | Translated into suitable APRS symbols when gated to APRS-IS
|
||||
<nbsp> | <nbsp> | 0x00 : Fixed Station
|
||||
<nbsp> | <nbsp> | 0x01 : Mobile Station
|
||||
<nbsp> | <nbsp> | 0x02 : Handheld
|
||||
8 | unsigned integer | Whole number absolute value of degrees latitude
|
||||
16 | unsigned integer | Decimal degrees of latitude multiplied by 65535, MSB first
|
||||
8 | unsigned integer | Whole number absolute value of degrees longitude
|
||||
16 | unsigned integer | Decimal degrees of longitude multiplied by 65535, MSB first
|
||||
8 | unsigned integer | Latitude N/S, Longitude E/W, Altitude, Speed and Bearing bit fields
|
||||
<nbsp> | <nbsp> | $xxxxxxx0_2$ North Latitude
|
||||
<nbsp> | <nbsp> | $xxxxxxx1_2$ South Latitude
|
||||
<nbsp> | <nbsp> | $xxxxxx0x_2$ East Longitude
|
||||
<nbsp> | <nbsp> | $xxxxxx1x_2$ West Longitude
|
||||
<nbsp> | <nbsp> | $xxxxx0xx_2$ Altitude data invalid
|
||||
<nbsp> | <nbsp> | $xxxxx1xx_2$ Altitude data valid
|
||||
<nbsp> | <nbsp> | $xxxx0xxx_2$ Speed and Bearing data invalid
|
||||
<nbsp> | <nbsp> | $xxxx1xxx_2$ Speed and Bearing data valid
|
||||
16 | unsigned integer | Altitude above sea level in feet + 1500 (if valid), MSB first
|
||||
16 | unsigned integer | Whole number of bearing in degrees between 0 and 360 (if valid), MSB first
|
||||
8 | unsigned integer | Whole number of speed in miles per hour (if valid)
|
||||
|
||||
##### Extended Callsign Data
|
||||
|
||||
This is only transmitted from repeaters/gateways and not from clients, who only receive and display this data. These fields should not appear over M17 Internet links as they should only be used over the air from a repeater/gateway.
|
||||
|
||||
The META field is split into two callsign fields. The first is always present, and the second is optional. The callsign data is encoded using the standard M17 callsign [Address Encoding](../../appendix/address-encoding) which takes six bytes to encode a nine character callsign. Any unused space in the META field contains 0x00 bytes. The first callsign field starts at offset zero in the META field, and the second callsign if present starts immediately after the first. There are two unused bytes at the end of the META field.
|
||||
|
||||
The use of these two callsign fields is as follows:
|
||||
|
||||
<center><span style="font-weight:bold">Table 21</span> Extended Callsign Data encoding</center>
|
||||
Source | Callsign Field 1 | Callsign Field 2
|
||||
------------------- | ---------------- | ----------------
|
||||
Locally Repeated RF | Originator | Unused
|
||||
ECHO Reply | Originator | Unused
|
||||
Reflector Traffic | Originator | Reflector Name
|
||||
|
||||
The extended callsign data is not used under any other circumstances than the above currently.
|
||||
|
||||
It is not expected that the data in the extra callsign fields change during the course of a transmission.
|
||||
|
||||
##### Scrambling
|
||||
|
||||
|
|
@ -87,38 +175,36 @@ Encryption type = $01_2$
|
|||
|
||||
Scrambling is an encryption by bit inversion using a bitwise exclusive-or (XOR) operation between the bit sequence of data and a pseudorandom bit sequence.
|
||||
|
||||
Pseudorandom bit sequence is generated using a Fibonacci-topology Linear-Feedback Shift Register (LFSR). Three different LFSR sizes are available: 8, 16 and 24-bit. Each shift register has an associated polynomial. The polynomials are listed in Table 7. The LFSR is initialised with a seed value of the same length as the shift register. The seed value acts as an encryption key for the scrambler algorithm. Figures 5 to 8 show block diagrams of the algorithm
|
||||
Pseudorandom bit sequence is generated using a Fibonacci-topology Linear-Feedback Shift Register (LFSR). Three different LFSR sizes are available: 8, 16 and 24-bit. Each shift register has an associated polynomial. The polynomials are listed in Table 7. The LFSR is initialised with a seed value of the same length as the shift register. The seed value acts as an encryption key for the scrambler algorithm. Figures 16 to 18 show block diagrams of the algorithm.
|
||||
|
||||
<center><span style="font-weight:bold">Table 22</span> Scrambling</center>
|
||||
Encryption subtype | LFSR polynomial | Seed length | Sequence period
|
||||
------------------ | --------------- | ----------- | ---------------
|
||||
$00_2$ | $x^8 + x^6 + x^5 + x^4 + 1$ | 8 bits | 255
|
||||
$01_2$ | $x^{16} + x^{15} + x^{13} + x^4 + 1$ | 16 bits | 65,535
|
||||
$10_2$ | $x^{24} + x^{23} + x^{22} + x^{17} + 1$ | 24 bits | 16,777,215
|
||||
|
||||
|
||||
---
|
||||
<center><span style="font-weight:bold">Figure 16</span> 8-bit LSFR taps</center>
|
||||
|
||||
|
||||
---
|
||||
|
||||
<center><span style="font-weight:bold">Figure 17</span> 16-bit LSFR taps</center>
|
||||
|
||||
|
||||
---
|
||||
|
||||
<center><span style="font-weight:bold">Figure 18</span> 24-bit LSFR taps</center>
|
||||
|
||||
|
||||
---
|
||||
|
||||
#### Advanced Encryption Standard (AES)
|
||||
##### Advanced Encryption Standard (AES)
|
||||
|
||||
Encryption type = $10_2$
|
||||
|
||||
This method uses AES block cipher in counter (CTR) mode, with a 96-bit nonce that should never be used for more than one separate stream and a 32 bit CTR.
|
||||
This method uses AES block cipher in counter (CTR) mode, with a 96-bit nonce that should never be used for more than one separate stream and a 32-bit CTR.
|
||||
|
||||
The 96-bit AES nonce value is extracted from the 96 most significant bits of the META field, and the remaining 16 bits of the META field form the highest 16 bits of the 32 bit counter. The FN (Frame Number) field value is then used to fill out the lower 16 bits of the counter, and always starts from 0 (zero) in a new voice stream.
|
||||
The 96-bit AES nonce value is extracted from the 96 most significant bits of the META field, and the remaining 16 bits of the META field form the highest 16 bits of the 32-bit counter. The FN (Frame Number) field value is then used to fill out the lower 16 bits of the counter, and always starts from 0 (zero) in a new voice stream.
|
||||
|
||||
The 16 bit frame number and 40 ms frames can provide for over 20 minutes of streaming without rolling over the counter.
|
||||
The 16-bit frame number and 40 ms frames can provide for over 20 minutes of streaming without rolling over the counter.
|
||||
|
||||
> The effective capacity of the counter is 15 bits, as the MSB is used for transmission end signalling. At 40ms per frame, or 25 frames per second, and 2\*\*15 frames, we get 2\*\*15 frames / 25 frames per second = 1310 seconds, or 21 minutes and some change.
|
||||
> The effective capacity of the counter is 15 bits, as the MSB is used for transmission end signalling. At 40ms per frame, or 25 frames per second, and $2^15$ frames, we get $2^15$ frames / 25 frames per second = 1310 seconds, or almost 22 minutes.
|
||||
|
||||
The random part of the nonce value should be generated with a hardware random number generator or any other method of generating non-repeating values.
|
||||
|
||||
|
|
@ -126,6 +212,7 @@ To combat replay attacks, a 32-bit timestamp shall be embedded into the cryptogr
|
|||
|
||||
##### 96 bit nonce field structure
|
||||
|
||||
<center><span style="font-weight:bold">Table 23</span> Nonce field</center>
|
||||
| Timestamp | Random Data | CTR_HIGH |
|
||||
| --------- | ----------- | -------- |
|
||||
| 32 | 64 | 16 |
|
||||
|
|
@ -134,19 +221,38 @@ To combat replay attacks, a 32-bit timestamp shall be embedded into the cryptogr
|
|||
|
||||
!! In CTR mode, AES encryption is malleable. That is, an attacker can change the contents of the encrypted message without decrypting it. This means that recipients of AES-encrypted data must not trust that the data is authentic. Users who require that received messages are proven to be exactly as-sent by the sender should add application-layer authentication, such as HMAC. In the future, use of a different mode, such as Galois/Counter Mode, could alleviate this issue.
|
||||
|
||||
##### Channel Access Number (CAN)
|
||||
|
||||
##### LSF META
|
||||
The Channel Access Number (CAN) is a four bit code that may be used to filter received audio, text, and GNSS data. A receiver may optionally allow reception from sources only if their transmitted CAN value matches the receiver's own specified CAN value.
|
||||
|
||||
#### Stream Frames
|
||||
|
||||
[Stream Frames](../data-link-layer#stream-frames) will contain the appropriate LICH data (described above). The Stream Contents will include the incrementing 16-bit Frame Number, and 128 bits of Codec 2 data (unencrypted or encrypted).
|
||||
|
||||
#### References / Acknowledgements
|
||||
|
||||
- [Jonathan Naylor (G4KLX) Source/Destination and META fields in the M17 Voice Application](https://discourse.m17project.org/t/callsigns-and-extended-use-of-the-meta-field-in-m17/103)
|
||||
- [Jonathan Naylor (G4KLX) GPS Encoding in META field](https://discourse.m17project.org/t/the-format-of-the-m17-gps-data/107/3)
|
||||
- [Jonathan Naylor (G4KLX) Multi-Mode Digital Voice Modem (MMVDM)](https://github.com/g4klx/MMDVM)
|
||||
|
||||
The LSF META field is defined by the specific application.
|
||||
|
||||
### Packet Application
|
||||
|
||||
**!!! Incomplete !!! This is work in progress.**
|
||||
|
||||
A single packet of up to 798 bytes of data may be sent in one transmission.
|
||||
|
||||
Packets are sent using [Packet Mode](../data-link-layer#packet-mode).
|
||||
|
||||
A Stream Mode Transmission begins with an [LSF](../04.data-link-layer/#link-setup-frame-lsf).
|
||||
|
||||
Packet superframes are composed of a 1..n byte data type specifier, 0..797 bytes of payload data. The data type specifier is encoded in the same way as UTF-8. It provides efficient coding of common data types. And it can be extended to include a very large number of distinct packet data type codes.
|
||||
|
||||
The data type specifier can also be used as a protocol specifier. For example, the following protocol identifers are reserved in the M17 packet spec:
|
||||
|
||||
##### Reserved Protocols
|
||||
|
||||
<center><span style="font-weight:bold">Table 24</span> Packet protocol identifiers</center>
|
||||
Identifier | Protocol
|
||||
---------- | --------
|
||||
0x00 | RAW
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@ M17 uses 48-bit (6-byte) addresses. Callsigns and special purpose addresses are
|
|||
|
||||
### Address Scheme
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> M17 Addresses</center>
|
||||
Address Range (base-16) | Category | Number of Addresses | Remarks
|
||||
------------- | -------- | ------------------- | -------
|
||||
0x000000000000 | RESERVED | 1 | For future use
|
||||
|
|
@ -25,6 +26,7 @@ Address Range (base-16) | Category | Number of Addresses | Remarks
|
|||
|
||||
9 characters from an alphabet of 40 possible characters can be encoded into 48 bits (6 bytes). The base-40 alphabet is:
|
||||
|
||||
<center><span style="font-weight:bold">Table 2</span> M17 Callsign Alphabet</center>
|
||||
Value (base-10) | Character | Note
|
||||
--------------- | --------- | ----
|
||||
0 | ' ' | A space, ASCII 32 (0x20). Invalid characters will be replaced with this.
|
||||
|
|
@ -124,6 +126,7 @@ Secondary operating suffixes are often added to callsign to indicate temporary c
|
|||
|
||||
The minimum number of allowed callsign characters in the callsign alphabet is 37 ('A' through 'Z', '0' through '9', and '/'). The following table shows how many bytes are required to encoded a callsign using an alphabet size of 37.
|
||||
|
||||
<center><span style="font-weight:bold">Table 3</span> Storage required for number of callsign characters</center>
|
||||
Callsign Characters | Bits | Bytes
|
||||
------------------- | ---- | -----
|
||||
7 | $log_2(37^7)=36.47$ | 5
|
||||
|
|
@ -140,6 +143,7 @@ Of these, 9 characters into 6 bytes, or 12 charcters into 8 bytes are the most e
|
|||
|
||||
The following table shows how many bytes are required to encode a 9 character callsign using callsign alphabet sizes of 37 through 41.
|
||||
|
||||
<center><span style="font-weight:bold">Table 4</span> Storage required for alphabet size</center>
|
||||
Alphabet Size | Bits | Bytes
|
||||
------------- | ---- | -----
|
||||
37 | $log_2(37^9)=46.89$ | 6
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ taxonomy:
|
|||
- docs
|
||||
---
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> Randomizer values</center>
|
||||
Seq. number | Value | Seq. number | Value
|
||||
----------- | ----- | ----------- | -----
|
||||
00 | 0xD6 | 23 | 0x6E
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@ The convolutional code shall encode the input bit sequence after appending 4 tai
|
|||
|
||||
The output from the encoder must be read alternately.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 1</span> Convolutional encoder</center>
|
||||
|
||||
|
||||
### Issues to address...
|
||||
|
|
|
|||
|
|
@ -48,7 +48,8 @@ This is equivalent to 0xC75 in hexadecimal notation. Both the generating matrix
|
|||
\)
|
||||
|
||||
The output of the Golay encoder is shown in the table below.
|
||||
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> Golay encoder details</center>
|
||||
Field | Data | Check bits | Parity
|
||||
----- | ---- | ---------- | ------
|
||||
Position | 23..12 | 11..1 | 0 (LSB)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ taxonomy:
|
|||
|
||||
For interleaving a Quadratic Permutation Polynomial (QPP) is used. The polynomial \(\pi(x)=(45x+92x^2)\mod 368\) is used for a 368 bit interleaving pattern QPP.
|
||||
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> Interleaver mapping</center>
|
||||
input index | output index | input index | output index | input index | output index | input index | output index
|
||||
----------- | ------------ | ----------- | ------------ | ----------- | ------------ | ----------- | ------------
|
||||
0 | 0 | 92 | 92 | 184 | 184 | 276 | 276
|
||||
|
|
|
|||
|
|
@ -12,13 +12,13 @@ The PRBS uses the ITU standard PRBS9 polynomial : \(x^{9}+x^{5}+1\)
|
|||
This is the traditional form for a linear feedback shift register (LFSR) used
|
||||
to generate a psuedorandom binary sequence.
|
||||
|
||||
<center><span style="font-weight:bold">Figure X</span> Traditional form LFSR</center>
|
||||
<center><span style="font-weight:bold">Figure 1</span> Traditional form LFSR</center>
|
||||
|
||||
|
||||
However, the M17 LFSR is a slightly different. The M17 PRBS9 uses the
|
||||
generated bit as the output bit rather than the high-bit before the shift.
|
||||
|
||||
<center><span style="font-weight:bold">Figure X</span> M17 LFSR</center>
|
||||
<center><span style="font-weight:bold">Figure 2</span> M17 LFSR</center>
|
||||
|
||||
|
||||
This will result in the same sequence, just shifted by nine bits.
|
||||
|
|
@ -29,7 +29,7 @@ The reason for this is that it allows for easier synchronization. This is
|
|||
equivalent to a multiplicative scrambler (a self-synchronizing scrambler)
|
||||
fed with a stream of 0s.
|
||||
|
||||
<center><span style="font-weight:bold">Figure X</span> M17 PRBS9 Generator</center>
|
||||
<center><span style="font-weight:bold">Figure 3</span> M17 PRBS9 Generator</center>
|
||||
|
||||
|
||||
```
|
||||
|
|
@ -69,7 +69,7 @@ reset. The received bit is then also shifted into the LFSR state register.
|
|||
Once a sequence of eighteen (18) consecutive good bits are recovered (twice
|
||||
the length of the LFSR), the stream is considered syncronized.
|
||||
|
||||
<center><span style="font-weight:bold">Figure X</span> M17 PRBS9 Synchronization</center>
|
||||
<center><span style="font-weight:bold">Figure 4</span> M17 PRBS9 Synchronization</center>
|
||||
|
||||
|
||||
During synchronization, bits received and bit errors are not counted towards
|
||||
|
|
@ -107,7 +107,7 @@ After synchronization, BERT mode switches to error-counting mode, where the
|
|||
received bits are compared to a free-running PRBS9 generator. Each bit that
|
||||
does not match the output of the free-running LFSR is counted as a bit error.
|
||||
|
||||
<center><span style="font-weight:bold">Figure X</span> M17 PRBS9 Validation</center>
|
||||
<center><span style="font-weight:bold">Figure 5</span> M17 PRBS9 Validation</center>
|
||||
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -131,8 +131,9 @@ The streaming protocol is fairly trivial to describe. It is used by sending firs
|
|||
|
||||
#### Stream Format
|
||||
|
||||
##### M17 Kiss Stream Protocol
|
||||
##### M17 KISS Stream Protocol
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> KISS Stream</center>
|
||||
Frame Size | Contents
|
||||
---------- | --------
|
||||
30 | Link Setup Frame
|
||||
|
|
@ -153,6 +154,7 @@ The data frames contain a 6-byte (48-bit) LICH segment followed by a 20 byte pay
|
|||
|
||||
##### KISS Stream Data Frame
|
||||
|
||||
<center><span style="font-weight:bold">Table 2</span> KISS Stream Data</center>
|
||||
Frame Size | Contents
|
||||
---------- | --------
|
||||
6 | LICH (48 bits)
|
||||
|
|
|
|||
|
|
@ -43,6 +43,7 @@ The rate at which new symbols are generated. For M17, this is 4800 symbols per
|
|||
### File Extensions
|
||||
Multiple files are used when testing the different elements of the M17 protocol. File extensions (the three characters after a period in a complete file name) are defined to standardize formats and usage.
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> File extensions</center>
|
||||
Extension | Description | Data Format | Data Rate
|
||||
--------- | ----------- | ----------- | ---------
|
||||
aud | Mono audio | Signed 16-bit LE | 8000 samples per second
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue