= Hamnet70: IP-based networking in the 70 cm amateur radio band
Thomas Kolb DL5TKL
0.1, 2024-04-25
:toc:
:stem:
:webfonts!:

// SPDX-License-Identifier: CC-BY-SA-4.0
// List of contributors is at the end of the document.

== Introduction

https://git.tkolb.de/amateurfunk/hamnet70[Hamnet70] intends to provide a network system in the 70 cm amateur radio band that can transfer Internet Protocol (IP) packets at a high speed.
The protocols defined here are inspired by the Packet Radio network and Bluetooth Low Energy.

The protocols are designed primarily for centralized infrastructure as they were common in the Packet Radio network.
Few base stations (_digipeaters_) provide wide coverage from exposed locations.
Every user can connect to the base station, but they can not necessarily receive each other’s transmissions.
Therefore, a star topology network where the base station coordinates transmissions is the primary goal.

== General Notes

All data is transmitted in network byte order (big endian = MSB first).

== Layer 1: Physical Layer

The Physical Layer (PHY) is responsible for encoding a Layer 2 packet such that
it can be transmitted over the air. Therefore, it encodes and modulates the
data, and adds a fixed preamble to aid synchronization to the signal.
Additionally, a mechanism is defined that allows to group packets in a „burst“,
which reduces overhead.

