-
Notifications
You must be signed in to change notification settings - Fork 114
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 (due to FIFO buffer size, see 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,
| Byte 1 | Byte 2 - 8 | Byte 9 - 13 | Byte 14 - 17 | Byte 18 - 22 | Byte 23 | Byte 24 | Byte 25 - 256 |
|---|---|---|---|---|---|---|---|
| TTL | src address | dest address | src client ID | dest client ID | sequence number | type of message | 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
source client ID - a unique identifier of web socket client or the system (last 4 bytes of MAC?)
destination client ID - a unique identifier of intended recipient (0xFF for any recipient).
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 (tunable cutoff)?
- Has the packet exceed it's time to live?
- Has the node exceeded it's duty cycle (transmitted too much)?
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 RSSI, SNR, packet loss of recent messages
In order to avoid over using air space (exceeding duty cycle), the routing protocol should be (at least partially) built into normal packet structure. This way every packet can be used to update the routing table and route metrics. If a node reaches a timeout period, based on acceptable duty cycle, without transmitting it should transmit a "hello, I'm alive" packet, so other nodes do not drop it from their routing table.