M17_Project
/
M17_spec
mirror of https://github.com/M17-Project/M17_spec.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Second round of corrections/improvements

pull/171/head
Tom Early 2025-10-22 05:33:01 -07:00
parent 5bd3a842fc
commit cc6acbdec9
1 changed files with 74 additions and 104 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

178
M17_spec.tex
View File

@ -500,7 +500,7 @@ Multiple Stream or Packet Sync Bursts may be present during a Transmission, depe
The Link Setup Data (LSD) is a data structure that is common to both Stream and Packet Mode and contains information needed to establish a link. This data is a fundamental part of both RF data streams and and any kind of internet protocol packets. The Link Setup Data (LSD) is a data structure that is common to both Stream and Packet Mode and contains information needed to establish a link. This data is a fundamental part of both RF data streams and and any kind of internet protocol packets.
\begin{table}[H] \label{lsd} \begin{table}[H]
\centering \centering
\begin{tblr}{lcl} \begin{tblr}{lcl}
\hline \hline
@ -512,8 +512,8 @@ The Link Setup Data (LSD) is a data structure that is common to both Stream and
META & 112 bits & Meta data \\ META & 112 bits & Meta data \\
\hline[2pt] \hline[2pt]
\end{tblr} \end{tblr}
\caption{Link Setup Data Contents}
\label{tab:lsd_contents} \label{tab:lsd_contents}
\caption{Link Setup Data Contents}
\end{table} \end{table}
Total: 28 bytes, 224 Type 1 bits Total: 28 bytes, 224 Type 1 bits
@ -636,6 +636,7 @@ Following the LSF, one or more Stream Frames may be sent.
PREAMBLE & LSF SYNC BURST & LSF FRAME & STREAM SYNC BURST & STREAM FRAME & ••• & STREAM SYNC BURST & STREAM FRAME & EoT \\ PREAMBLE & LSF SYNC BURST & LSF FRAME & STREAM SYNC BURST & STREAM FRAME & ••• & STREAM SYNC BURST & STREAM FRAME & EoT \\
\end{tblr} \end{tblr}
\caption{Stream Mode} \caption{Stream Mode}
\label{tab:stream_mode}
\end{table} \end{table}
\subsection{Stream Frames} \subsection{Stream Frames}
@ -844,7 +845,7 @@ Stream Frames are grouped into Stream Superframes, which is the group of 6 frame
\label{fig:m17stream} \label{fig:m17stream}
\end{figure} \end{figure}
\section{Packet Mode} \section{Packet Mode} \label{sec:packet_mode}
In Packet Mode, a Single Packet with up to 823 bytes of Application Packet Data along with an appended two byte CRC may be sent over the physical layer during one Transmission. The total number of bytes ranges from 25 to 825 (33*25) bytes in 25 byte increments. In Packet Mode, a Single Packet with up to 823 bytes of Application Packet Data along with an appended two byte CRC may be sent over the physical layer during one Transmission. The total number of bytes ranges from 25 to 825 (33*25) bytes in 25 byte increments.
@ -877,6 +878,7 @@ Packet Mode shall always start with an LSF that has the LSF TYPE Packet/Stream i
PREAMBLE & LSF Sync Burst & LSF Frame & Packet Sync Burst & Packet Frame & ••• & Packet Sync Burst & Packet Frame & EoT \\ PREAMBLE & LSF Sync Burst & LSF Frame & Packet Sync Burst & Packet Frame & ••• & Packet Sync Burst & Packet Frame & EoT \\
\end{tblr} \end{tblr}
\caption{Packet Mode} \caption{Packet Mode}
\label{tab:packet_mode}
\end{table} \end{table}
\subsection{Packet Frames} \label{packet_frames} \subsection{Packet Frames} \label{packet_frames}
@ -1102,55 +1104,32 @@ Within the Physical Layer, the 368 Type 4 bits are randomized and combined with
\chapter{Application Layer} \chapter{Application Layer}
Implementation details for M17 clients, repeaters, and gateways ensure that an M17 Amateur Radio Voice Application is legal under all licensing regimes. Implementation details for M17 clients, repeaters, and gateways ensure that an M17 Amateur Radio Voice
Application is legal under all licensing regimes.
\section{Two Operation Modes} At the applications level, there are two M17 operating modes, Packet and Stream.
Stream Mode is primarily for digital voice using open source low bit rate speech codecs,
while Packet Mode is primarily for text messaging.
Both modes are intended to be used over the air by amateur radio operators worldwide.
Stream mode is primarily for an audio stream containing low bit rate speech encoded using the open source \href{http://rowetel.com/codec2.html}{Codec 2} codec. One of two different Codec 2 rates can be used in M17, and so Stream mode can be used in a voice-only mode using the higher bit rate codec, and voice+data mode using a lower bit rate codec which leave room for a parallel data stream, and a data only stream mode where arbitrarily large data objects can be streamed. Stream mode is intended to be used over the air by amateur radio operators worldwide. As illlustrated in Tables \ref{tab:stream_mode} and \ref{tab:packet_mode},
both modes begin with a Link Setup Frame followed by one or more data frames.
Packet mode is a one-shot method to send a small data packet over the air. It is intended primarily for text messaging, but other small binary objects can also be sent. Application data begin with the contents of the Link Setup Data, Table~\ref{tab:lsd_contents},
which contain four items that discribe not only the originator and the desired target of the M17
transmission, but also parameters that indicate how the contents of the M17 transmission is to be received.
Both Stream and Packet mode begins with an Link Setup Frame, LSF. \section{DST/SRC}
\begin{table}[H] The stream or packet mode data originator will set the destination (DST) and source (SRC) addresses. These addresses may be encoded amateur radio callsigns, or special identifiers. Once set by the originator of the transmssion, these addresses should not be changed by any application. See Address Encoding \autoref{address_encoding} for details on how up to 9 characters of text can be encoded into the 6-byte address value.
\centering
\begin{tblr}{lrl}
\hline
Field & Length & Description \\
\hline
DST & 48 bits & Destination address \\
SRC & 48 bits & Source address \\
TYPE & 16 bits & Information about the incoming data stream \\
META & 112 bits & Metadata field \\
CRC & 16 bits & Detailed in Section \ref{crc} \\
\hline[2px]
\end{tblr}
\caption{Link Setup Frame Contents}
\end{table}
\paragraph{DST/SRC} The destination address used by a originator may simply be a callsign or reflector designation for a point to point contact, or may be a special identifier, typically the BROADCAST address, \texttt{0xFFFFFFFF}. The source address is always the originator's callsign.
Destination (DST) and source (SRC) addresses may be encoded amateur radio callsigns, or special identifiers. See Address Encoding \autoref{address_encoding} for details on how up to 9 characters of text can be encoded into the 6-byte address value. \section{TYPE}
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 voice stream, an extended callsign data field will be encoded in the LSF META field. The 16-bit TYPE field contains all information needed to properly interpret the subsquent payload frames.
Please note that both Packet and Stream Mode use the same TYPE, however Packet Mode does not support either encryption
The destination address used by a client may simply be a callsign or reflector designation for a point to point contact, or may be a special identifier. Special identifiers are 6-byte addresses than can't be encoded in the standard way. For an explanation, see the Address Encoding \autoref{address_encoding}. or signing, so those fields should be set to zero.
\paragraph{TYPE}
The 2-byte TYPE field contains information about the frames to follow LSF. There are five subfields contained in TYPE that are used to specify not only the characterisitics of the Stream Mode payload, but also contents of the Meta data. Details of TYPE will be discussed later in this chapter.
\paragraph{META}
The 14-byte META field can and will contain a variety of data. In Stream mode, the META data will change as the stream evolves. The first meta field is available in the LSF frame but subsequent data/voice frames will potentially carry different META data in each superframe that follows. In Packet mode, one META field is available in the LSF frame. Different META data is described later in this chapter.
\paragraph{CRC}
The last 2 bytes of the 30-byte LSF is a 16-bit CRC as described in Section \ref{crc}.
\section{TYPE Field}
The TYPE field is 16 bits, 2 bytes, and contains all information need to properly interpret the stream frames. The first byte contains 3 subfields that characterize the payload data.
\begin{table}[H] \begin{table}[H]
\centering \centering
@ -1165,17 +1144,23 @@ The TYPE field is 16 bits, 2 bytes, and contains all information need to properl
\parbox{3em}{Signed} \\ \parbox{3em}{Signed} \\
\hline \hline
1 & 1 &
\multicolumn{4}{c}{Meta Data} & \multicolumn{4}{c}{Meta} &
\multicolumn{4}{c}{Channel Access Number} \\ \multicolumn{4}{c}{CAN} \\
\hline \hline
\end{NiceTabular} \end{NiceTabular}
\normalsize \normalsize
\caption{Stream LSF TYPE Layout} \caption{Stream LSF TYPE Layout}
\end{table} \end{table}
Allowed values for the five fields are described below.
\subsection{Payload} \subsection{Payload}
The first TYPE subfield is the 4 most significant bits of the first byte and specifies the contents of the 128-bit payload. The first TYPE subfield is the 4 most significant bits of the first byte and specifies the contents of the 128-bit payload.
Current implementations includes four payloads, two \href{http://rowetel.com/codec2.html}{Codec 2} codecs,
a higher bit rate codec, 3200 bps, operating in a voice-only mode, and a lower bit rate codec, 1600 bps, that has a
parallel data stream, also 1600 pbs, resulting in a voice+data mode. Stream Mode also supports a 3200 bps data-only mode.
Packet Mode makes up the final payload.
\begin{table}[H] \begin{table}[H]
\centering \centering
@ -1193,17 +1178,21 @@ The first TYPE subfield is the 4 most significant bits of the first byte and spe
\texttt{0xF} & Packet data \\ \texttt{0xF} & Packet data \\
\hline[2px] \hline[2px]
\end{tblr} \end{tblr}
\caption{Payload Subfield} \caption{Payload TYPE Subfield}
\end{table} \end{table}
The prior version of TYPE reserved the 4 most significant bits, so reserving \texttt{0x0} here provides a simple version detecting mechanism. Before version 3 of the specification, the 4 most significant bits of TYPE were always zero.
Because the 0x0 value is reserved, clients may assume that a zero value in that field indicates
a frame encoded according to the prior version.
Also note that protocol(s) for the data portion of Stream modes \texttt{0x1} and
\texttt{0x3} are yet to be developed.
\subsection{Encryption} \subsection{Encryption}
The next 3 bits of the first byte is a numeric value that specifies the encryption mode applied to The next 3 bits of the first byte is a numeric value that specifies the encryption mode applied to
the payload data. These encryptions methods are for Stream Mode only. Encryption is \textbf{optional}. the payload data. These encryptions methods are for Stream Mode only. Encryption is \textbf{optional}.
The use of it may be restricted within some radio services and countries, and should only be used if The use of it may be restricted within some radio services and countries, and should only be used if
legally permissible. legally permissible. Packet Mode does not support encryption and should be \texttt{0x0}.
\begin{table}[H] \begin{table}[H]
\centering \centering
@ -1223,41 +1212,49 @@ legally permissible.
\texttt{0x7} & Reserved \\ \texttt{0x7} & Reserved \\
\hline[2px] \hline[2px]
\end{tblr} \end{tblr}
\caption{Encryption Type Subfield} \caption{Encryption TYPE Subfield}
\end{table} \end{table}
For a complete discussion of the Scrambler and AES encryption method, see the Encryption \autoref{stream_encryption}. For a complete discussion of the Scrambler and AES encryption method, see the Encryption \autoref{stream_encryption}.
\subsection{Signed} \subsection{Signed}
The least significant bit of the first byte of TYPE specifies if the payload data is digitally signed. If this bit is set, then the stream is digitally signed. Only Stream Mode payload data can be signed. Details of signing and verifying a stream payload are in the Digital Signature \autoref{digital_signature}. The least significant bit of the first byte of TYPE specifies if the payload data is digitally signed.
If this bit is set, then the stream is digitally signed. Only Stream Mode payload data can be signed.
Details of signing and verifying a stream payload are in the Digital Signature \autoref{digital_signature}.
Packet Mode does not support signing so the sign bit should be clear.
\subsection{Meta} \subsection{Meta}
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 GNSS data which should be transmitted as soon as possible after the GNSS data is received from its source. The most significant 4 bits of the second byte of TYPE specifies the contents of META. There are five possible contents in META.
The most significant 4 bits of the second byte of the TYPE specifies the contents of the Meta data.
\begin{table}[H] \begin{table}[H]
\centering \centering
\begin{tblr}{lll} \begin{tblr}{llll}
\hline \hline
Value & LSF META data contents & Details \\ Value & LSF META Contents & Count & Details \\
\hline \hline
\texttt{0x0} & None & \\ \texttt{0x0} & None & & The META is nulled. \\
\texttt{0x1} & GNSS Position Data & GNSS Data \autoref{gnss_data} \\ \texttt{0x1} & GNSS Position Data & \texttt{1} & GNSS Data \autoref{gnss_data} \\
\texttt{0x2} & Extended Callsign Data & Extended Callsign \autoref{extended_callsign} \\ \texttt{0x2} & Extended Callsign Data & \texttt{} & Extended Callsign \autoref{extended_callsign} \\
\texttt{0x3} & Text Data & Text Data \autoref{text_data} \\ \texttt{0x3} & Text Data & \texttt{1..15} & Text Data \autoref{text_data} \\
\texttt{0x4..0xE} & Reserved & \\ \texttt{0x4..0xE} & Reserved & \\
\texttt{0xF} & AES Encryption IV & AES \autoref{aes} \\ \texttt{0xF} & AES Encryption IV & \texttt{1} & AES \autoref{aes} \\
\hline[2px] \hline[2px]
\end{tblr} \end{tblr}
\caption{Meta Type Subfield} \caption{Meta TYPE Subfield}
\label{tab:meta_type_subfield}
\end{table} \end{table}
\subsection{Channel Access Number} All META values use a single META array to carry data, except for Text Data, where up to 15 consecutive META arrays can be used to carry up to 195 bytes of Text Data. Of course because Packet Mode does not support encryption, it's value should never be \texttt{0xF}. Also, the only text data than can be supported would be a single block text, with a control byte of \texttt{0x11}.
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. \subsection{CAN}
The least significant 4 bits of the second byte of TYPE is the CAN (Channel Access Number) subfield, with possible values \texttt{0x0..0xF}, that may be used to filter received incoming Stream or Packet Mode data. A receiver may optionally allow reception from sources only if their its CAN value matches the receiver's own specified CAN value.
\section{META}
META, a 14 byte array is the final part of the LSD. Table~\ref{tab:meta_type_subfield} lists the different contents META can have. While Packet Mode can accomodate a single META array, Stream Mode can additionally have new META contents every 240 milliseconds (every superframe). It will be up to the sender to decide on priority if multiple META types are available to be sent. During an ongoing Stream META transmission, any TYPE of META may be retransmitted during a stream mode transmission. Retransmission of META data is not strictly required, but one reason to retransmit data is for the benefit of late listeners. With static data like Text or Extended Callsign data, repetition intervals could be on the order of 10 to 30 seconds. GNSS data might be done more often, especially if the GNSS station type is Mobile. In this case, GNSS data should be transmitted as soon as possible after the GNSS data is received from its source.
\section{Stream Frames} \section{Stream Frames}
@ -1265,40 +1262,13 @@ Stream Frames will contain chunked LSF contents (in the LICH field). The Stream
\section{Packet Mode} \section{Packet Mode}
\subsection{Packet Mode LSF TYPE} Some countries require that the source of a transmisson be accountable to the amatuer licence that created the RF. Because Packet Mode can only carry a single META array, it's important to recognize that over-the-air relays, such as repeaters might have to overwrite that META array with Extented Callsign data so that the transmitting station callsign is attached to the transmission. As an example, a portable radio might transmit Packet Mode data to a local repeater, setting the META to GNSS data. Of course, this transmission would be identifiable by the SRC field in the LSF of the packet. If the repeater was linked to an internet server, it could just relay the Packet Mode data to the server. However a duplex repeater would have to modify the over-the-air packet by overwriting the META array with Extended Callsign data before repeating it. The GNSS data would be available to the local listeners, but only via a repeater dashboard.
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.
\begin{table}[H]
\centering
\small
\begin{NiceTabular}{|W{c}{4em}|[tikz=very thick]W{c}{3em}|W{c}{3em}|W{c}{3em}|W{c}{3em}|W{c}{3em}|W{c}{3em}|W{c}{3em}|W{c}{3em}|}
\hline
\diagbox{Byte}{Bit} & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 \\
\Hline[tikz=very thick]
0 &
\multicolumn{4}{c}{Payload Type} &
\multicolumn{4}{c}{Reserved} \\
\hline
1 &
\multicolumn{4}{c}{Meta Data} &
\multicolumn{4}{c}{Channel Access Number} \\
\hline
\end{NiceTabular}
\caption{Packet LSF TYPE Layout}
\label{tab:packet_lsf_type}
\end{table}
\subsection{Packet Data}
A single packet of up to 823 bytes of data may be sent in one transmission. A single packet of up to 823 bytes of data may be sent in one transmission.
Packets are sent using Packet Mode.
Packets are composed of a 1..n byte data type specifier and up to $823-n$ bytes of payload data. The data type specifier is a variable-length encoding using the same format as UTF-8. The data type specifier must be between $0$ and $2^{21}-1$ which will occupy between 1 and 4 bytes when encoded. Values from 0 to 127 are identical to their encoded form. Packets are composed of a 1..n byte data type specifier and up to $823-n$ bytes of payload data. The data type specifier is a variable-length encoding using the same format as UTF-8. The data type specifier must be between $0$ and $2^{21}-1$ which will occupy between 1 and 4 bytes when encoded. Values from 0 to 127 are identical to their encoded form.
The data type specifier can also be used as a protocol specifier. Table~\ref{tab:reserved_packet_protocols} lists the reserved protocol identifiers. The data type specifier can also be used as a protocol specifier. Table~\ref{tab:reserved_packet_protocols} lists the assigned protocol identifiers.
\begin{table}[H] \begin{table}[H]
\centering \centering
@ -2081,10 +2051,6 @@ FN field sets the most significant 16 bits of the counter, with the 32-bit least
\label{tab:aes_counter} \label{tab:aes_counter}
\end{table} \end{table}
\begin{quote}
\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}
\chapter{Digital Signature} \label{digital_signature}. \chapter{Digital Signature} \label{digital_signature}.
M17 protocol provides a stream authentication method through Elliptic Curve Digital Signature Algorithm (ECDSA). The curve used is $secp256r1$. Signature availability is signalled with a specific bit in the TYPE field. Signature use reduces the maximum length of the stream by 4 frames. M17 protocol provides a stream authentication method through Elliptic Curve Digital Signature Algorithm (ECDSA). The curve used is $secp256r1$. Signature availability is signalled with a specific bit in the TYPE field. Signature use reduces the maximum length of the stream by 4 frames.
@ -2119,7 +2085,7 @@ At the receiver-side, the 512-bit signature is retrieved from the last 4 frames'
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. 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. 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 GNSS receiver.
The GNSS data includes eight numeric values using from $3$ bits to $24$ bits. The two largest $24$ bit values are signed, two's complement values. The other six are unsigned values. All numeric fields are in order from most significant to least significant bit. There is also one $4$ bit validity field that used to indicate which numeric fields are valid. The GNSS data includes eight numeric values using from $3$ bits to $24$ bits. The two largest $24$ bit values are signed, two's complement values. The other six are unsigned values. All numeric fields are in order from most significant to least significant bit. There is also one $4$ bit validity field that used to indicate which numeric fields are valid.
@ -2208,9 +2174,9 @@ Finally, the remaining $4$ bits of the thirteenth byte and the fourteenth byte a
\chapter{Extended Callsign Data} \label{extended_callsign} \chapter{Extended Callsign Data} \label{extended_callsign}
This is only transmitted from repeaters/gateways and not from clients, who only receive and display this data. This is only transmitted from a duplex repeater 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 These fields should not appear over M17 Internet links as they should only be used over the air from a
repeater/gateway. repeater.
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 which takes six bytes to encode a nine character callsign. Any unused space in the META field contains \texttt{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 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 which takes six bytes to encode a nine character callsign. Any unused space in the META field contains \texttt{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.
@ -2240,13 +2206,17 @@ It is not expected that the data in the extra callsign fields change during the
The first byte of the Text Data is a Control Byte. To maintain backward compatibility, a Control Byte of \texttt{0x00} indicates that no Text Data is included. The first byte of the Text Data is a Control Byte. To maintain backward compatibility, a Control Byte of \texttt{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 null characters to fill any unused space at the end of the last used Text Data block. Up to fifteen Text Data blocks compose a complete message with a maximum length of 195 bytes. Each block may contain up to 13 bytes of UTF-8 encoded text, and is padded with null 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 Control Byte is split into two 4-bit fields. The most significant four bits is the number of block META blocks required for a complete message. Possible values are \texttt{1..15}.
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. The least significant four bits indicate which of the Text Data blocks this text corresponds to. Possible values are \texttt{0..15}. In a 15 block message, the first block would have a control byte of \texttt{0xF1}, and the last block would have \texttt{0xFF}.
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. The last block may or may not have null characters at the end of the block, otherwise, there should be no null characters interspersed in the Text Data. The text data should not contain any control characters, except for perhaps tab and newline characters, however, text data senders should expect that receivers might display the message in a limited space by adding line breaks to limit the width of the display.
It is up to the receiver to make sure all blocks in the message are received as well as 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.
For Stream Mode, messages that are 13 bytes or less can be transmitted in one superframe, 240ms. A 15 block message will take 3.6 seconds. For Packet Mode, Text Data is limited to 13 bytes, and will have a control byte of \texttt{0xF1}.
If there is no data to be transferred, the Control Byte should be set to zero. If there is no data to be transferred, the Control Byte should be set to zero.