[#phy_packet_format]
=== PHY Packet Format

A packet encoded by the PHY consists of the following blocks:

. Preamble: a fixed symbol sequence that the receiver can use to determine the start time, frequency and phase offset of the following data.
. PHY header: contains information about the packet length and modulation/coding scheme.
. Data symbols: encoded and modulated data.

==== Preamble

The preamble is a fixed 63-bit sequence generated from a linear feedback shift register with 6 bits and the generator polynomial stem:[x^6 + x^5 + 1].

The generated sequence is: `111000101111001010001100001000001111110101011001101110110100100`.

This sequence is modulated using BPSK.

The preamble is prefixed to each transmitted packet, even inside a burst.

==== PHY Header

The PHY header describes how the following data symbols should be interpreted. It consists of the following fields:

. Modulation/code combination ID (MODCOD): 4 bit
. Number of data symbols: 12 bit

Therefore the PHY header has as size of 16 bit.

For additional protection, the header is encoded using a [12,8] Hamming code, which can reliably correct single-bit errors and detect double-bit errors in every block of eight bits.

The PHY header is always modulated using QPSK.

===== Modulation/code combinations

The following table lists all supported combinations of modulation and forward error correction for the packet data.

[options="header"]
.Supported packet data modulation/code combinations (MODCODs)
|===
| ID (binary) | Modulation | Channel Code

| 0000
| 16-QAM
| Punctured convolutional code: stem:[r=3/4], stem:[K=7]

| 0001
| QPSK
| Punctured convolutional code: stem:[r=3/4], stem:[K=7]

| _others_
| _reserved_
| _reserved_
|===

==== Data Whitening

The IP packets transferred by Hamnet70 may contain long sequences of identical bytes (think of the zeros in the middle of IPv6 addresses), which make it hard to keep the system synchronized. To prevent the transmission of many identical symbols in a row, the data is whitened using a pseudo-random sequence.

Here, a 9-bit linear feedback shift register (LFSR) according to the CCITT specification is used to generate the pseudo-random sequence. The generator polynomial is stem:[x^9 + x^5 + 1]. The data is whitened by XORing data bytes with the _whitening key_ generated from the LFSR.

The whitening key is generated by taking the LSB of the LFSR state, and shifting it into an 8-bit register from the right. Then the LFSR is advanced and the process is repeated. Every 8 repetitions the contents of the 8-bit register are XORed with a data byte to calculate the whitened data.

To remove the whitening, the same procedure is applied to the whitened data at the receiver side. XORing with the same sequence results in the original data.

Whitening is only applied to the layer 2 packet data, but not the PHY header.

==== Data Modulation

The first data symbol follows directly after the last symbol of the PHY header. The data is encoded and modulated using the scheme defined in the PHY header’s MODCOD field. The number of symbols resulting from the encoding and modulation process is stored in the PHY header as well.

=== Burst Transmission

Packets are transmitted in bursts which can combine multiple packets in a contiguous transmission.

A burst consists of the following elements:

. Ramp-up sequence
. Pre-packet idle sequence (optional)
. One or more packets as defined in <<phy_packet_format>>
. Ramp-down sequence

The ramp-up, ramp-down and idle sequences consist of alternating +1/-1 BPSK symbols.

During ramp-up, their amplitude stem:[A_u(k)] is scaled up across stem:[L_u] symbols, following the curve stem:[A_u(k) = sin(π/2 * k / L_u)]. Ramp-down follows a similar sinusoidal for stem:[L_d] symbols: stem:[A_d(k) = cos(π/2 * k / L_d)]. The purpose of these sequences is to avoid splatter while turning on and off the transmitted signal.

During the pre-packet idle sequence, the alternating BPSK symbols are continued with constant amplitude 1.0. This sequence may help synchronizers acquire the signal better (especially the gain and timing regulation can benefit), but is not needed if they are fast enough. If and how this part is used is still to be determined.

Each packet in a burst includes a preamble. Packets are directly concatenated, i.e. after the last data symbol follows the first preamble symbol.

=== Pulse Forming

Pulse forming is applied to limit the bandwidth of the transmitted signal and to reduce inter-symbol interference at the receiver.

This system uses Root Raised Cosine (RRC) filters with a roll-off factor of stem:[alpha=0.2]. Therefore the bandwidth is 1.2 times the symbol rate.

The filter is applied to the whole symbol sequence of the burst. The same filter must be applied at the receiver to minimize inter-symbol interference.

== Layer 2: Link Layer

The Hamnet70 link layer is designed to ensure reliable communication between a central station (digipeater) and several clients, while making efficient use of the available airtime. To accomplish this, it uses several technologies, including variable-length addressing and automatic repetition of packets that could not be decoded.

=== Frame Structure

The link layer frame consist of three elements, as follows:

. The <<_link_layer_header,link layer header>>
. A variable amount of data, depending on the packet type
. CRC16 of all previous bytes, including the link layer header

The CRC16 is calculated using the generator polynomial stem:[x^15 + x^2 + 1].

=== Node Addresses

Node addresses use the https://github.com/arngll/arnce-spec/blob/main/n6drc-arnce.md#introduction[HAM-64 address format]. This format allows to encode callsigns of up to 12 characters in a number of 16, 32, 48 or 64 bits. Additionally, it allows to replace the full version of an address with a temporary short address with only 16 bits that is used during a connection. Multicast and broadcast addresses are also specified.

=== Link Layer Header

Each layer 2 packet contains a header that identifies how the message should be interpreted. It is of variable length and composed as follows:

[cols="2,1,5", options="header"]
.Link layer header layout
|===
| Field | Length | Description

| Message type
| 3 bit
| The type of the message. See below for a list of values.

| TX request
| 1 bit
| After this message, the burst ends and the destination may transmit.

| Source address length
| 2 bit
| Length of the source address.

| Destination address length
| 2 bit
| Length of the destination address.

| TX sequence number
| 4 bit
| Sequence number of the currently transmitted packet.

| RX sequence number
| 4 bit
| Sequence number of the packet expected next.

| Source address
| 16, 32, 48 or 64 bit
| HAM-64 address identifying the sending station.

| Destination address length
| 16, 32, 48 or 64 bit
| HAM-64 address identifying the target station.
|===

The total Link Layer Header length is therefore at least 6 byte and at most 18 byte.

[cols="1,2,5", options="header"]
.Message types
|===
| Value | Name | Description

| `000`
| Data frame
| A regular data packet (inside a connection).

| `001`
| Connection management
| Includes functions such as establishing (or denying) new connections or closing open connections.

| `010`
| Empty frame
| Used for simple acknowledgements or transmission requests. This frame itself is not acknowledged.

| `100`
| Connectionless frame
| A data packet that is sent outside of a connection.

| _other_
| _reserved_
| All values not explicitly listed are reserved and shall be ignored by receivers.

|===

The length of the source and destination addresses is encoded as follows: `00` = 16 bit, `01` = 32 bit, `10` = 48 bit, `11` = 64 bit.

=== Automatic Packet Repetition

Lost packets are automatically repeated in Hamnet70. As the system is also designed for high throughput, it uses the Go-Back-N algorithm to handle this. The algorithm is described in this section.

Both the digipeater and the client send two sequence numbers with each packet.

The _TX sequence number_ is the number of the current packet. It uniquely identifies that packet at the time it is transmitted. The _TX sequence number_ is incremented (with overflow) with each new packet that is sent.

The _RX sequence number_ is the packet number the sending station expects to see next from the other side. It is incremented when a packet with this expected sequence number is decoded successfully. Received packets with other sequence numbers than the expected one must be dropped.

Example: The two stations A and B just connected and expect to see sequence number 0 from each other. Station A transmits a burst with three packets: P0, P1, P2. Station B decodes packet P0 and increases the expected number to 1. P1 is not decoded due to noise and therefore lost. P2 is again decoded, but is dropped because its sequence number is 2 and not the expected 1. In its transmission cycle, station B tells station A that it expects P1 next. Station A therefore _goes back to_ P1 in its transmission queue and starts transmitting all packets after P1 again.

If a station does not have anything to transmit, it shall transmit an _Empty Frame_ to acknowledge the data from the other side.

As the sequence numbers in Hamnet70 have 4 bits, up to 15 packets can be transmitted in a burst before the numbers become ambiguous.

Due to the long possible bursts, this system can achieve high throughput if there is low packet loss. However, it can also become very slow if many packets are lost because all packets after the first error have to be repeated. Therefore it might be a good idea to adjust the burst length depending on the packet loss and send smaller bursts if only few packets go through.

=== Frame Definitions

==== Data Frame

Data Frames carry all higher-layer data in a connection.
Each Data Frame transfers a single layer-3 packet.

The layer 2 header of Data Frames is filled as follows:

- Message Type: `000` (Data Frame)
- TX Request: `1` if this is the last packet in the burst, `0` otherwise
- Source Address: the transmitter’s HAM-64 address
- Destination Address: the target station’s HAM-64 address
- TX sequence number: as required by Go-Back-N
- RX sequence number: as required by Go-Back-N

To identify how the encoded packet should be handled, the layer 3 protocol is encoded in the first byte of the layer 2 payload.
The full layer 2 payload therefore is composed as follows:

- Layer 3 protocol ID (1 Byte)
- Layer 3 packet data (variable length)

So far, the following protocols are defined and supported:

[cols="2,1,1", options="header"]
.Layer 3 protocol identifiers. EtherType is given as reference.
|===
| Protocol | Hamnet70 ID | EtherType

| IPv6
| `0x00`
| `0x86DD`

| IPv4
| `0x10`
| `0x0800`

| _undefined/auto_
| `0xFF`
| -

3+|_All other values are reserved._

|===

==== Empty Frame

The Empty Frame does not contain any data and therefore only consists of the header and the CRC.

It is used in two cases:

- The digipeater requests a transmission from a client, but does not have any data or management frames queued.
  In this case the _TX Request_ field is set to 1.
- A station acknowledges frames from another station when it does not have any data to transmit.
  Here, _TX Request_ is set to 0.

Empty Frames are not acknowledged.
They therefore do not have a _TX sequence number_; this field is reserved and must be set to zero.

The _RX sequence number_ and all other header fields are used as usual.

==== Connection Management

Connection Management Frames control the Layer 2 connection between a client and the digipeater.
They are especially important for connect and disconnect procedures.

Connection Management Frames have at least one byte in the data field: the type of the management packet.
The following types are defined:

[cols="1,2,5", options="header"]
.Connection Management Types
|===
|Type Indicator
|Sent by
|Description

|`0x00`
|Digipeater
|Beacon

|`0x01`
|Client
|Connection Request

|`0x02`
|Digipeater
|Connection Parameters

|`0x03`
|Digipeater
|Connection Reset

|`0x04`
|Digipeater
|Disconnect Request

|`0x05`
|Client
|Disconnect
|===

===== Beacons

Beacons are sent periodically by the digipeater to show it’s presence to potential new clients.

The layer 2 header is filled as follows:

- Message Type: `001` (Connection Management)
- TX Request: `1`
- Source Address: the digipeater’s HAM-64 address
- Destination Address: the HAM-64 broadcast address
- TX sequence number: reserved, always 0
- RX sequence number: reserved, always 0

The message contains exactly 1 data byte: `0x00` to indicate that this is a Beacon packet.

A Beacon packet shall always be sent as the last or only packet in a burst.
After a Beacon is sent by the digipeater it listens for a short time for Connection Requests from new clients.
A new client that intends to connect shall send the Connection Request as soon as possible after the beacon transmission ends.

===== Connection Request

A Connection Request is sent by a client that intends to connect to a digipeater.

The layer 2 header is filled as follows:

- Message Type: `001` (Connection Management)
- TX Request: `1`
- Source Address: the new client’s HAM-64 address
- Destination Address: the digipeater’s HAM-64 address
- TX sequence number: reserved, always 0
- RX sequence number: reserved, always 0

The message contains exactly 1 data byte: `0x01` to indicate that this is a Connection Request packet.

A Connection Request is always a response to a Beacon packet.
It shall be the only packet in a burst.

When the digipeater receives a Connection Request it has two options for a response:

. Accept the connection by sending a Connection Parameters packet to the client in the next burst.
. Reject the connection by sending a Connection Reset packet to the client in the next burst.

===== Connection Parameters

The Connection Parameters packet has two functions: it indicates to a client that its Connection Request was accepted and tells it how to configure its network stack.
This is the first packet in the regular Go-back-N data flow.

The layer 2 header is filled as follows:

- Message Type: `001` (Connection Management)
- TX Request: `1`
- Source Address: the digipeater’s HAM-64 address
- Destination Address: the new client’s HAM-64 address
- TX sequence number: 0 (the first packet)
- RX sequence number: 0 (no packets received yet)

The type indicator is `0x02`.

After the type indicator follow one or more configuration blocks.
Each block consists of three data fields:

. Configuration Type: 1 byte
. Configuration Data Length: 1 byte
. Configuration data: variable number of bytes as indicated by Configuration Data Length

The following Configuration Types are defined:

[cols="1,1,5", options="header"]
.Configuration Types
|===
|Type Indicator
|Length
|Description

|`0x00`
|16 Byte
|IPv6 address

|`0x01`
|16 Byte
|IPv6 gateway

|`0x02`
|16 Byte
|IPv6 DNS server (may appear multiple times)

|`0x03` - `0x07`
|-
|_reserved_

|`0x08`
|4 Byte
|IPv4 address

|`0x09`
|4 Byte
|IPv4 gateway

|`0x0A`
|4 Byte
|IPv4 DNS server (may appear multiple times)

|`0x0B` - `0xFF`
|-
|_reserved_

|===

If the client receives an unknown Configuration Type the corresponding block shall be skipped.
The remaining blocks shall be parsed as usual.

===== Connection Reset

A Connection Reset is set by the digipeater if it receives unexpected packets from stations that are not connected.

The layer 2 header is filled as follows:

- Message Type: `001` (Connection Management)
- TX Request: `1` if this is the last packet in the burst, `0` otherwise
- Source Address: the digipeater’s HAM-64 address
- Destination Address: the new client’s HAM-64 address
- TX sequence number: reserved, always 0
- RX sequence number: reserved, always 0

The message contains exactly 1 data byte: `0x03` to indicate that this is a Connection Reset packet.

A Connection Request is sent in a regular burst and can be in any position.

This message means that the digipeater does not have any information about a connection with the addressed client.
Therefore, when a client receives a Connection Reset, it shall drop its complete connection state and start a new connection procedure if desired.

===== Disconnect Request

A Disconnect Request is set by the digipeater when it wants to orderly shut down a client connection.
It is the last packet that the digipeater sends in a connection.

The layer 2 header is filled as follows:

- Message Type: `001` (Connection Management)
- TX Request: `1` if this is the last packet in the burst, `0` otherwise
- Source Address: the digipeater’s HAM-64 address
- Destination Address: the client’s HAM-64 address
- TX sequence number: as required by Go-Back-N
- RX sequence number: as required by Go-Back-N

The message contains exactly 1 data byte: `0x04` to indicate that this is a Disconnect Request packet.

A Disconnect Request is sent in a regular burst and can be in any position.
The sequence numbers are sent and handled the same way as in regular connection packets.

When a client receives a Disconnect Request, it may transmit the remainder of its current queue, but must not queue new data packets.
After the last packet is transmitted, the client shall send a Disconnect packet, which confirms the end of the connection.

The digipeater must keep the connection state in memory until either the Disconnect packet is received from the client or the connection times out.

===== Disconnect

A Disconnect packet is sent by the client to terminate the connection.
It is the last packet in a connection and is not confirmed by the digipeater.

The layer 2 header is filled as follows:

- Message Type: `001` (Connection Management)
- TX Request: `0`
- Source Address: the client’s HAM-64 address
- Destination Address: the digipeater’s HAM-64 address
- TX sequence number: as required by Go-Back-N
- RX sequence number: as required by Go-Back-N

The message contains exactly 1 data byte: `0x05` to indicate that this is a Disconnect packet.

A Disconnect is sent always as the final packet of a burst.
The sequence numbers are sent and handled the same way as in regular connection packets.

When the digipeater receives a disconnect packet in the regular packet flow (i.e. no previous packets are lost), it will immediately drop the connection state and not call this client again.
Therefore, if the client wants to ensure that all previous packets are transmitted, it must wait until the digipeater confirms that by sending the corresponding RX sequence number before sending the Disconnect packet.

==== Connectionless Frame

Connectionless Frames are used to transfer packets between unconnected notes.
They can be used to implement custom protocols (similar to APRS, which is implemented on top of AX.25).

The layer 2 header of Connectionless Frames is filled as follows:

- Message Type: `100` (Connectionless Frame)
- TX Request: `1` if this is the last packet in the burst, `0` otherwise
- Source Address: the transmitter’s HAM-64 address
- Destination Address: the target station’s HAM-64 address
- TX sequence number: user-defined
- RX sequence number: user-defined

The sequence numbers can be used in any way that is useful for the custom protocol.

It is required that the first byte of each Connectionless Frame identify the protocol being used.
Protocol numbers are centrally assigned and are listed below.
Some protocol numbers are reserved for experimentation and development and can be self-assigned temporarily.

[cols="1,3", options="header"]
.Connectionless Frame protocol IDs
|===
|Protocol IDs
|Description

|`0x00 .. 0xF7`
|_reserved_

|`0xF8 .. 0xFF`
|Available for experimentation and developmentfootnote:[If you are developing a new protocol, you can freely pick a number from this range. Please check which temporary IDs are already used around your location and pick a free one. When your protocol reaches a sufficiently stable state, please request an official ID assignment].
|===

=== Message Sequence Charts

==== Connection Establishment

[msc,format=svg,svg-type=interactive, scale=1.4]
.Connection establishment
....
msc {
	digi [label="Digipeater"],
	client [label="Client"];

	digi -> client [label="Beacon (Broadcast)"];
	digi -> client [label="Beacon (Broadcast)"];

	client box client [label="Decides to connect"];
	...;

	digi -> client [label="Beacon (Broadcast)"];
	digi <- client [label="Connection Request"];

	--- [label="Alternative 1: Connection is accepted"];
	digi -> client [label="Connection Parameters"];
	digi <- client [label="Connection Acknowledgement"];
	digi box client [label="Connection established"];

	--- [label="Alternative 2: Connection is rejected"];
	digi -> client [label="Connection Reset"];
}
....

==== Communication during a Connection

[msc,format=svg,svg-type=interactive, scale=1.4]
.In-connection communication
....
msc {
	digi [label="Digipeater"],
	client [label="Client"];

	--- [label="Connection established"];
	digi => client [label="Up to 14 packets without Transmission Request"];
	digi -> client [label="Packet with Transmission Request"];

	digi box digi [label="Start timeout timer"];

	--- [label="Alternative 1: Normal reply"];

	digi <= client [label="Up to 14 packets without Transmission Request"];
	digi <- client [label="Packet with Transmission Request"];

	--- [label="Alternative 2: Partial reply"];

	digi <= client [label="Up to 14 packets without Transmission Request"];
	digi x- client [label="Packet with Transmission Request"];
	...;
	digi rbox digi [label="Timeout expired"];

	--- [label="Alternative 3: No reply"];

	digi x- client [label="Packets from client"];
	...;
	digi rbox digi [label="Timeout expired"];

	--- [label="Finally"];

	digi box digi [label="Query next client"];
}
....

==== Connection Shutdown

===== Client-initiated

[msc,format=svg,svg-type=interactive, scale=1.4]
.Client-initiated shutdown
....
msc {
	digi [label="Digipeater"],
	client [label="Client"];

	--- [label="Connection established"];
	client box client [label="Decides to disconnect"];
	...;
	digi -> client [label="Transmission request"];
	digi <- client [label="Disconnect"];

	--- [label="Connection closed"];
}
....

===== Digipeater-initiated

[msc,format=svg,svg-type=interactive, scale=1.4]
.Digipeater-initiated shutdown
....
msc {
	digi [label="Digipeater"],
	client [label="Client"];

	--- [label="Connection established"];
	digi box digi [label="Decides to disconnect Client"];

	digi -> client [label="Disconnect request"];
	digi <- client [label="Disconnect"];

	--- [label="Connection closed"];
}
....

=== State Diagrams

This section documents state diagrams for the digipeater and the clients.
They are only informational; different implementations are possible and allowed as long as the procedures defined by the <<_message_sequence_charts,message sequence charts>> are obeyed.
However, the state diagrams shown here reflect the reference implementation.

==== Connection State Diagram

[graphviz,format=svg,svg-type=interactive,scale=1.0]
.Connection state diagram
....
digraph connection {
	uninitd [label="Uninitialized"];
	connecting [label="Connecting"];
	wait_client [label="Wait for\nclient"];
	estab [label="Two-way communication\nestablished"];
	closed [label="Closed"];

	uninitd -> connecting [label="Connection request\nsent [client]"];
	uninitd -> wait_client [label="Connection request\nreceived [digipeater]"];

	connecting -> estab [label="Connection\nacknowledgement sent"];
	wait_client -> estab [label="Connection\nacknowledged"];

	connecting -> closed [label="Timeout"];
	wait_client -> closed [label="Timeout"];

	estab -> closed [label="Disconnect/Timeout"];
	closed -> uninitd [label="State erased"];
}
....

==== Digipeater Connection Multiplexing

[graphviz,layout=neato,format=svg,svg-type=interactive,scale=1.0]
.Handling of multiple connections at the digipeater
....
digraph multiclient {
	overlap=false;

	idle [label="Idle"];
	send_beacon [label="Send Beacon"];
	accept_new [label="Check for\nnew clients"];
	check_conn [label="Check connection timers"];
	send_to_client [label="Send queued packets\nto client"];
	receive_from_client [label="Receive packets\nfrom client"];
	check_timeout [label="Check connection\ntimeout"];
	reset_timeout [label="Reset connection\ntimeout"];
	close_conn [label="Close\nconnection"];

	idle -> send_beacon [label="Beacon timeout\nexpired"];
	send_beacon -> accept_new;
	accept_new -> idle;

	idle -> check_conn [label="Any contact\ntimer expired"];
	check_conn -> send_to_client [label="Contact timer\nexpired"];
	send_to_client -> receive_from_client;
	receive_from_client -> reset_timeout [label="Packets received"];
	reset_timeout -> check_conn;

	receive_from_client -> check_timeout [label="Nothing received"];
	check_timeout -> check_conn [label="No timeout yet"];
	check_timeout -> close_conn [label="Timed out"];
	close_conn -> check_conn;

	check_conn -> idle [label="All expired\nconnections handled"];
}
....

== Higher Layer Protocols

[appendix]
== Modulation Details

=== BPSK

In binary phase shift keying, a `1` bit is sent as -1.0 and a `0` bit is sent as +1.0.

=== QPSK

tbd.

=== 16-QAM

tbd.

== Documentation License

This documentation is © 2024 by the following contributors and licensed under the terms of the https://creativecommons.org/licenses/by-sa/4.0/[Creative Commons Attribution-ShareAlike 4.0] license.

- Thomas Kolb DL5TKL
- Simon Ruderich