star-mesh LoRa network
mesh MAC details
Mesh Network MAC layer details¶
frame format¶
All packet messaging begins with a request packet. The request packet is sent to a receiving device in an idle low-power state. The low-power state is spend mostly in deep sleep, where the receiver wakes up only for short time to check if LoRa preamble exists. If this preamble is present, the LoRa de-modulator receives the message at end of preamble. This is known as Rx-Single operation, with timeout.
On the transmitter side of request packet, a long preamble is sent with duration slightly longer than the wake-up interval of receiver.
This request packet is then followed by an acknowledge / answer packet. This response packet is sent with normal / short preamble length of 8 symbols.
physical frame | |||||
---|---|---|---|---|---|
octets: | 1 | 4 | 4 | n | 2 |
hop distance | src ID | dest ID | cmd-frame | crc16 | |
from gateway | varies |
cmd-frame | repeat as necessary | ||||
---|---|---|---|---|---|
octets: | 1 | n | 1, if another cmd | n | etc |
cmd number | cmd arguments | cmd number | cmd args | etc |
commands implemented on network¶
CMD_ANS
- answer to any request other than discovery
CMD_DISCOVERY_REQ
- broadcast to all devices when a device is not attached to network
CMD_DISCOVERY_ANS
- response to discovery request, sent at randomized time relative to discovery request
CMD_ATTACH_REQ
- sent by device after discover request, to associate with device on network
CMD_USER_PAYLOAD_UP_REQ
- user payload uplink: sent by device with user payload, to be forwarded up to central gateway as needed
CMD_USER_PAYLOAD_DN_REQ
- user payload downlink: sent by central gateway, to be forwarded down to destination device as needed
CMD_NEW_DEVICE_ATTACHED_REQ
- sent by device with a new device has attached to it. Required for gateway to know route to new device
CMD_REMOVE_DEVICE_REQ
- sent by gateway to inform downstream devices that a device has attached to a different device, and needs to be removed from list
CMD_DOWNSTREAM_NOT_RESPONDING
- send by device when a user downlink could not be sent, device not answering downlink request
unit identifier¶
Each device on this network has a 4-byte unit identifier to uniquely identify device on network. This identifier is obtained from CPU serial number registers. On STM32 family, this is obtained using LL_GetUID_Wordn()
, where n
is 0, 1 and 2.
For other CPU families, the appropriate register containing date-code, lot, wafer position must be used.
This method of identifying permits the same firmware binary file to be programmed into every device.
discovery process¶
When a device inst attached to network, it will broadcast a discovery request. All devices hearing this request will send a discovery answer at random time offset relative to end of discovery request. The requesting device will keep receiver open for predetermined time to collect these discovery answers. At the end of this collection, the requesting device will select best upstream device to associate with, based on how many hops device is away from gateway along with LoRa SNR and RSSI.
CMD_DISCOVERY_REQ
to upstreamCMD_DISCOVERY_ANS
to downstream (1 or more)CMD_ATTACH_REQ
to upstreamCMD_ANS
to downstream
This procedure is also done when upstream no longer answers requests: retries exceeded to upstream.
The amount of time given for discovery answer collection is defined in main.h N_DISCOVERY_ANS
, which is scaled according to packet time duration of discovery answer.
Additionally, during operation on network, devices will listen to the hop-distance-from-gateway byte in packet header to evaluate if another device becomes more preferable to become associated with. The same method used in the discovery process is used to determine preference value for deciding if another device has higher preference to be associated with. This is needed to accommodate changes in network, such as new devices or moved devices, or if a device was busy while the initial discovery request was sent.