Introduction

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

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

  1. Preamble: a fixed symbol sequence that the receiver can use to determine the start time, frequency and phase offset of the following data.

  2. PHY header: contains information about the packet length and modulation/coding scheme.

  3. 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 \$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:

  1. Modulation/code combination ID (MODCOD): 4 bit

  2. 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.

Table 1. Supported packet data modulation/code combinations (MODCODs)
ID (binary) Modulation Channel Code

0000

16-QAM

Punctured convolutional code: \$r=3/4\$, \$K=7\$

0001

QPSK

Punctured convolutional code: \$r=3/4\$, \$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 \$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:

  1. Ramp-up sequence

  2. Pre-packet idle sequence (optional)

  3. One or more packets as defined in PHY Packet Format

  4. Ramp-down sequence

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

During ramp-up, their amplitude \$A_u(k)\$ is scaled up across \$L_u\$ symbols, following the curve \$A_u(k) = sin(π/2 * k / L_u)\$. Ramp-down follows a similar sinusoidal for \$L_d\$ symbols: \$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 \$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.

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:

  1. The link layer header

  2. A variable amount of data, depending on the packet type

  3. CRC16 of all previous bytes, including the link layer header

The CRC16 is calculated using the generator polynomial \$x^15 + x^2 + 1\$.

Node Addresses

Node addresses use the 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.

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

Table 2. 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.

Table 3. 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:

Table 4. Layer 3 protocol identifiers. EtherType is given as reference.
Protocol Hamnet70 ID EtherType

IPv6

0x00

0x86DD

IPv4

0x10

0x0800

undefined/auto

0xFF

-

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:

Table 5. 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:

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

  2. 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:

  1. Configuration Type: 1 byte

  2. Configuration Data Length: 1 byte

  3. Configuration data: variable number of bytes as indicated by Configuration Data Length

The following Configuration Types are defined:

Table 6. 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.

Table 7. Connectionless Frame protocol IDs
Protocol IDs Description

0x00 .. 0xF7

reserved

0xF8 .. 0xFF

Available for experimentation and development[1].

Message Sequence Charts

Connection Establishment

Diagram
Figure 1. Connection establishment

Communication during a Connection

Diagram
Figure 2. In-connection communication

Connection Shutdown

Client-initiated
Diagram
Figure 3. Client-initiated shutdown
Digipeater-initiated
Diagram
Figure 4. Digipeater-initiated shutdown

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 are obeyed. However, the state diagrams shown here reflect the reference implementation.

Connection State Diagram

Diagram
Figure 5. Connection state diagram

Digipeater Connection Multiplexing

Diagram
Figure 6. Handling of multiple connections at the digipeater

Higher Layer Protocols

Appendix A: 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 Creative Commons Attribution-ShareAlike 4.0 license.

  • Thomas Kolb DL5TKL

  • Simon Ruderich


1. 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