star-mesh LoRa network

Dependencies:   sx12xx_hal

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:144n2
hop distancesrc IDdest IDcmd-framecrc16
from gatewayvaries
cmd-framerepeat as necessary
octets:1n1, if another cmdnetc
cmd numbercmd argumentscmd numbercmd argsetc

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.

  1. CMD_DISCOVERY_REQ to upstream
  2. CMD_DISCOVERY_ANS to downstream (1 or more)
  3. CMD_ATTACH_REQ to upstream
  4. CMD_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.


All wikipages