# Radio Link Layer specification
Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (opens new window).
# Overview
The physical channel is a shared channel, so access to the physical channel is contended. Multiple End Devices are allowed to send data at the same time. Collisions MAY therefore occur. Listen Before Talk SHOULD be used if possible.
# Device classes
There are three device classes defined:
| Class | Description |
|---|---|
| A | Low Power, sleepy End Devices. Aloha* |
| B | Low power, time-slotted network |
| C | Always-on End Devices |
# Physical layer packet format
The physical layer packet format is specifically designed to be vendor-neutral and support many cheap commercial off-the-shelf transceivers.
| Preamble | Sync word | Len 1 byte | MAC frame 3-N bytes | CRC 2 bytes |
|---|
The protocol consists of a link layer, a MAC layer, a Transport layer and a application layer. It is designed for being encrypted and secure but does allow for unencrypted content to be transported.
Preamble, sync header and frame length are frequency specific. Details can be found below.
# Sub-GHz specific
MAC Frame Payload max-length is 61 bytes. This is so that many older transceivers with 64-byte-fifo is able to fit the frame.
Sub-GHz preample and sync length:
| Name | Length | Value |
|---|---|---|
| Preamble | 4 bytes | 0101... |
| Sync word | 4 bytes | 0xBBBBBBBB |
# 2.4 GHz - specific
MAC Frame Payload max-length is 125 bytes as the transceivers are newer and more cable than their sub-GHz counterparts.
Preamble and sync values for 2.4 GHz are:
| Name | Length | Value |
|---|---|---|
| Preamble | 3 bytes | 0101... |
| Sync word | 2 bytes | 0xBBBB |
# CRC
MittoNet uses CRC-16 with the polynomial 0x8005:
- Polynom : x16 + x15 + x2 + 1 (0x8005)
- Initialization: 0xFFFF
- no input byte reversal
- no output byte reversal
- no XOR
This polynomial is supported by major MCU and transceiver vendors.
# Sending data to a Class A End Device
Class A devices can send data unacknowledged (unreliable) or acknowledged (reliable). The reliable protocol supports birectional communication while the unreliable protocol does not. Data to the End Device MUST be delivered to the Gateway which will then forward to the data to the End Device the next time it connects.
# Device to Device communication
End Devices are assigned a network address once they joined the network. While this allows for device-to-device communication, it does not specify how authenticity is verified and how authorization takes place. This is left to the Application protocol to decide.
# Data rate
Data rate is fixed. A Gateway MAY support multiple physical channels with different speeds.
# Channels
Channels are fixed and are numbered from 1 to 250. A channel is characterized by the following parameters
- Encoding (2-FSK)
- Symbol rate
- Frequency
A list of MittoNet channels can be found on MittoNet.org (opens new window).
# Modulation
The following modulation types are available:
- 2-FSK with gaussian filter value of 0.5
# End Device MAC layer
Many of-the-shelf transceivers and wireless MCUs that support FSK modulation, has a packet-hander built in. The usual supported packet-format is: - preamble - sync-word - length - address - payload - CRC. The MittoNet protocol has been designed to take advantage of this industri packet-format standard and is extending it with MAC-layer and application layer features.
# Packet structure overview
All packets are carried in the PHY payload.
PHY packet:
| Preamble | Sync | Len 1 byte | MAC frame | CRC 2 bytes |
|---|
# MAC frame
| FDAddr 1 byte | FSAddr 1 byte | FHdr 1 byte | MAC Frame Payload 0-N bytes |
|---|
# Frame Address (FDAddr)
This field contains the physical layer destination address.
# Frame Address (FSAddr)
This field contains the physical layer source address.
# Header (FHdr)
The FHdr is short for Frame Header and contains the type of frame and version information:
| FVer [7:6] | RFU[5:4] | FProto [3:0] |
|---|
# Frame Version header (FVer)
| FVer | Description |
|---|---|
| 0 | Version 1 |
| 1 - 3 | Reserved |
# Frame protocol (FProto)
Type is the MAC frame type. The following table describes the options:
| FProto | Description |
|---|---|
| 0 | Network Join protocol |
| 1 | Service Discovery protocol |
| 2 | Reliable protocol (RP) |
| 3 | Unreliable protocol (UP) |
| 4 | Generic Broadcast protocol |
| 5 - 13 | Reserved |
| 14 | Blackhole protocol* |
| 15 | Reserved |
* The Blackhole Protocol number (14) is private to the network and can be used for proprietary implementations.
# Mac Frame Payload
The TType field specifies the type of transport layer carried in the MAC payload.