-
Notifications
You must be signed in to change notification settings - Fork 111
Protocol
A disaster area network (DAN) is a hetreogenous wireless mesh network that utilizes the LoRa modulation scheme for point-to-point or point-to-multipoint connections between nodes. The following document describes the Layer 2 protocol developed for use on DANs.
LoRa refers to a proprietary modulation scheme developed by Semtech. For more info, the physical modulation was reverse engineered by Matt Knight, https://www.link-labs.com/blog/what-is-lora. The modulation scheme should not be confused with LoRaWAN, the protocol stack for the Things Network, https://www.link-labs.com/blog/what-is-lorawan.
There are a few network stacks already being devleoped for LoRa-based networks,
- Things Network - star topology, mostly for sensor networks
- Reticulum - pre-alpha, may be capabale of ad-hoc style meshing, physical layer agnostic
- 6LoWPAN - IPv6 network stack for low power wireless personal area networks
- IEEE 802.15.4e - MAC amendement to IEEE standard for wireless personal area networks (WPANs)
Implement a network stack for DANs that is capable of,
- Communication between any two nodes on a DAN via LoRa, without the need for a server or gateway.
- Intelligent routing of packets on a DAN, with loop-avoidance
- Minimal design that could be easily reimplemented on many devices (e.g. Arduino microcontrollers, OpenWrt routers, Linux computers)
- LoRa packets can only be 256 bytes (according to the official documentation https://www.semtech.com/products/wireless-rf/lora-transceivers/SX1276).
- LoRa devices operate at 915 MHz, in North America. This is in the 33cm ISM band (902-928MHz), it does not require license to use and allows retransmission of packets and encryption of messages, https://www.itu.int/net/ITU-R/terrestrial/faq/index.html#g013.
There are two possible ways of looking at addressing on a DAN.
- single node addressing
- multicast addressing
Single node addressing implies that messages are sent with a single destination address, to begin we will use the MAC address of the nodes WiFi interface as its address. This should be uniquie across the network. We plan to implement encryption eventually, so nodes (or users) may be identified by a public key.
Multicast addressing implies that messages are sent with multiple destinations, these destinations will have a shared multicast address, that will look like a MAC address. Essentially, nodes could subscribe to a channel by accepting messages for a specific address. This may assume prior knowledge of a multicast feed, though we may choose to implement some form of discovery eventually.
Semetech's specifications for LoRa tranceivers include a header (set explicit or implicit). When set in explicit mode, a header will be sent that contains the payload's length, coding rate, and the presence of a CRC, (link to RFM doc) https://revspace.nl/DecodingLora
This should mean we do not need to implement these features in our header, though it may be prefereable to handle them on our own eventually.
Currently, we are using an explicit header, the payload is divided as follows,
1 byte TTL | 6 bytes source address | 6 bytes destination address | 1 byte sequence number | 1 byte type of message | 240 bytes data
TTL - time to live, number of hops allowed before message is discarded by a node
source address - MAC (or MAC-like) address of node that originated the message
destination address - MAC (or MAC-like) address of intended destination node
sequence number - utility byte reserved for services or applications (e.g. handle larger data, perform error checking, generate metrics)
type of message - utility byte describes content of payload and intended service or application (e.g. chat, maps, routing, etc)
data - content of message to be interpreted by application layer
An optional CRC may be included at the end of the payload (it's unclear how or when this is checked).
Devices on a DAN are assumed to only have a single radio transceiver (though we plan on adding support for two). This means that every routing decision comes down to a single question, Should the node retransmit a message or not? This decision is based on a few of conditions,
- Is the destination address in the node's routing table?
- Is the quality of the link adequate?
- Is there another node with a better quality link already transmitting?
A routing table entry on a disaster radio node looks like,
6 bytes destination address | 6 byte next hop address | 1 byte hops from destination address | 1 byte quality of link
destination address - MAC (or MAC-like) address of end point of route
next hop address - MAC (or MAC-like) address through which end point maybe reached
hops from destination address - number of hops from end point
quality of link - a metric based on the last received message from node