V3 first draft #171
V3 first draft #171
Conversation
There was a problem hiding this comment.
This looks really good! In addition to the inline comments, here are some other thoughts:
- I didn't see any mention of versioning. We should mention that
0x0in the Payload Type/Contents subfield means it is a version 1/2 frame and that for compatibility clients should consider processing it as such. If they don't do that, there's no path for interoperability in the transition to V3. - I suggest moving the detailed data format definitions out of the LSF TYPE section. That raises the question of where to put them. I was thinking either a new subsection at the end of the Application section 3, or in an appendix.
- We should consider some discussion of how to handle multiple types of META contents. Should encryption-related types get priority? Should all META text pieces be sent sequentially or can other types be interleaved? How should repeaters/gateways decide when to insert ECS data? (The spec does mention that GNSS data should be sent only once every five seconds.)
- META Text in Packet Mode is weird, because it's only 13 bytes instead of 52. Should we just disallow it?
M17_spec.tex
Outdated
| \subsection{TYPE} | ||
| \paragraph{TYPE} | ||
|
|
||
| The 2-byte 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. |
There was a problem hiding this comment.
The Packet/Stream indicator bit no longer exists, correct? So this paragraph should probably change to reflect the new scheme.
M17_spec.tex
Outdated
| \multicolumn{4}{c}{\textit{Reserved}} & | ||
| \parbox{3em}{\centering Signed Stream} & | ||
| \multicolumn{3}{c}{Channel Access Number\ldots} \\ | ||
| \multicolumn{4}{c}{Payload Type} & |
There was a problem hiding this comment.
It might be cleared if we didn't reuse the word 'type' here, since we're already in the TYPE field. Maybe call this 'Payload Contents'?
| \caption{Stream LSF TYPE Layout} | ||
| \end{table} | ||
|
|
||
| \subsection{Payload} |
There was a problem hiding this comment.
It would be nice if the heading titles matched the text in the table above. So if we make the change I suggested above, this would become 'Payload Contents'.
M17_spec.tex
Outdated
| \hline[2px] | ||
| \end{tblr} | ||
| \caption{Packet/Stream Indicator} | ||
| \caption{Payload Type Subfield} |
There was a problem hiding this comment.
If we change Payload Type to Payload Contents above it should change here too.
M17_spec.tex
Outdated
| \hline[2px] | ||
| \end{tblr} | ||
| \caption{Data Type} | ||
| \caption{Encryption Type Subfield} |
There was a problem hiding this comment.
For consistency, change 'Encryption Type Subfield' to 'Encryption Subfield'.
M17_spec.tex
Outdated
| \subparagraph{GNSS Data} | ||
|
|
||
| Encryption subtype = $01_2$ | ||
| \paragraph{GNSS Data} |
There was a problem hiding this comment.
Again I think it might be clearer if the actual definitions of the formats for GNSS Data, Extended Callsign Data, and Text Data were moved elsewhere and just referred to here. If we add more formats later, this section will get longer and longer.
M17_spec.tex
Outdated
| \textbf{WARNING} 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 use an appropriate digital signature algorithm, as described below. | ||
| \end{quote} | ||
| If there is no data to be transferred, the Control Byte should be set to zero. | ||
|
|
There was a problem hiding this comment.
TShould there should be some reference to the AES Encryption IV here, pointing to where the actual data format is defined?
M17_spec.tex
Outdated
|
|
||
| \subsection{Channel Access Number} | ||
|
|
||
| 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. |
There was a problem hiding this comment.
I find 'received audio, text, and GNSS data' confusing here. For example, does CAN not apply to packet data? Assuming it's to filter all received data, perhaps change the end of the first sentence to 'may be used to filter received messages.'
There was a problem hiding this comment.
CAN should apply to all M17 modes, including Packet.
M17_spec.tex
Outdated
| \subsection{Packet Mode LSF TYPE} | ||
|
|
||
| The TYPE field only defines the stream/packet bit, called ``P/S'' in Table~\ref{tab:packet_lsf_type} and the Channel Access Number (CAN) bits. All other bits are reserved. | ||
| The Packet Mode TYPE is similar to the Stream Mode TYPE. It has the payload subfield set to \texttt{0xF} and the Channel Access Number (CAN) bits set at the user specified value. A single Meta field is supported in the Link Setup and could be GNSS data, Extened Callsign data or a one section Text data. Unlike Stream Mode, Packet Mode does not support encryption or digital signatures. |
There was a problem hiding this comment.
s/Extened/Extended/
The main difference is that Packet Mode doesn't have encryption, so consider phrasing it like this:
Unlike Stream Mode, Packet Mode does not support encryption or digital signatures. Therefore, bits 0-3 of byte 0 are reserved when the payload subfield is set to \texttt{0xF}. Each packet has a single Link Setup META field. Its contents can be any of those defined in the META Contents, except those that are encryption or digital signature related.
M17_spec.tex
Outdated
| 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. | ||
|
|
||
| FN field sets the most significant 16 bits of the counter, with the 32-bit least significant part holding the timestamp. The remaining 80-bit portion is filled with random data, re-generated per transmission. | ||
| 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. |
There was a problem hiding this comment.
- Weren't we considering making this a counter rather then a bitmap?
- How does this work in Packet Mode, where there can only be one LSF? Is the control byte always
0x11?
There was a problem hiding this comment.
I put the issue in to change the control byte configuration to a 4-bit len and 4-bit segment value. I don't know if that is in line for this exact revision of the document or not, it needn't be in the same PR, but could be. I guess that is up to the person working on it.
As far as using META Text in Packet Mode, I wouldn't suggest doing it, but I don't see a reason to outright forbid doing it either. Common sense would suggest just to send a Packet SMS message, or multiple if needed, instead of using the META field for that, but hey, maybe they want to stick their name in the Meta TEXT field and the message in the Packet Data Text, not my call to tell others how to use the tools, just to provide them.
There was a problem hiding this comment.
Counter - yes. Then, in the Packet mode: 0x00 for no data, otherwise limit the valid values to 0x11 (single chunk, first part).
|
Replace "GPS" with "GNSS": I think this is the only occurrence. |
|
|
You sure about that? |
Let me clarify: The table uses 0x3E and 0x3F instead of correct values of 0x2E and 0x2F. |
| 1 - 26 & '\texttt{A}' - '\texttt{Z}' & Letter & \texttt{0x41} - \texttt{0x5A} & Uppercase \\ | ||
| 27 - 36 & '\texttt{0}' - '\texttt{9}' & Digit & \texttt{0x30} - \texttt{0x39} & Decimal \\ | ||
| 37 & '\texttt{-}' & Hyphen & \texttt{0x2D} & Dash \\ | ||
| 38 & '\texttt{/}' & Slash & \texttt{0x3F} & Forward slash & \\ |
|
The following comment is partially a reply to this pull request, #161, and some discussion on Discord, but I'll try to keep it organized 😅 I have a few comments regarding the protocol (proposal) itself, but also to the documentation/presentation as well. The spec separates three layers: physical, data link, and application. The data link and application were already intertwined relatively hard in the 2.0.3 spec, but even more in this draft. The OSI model makes an explicit distinction between individual packets (layers up to 3), streams of data (layer 4), and protocols/applications using those generic streams. I feel like M17 tried to squish two layer 4 protocols into the "data link" layer, and heavily exposing/coupling that to the application layer. See the payload field for example. It simultaniously contains versioning for the protocol, information on which types of frames are to follow (packet or stream), even which "application" is transmitting, all while being dependent on the mode. It's logical where this comes from. Decoupling layers is less bit-efficient than smearing it together. However, I do think it's worth to at least explicitly discuss whether this is desirable for the protocol (which I personally think it's not). If breaking changes are already accepted, here are some (random) ideas regarding the protocol:
One possible suggestion could then look like:
Concretely this could mean transparantly passing the TYPE field to the transport layer. Subfields regarding encryption etc. are handled by this layer, and relevant metadata will be decoded and passed along. Regardless of which "application" is selected. Below I added a slightly modified TYPE layout that would facilitate the above within the currently allocated 16 bits. Note that I'm still a fan of adding 2 or so extra bits to the version field, even if that might break the nice byte layout for the LSF frame.
Regarding the presentation (for lack of a better word) of the draft/spec, linking to my Discord post is probably easier than fully repeating it here |
|
This latest update reinstates the ECD and defines when and how it is used. |
5 participants
A first draft of V3.0.0 and the new TYPE format, based on the discussion in Issue #161
Because there is a lot of text in the Application Layer:Type section of the Spec, I promoted some elements of the text so they would appear in the PDF Outline. If I didn't do this, users would be forced to use the list of figures to rapidly move to a desired point in the Spec.