MittoNet

# Protocol overview

The network is a star network and Device can transmit when they want (Aloha). All communication is acknowledged. Broadcast (downlink) and unicast is supported. Device are required to register to the network.

MittoNet overview

# Introduction

This page aims to give a overview of of the MittoNet protocol suite. A simple to implement and easy to use spectrum efficient protocol suited for battery driven or solar-cell sensors and Devices.

# Device

Device are the sensors, actuators and devices that send and receive data.

# Gateway

The Gateway is the edge device, required to decrypt packets, send acknowledge packets and forward packets to the Network Server. Decision logic MAY be implemented on the Gateway as it then be able to filter packets based on rules that is has received from the Network Server. The Gateway software MAY be updated by the Network Server.

When the Gateway is started for the first time or has experienced power-loss, it will connect to the Network Server and retrieve it’s configuration before it will receive or forward any data. This includes the Network frequency(ies) and Network Server connection information.

The gateway MUST have at least two interfaces; The Wireless device network and a LAN network (or WAN for 4G uplink). It MAY have multiple wireless interfaces.

# Sub-GHz and 2.4GHz interfaces

These interfaces has the following configuration options:

  • Frequency
  • Data Rate (Kbps)
  • Preamble length
  • Sync word length

# WAN or LAN interface

  • NB-IoT or 3G/4G connection
  • WiFi
  • Ethernet

# Network Server

The Network Server takes care of managing the network and handling join requests from Device. It also does the rule/action-processing. There are a couple of required features that a Network Server must support, they are:

  • Handle Join requests from Gateways
  • Handling Join Requests from Device
  • Handle downlink data to Device
  • Forwarding data from Device

Optionally, the Network server can support the following features:

  • Filtering packets from Device
  • Storing data
  • Device Firmware upgrade (OTA)
  • Implement actions to be performed on data based on it’s content

# Protocol overview

The protocol is layered much like the TCP/IP protocol. It consists of the following layers:

  • Physical layer
  • Medium Access Control layer
  • Transport layer
  • Application layer

The Transport layer consists of a number of protocols for transferring data; A) Join protocol, B) Reliable communication, C) unreliable communication and D) Broadcast communication. Reliable communication is acknowledged and bidirectional communication with sleepy Device is possible. Unreliable communication is un-acknowledged and only Device that are awake and listening MAY receive data using this protocol.

The Application layer specifies a number of protocols and will be extended over time. Currenetly it consists of:

  • Network Command protocol
  • Network Event protocol
  • Application Command protocol
  • Application Event protocol

Network Event messages are used when the Device has "Low battery" or "Device rebooted", "Device opened". Network commands can be configuration messages like “only send events when X happens” or "Reboot".

Application Event message examples are “Humidity is 82%”, "Sheep is moving" or "Presense detected". Application Command messages can be “Actuate the lever”.

# Commands definition

Commands are defined as “An order to do something”. One may request changes by sending commands. They are named with a verb in the imperative mood plus and may include the aggregate type, for example Reboot or SetTemperature. Unlike an event, a command is not a statement of fact; it's only a request, and thus may be refused. The Network and the Application are allowed to send Commands.

# Events definition

Events are defined as “Something that has happened”. It can be a sensor reading or a one-time event of something that has been triggered, like a door-open-event. Primarily Device emit events, everything on the network is allowed to send Events.

# Device

# Device nomenclature

Devices MAY be grouped into types. This specification refers to a collection of Device that has identical hardware as a DeviceType. A DeviceType MAY have one or more sensors or types of data it can collect or actuate. This specification refers to these as DataTypes. A DataType is unique to a DeviceType.

# Device Join request

When joining, the Device must first determine which Channels (frequency and baud rate) it can use in joining the network:

  1. The Device selects a frequency, baud-rate and modulation
  2. The SHOULD find the nearest gateway by sending a Ping request, before sending the join request
    1. The Device sends a Network Command message with Type=0x01 Ping using the network source address of 0 and destination address of 1 (one)
    2. The Device MAY receive a reply and takes a note of the received RSSI (GW) in the ping reply message
    3. The Device MAY continue the search by repeating the process from step 1
  3. The Device sends a Join request to GW (FSAddr=0, FDAddr=1)
  4. The Gateway sends the Join request to the Network Server
  5. The Network Server authenticates the request and responds to the Gateway accordingly
  6. Gateway sends a reply to the Device with a Join accept or Join deny

If the Join request is accepted/approved, the response frame will contain Join accept/denied status and Network Configuration data. Configuration data MUST include:

  • Join Status
  • Event interval
  • Status interval
  • Network time
  • Optional Device configuration

Optionally, Configuration data MAY include

  • Configuration data for each of the Data Types on the Device.
  • Period and frequency for when the device should send back data or events

# Device to Device communication

Device to Device communication is done using the Network Address of the Device. If an Device wish to send data to another Device, then it must first obtain the other Device Network Address. This can be achieved either as a Network command to the Gateway or a broadcast frame that the other Device responds to.

# Gateway

The responsibility of the Gateway is to relay (bridge) packets to and from the Device to the Network Server. To do that, the Gateway has a permanent connection to the Network Server. The connection is used for the following things:

  • Configuration of the gateway
  • Relaying packets to Device
  • Relaying packets from Device

# Gateway startup

When the Gateway is started for the first time or has experienced power-loss it MUST connect to the Network server in order to obtain its own configuration. These include:

  • Permanent connection details (eg. MQTT)
  • Topics for subscription and for publishing (in case of MQTT)
  • List of operating frequencies on the Sub-GHz side

# Network Server

The Network Server holds all state for the network including all Device registrations, Device configuration and Gateway configuration. It is central to the network and if not functioning correctly will cause the network to malfunction.

# Device Registration

When a new Device is ready to be commissioned, it MUST be onboarded in order to be known to the Network. This process consists of the following steps:

  1. A new DeviceType is created in the Network Server.
  2. One of more DataTypes is created and associated with the DeviceType.
  3. The Unique ID of the Device is entered in the Network Server and it is configured with settings and DeviceType.

# Data path

When the Network Server receives data from an Device it will process it according to the configured rules. There includes:

  • Relaying raw data to Application server
  • Decoding data into meaningfull events and taking action depending on rules
  • Storing events
  • Forwarding events (MQTT, SMS, Email, Application connector)

Relaying of data depends on the Network Server implementation.

# Device Types

Device (ED) MAY be grouped into DeviceTypes. These are devices of the same type and have produce the same types of data-output when sending events or responding to commands. Devices of the same DeviceType MAY be configured differently but their DataType(s) remain the same.

The Device Type is used when decoding the data sent by the EDs mainly to know the DataTypes.

# Data Types

Device Types share the same data format. A Device Type MAY have one or more Data Types. These formats called DataTypes and represent One event from an Device. An example of a Data Type can be temperature, humidity or distance. Data Types MUST NOT be shared across Device Types.

# Rules

When events, eg. temperature=22deg, has been received and decoded by the Network Server, then rules MAY be configured to match certain events, like for instance if temperature > 22 deg then do the configured Action.

The implementation of the Rules is specific to the Network Server. The MittoNet specification does not cover the implementation details of the Network Server.

# Actions

Actions are executed when rules match data from EDs. Examples of actions are:

  • Forward data on MQTT
  • Send an email
  • Send an SMS
  • Store Data

The MittoNet specification does not cover how rules are implemented.

Last Updated: 5/15/2021, 12:02:32 PM