This repository contains the firmware and hardware files of the LoRaMultiHop protocol. The simulator is hosted here.
The network will be distilled from a mesh/star-type network to a tree/star network first. This is done by sending out beacon messages. These beacon messages are sent out from the central node (gateway). In this message, the SRC_UID field is filled NODE_UID of the sender. When a sensor node receives the beacon message from the gateway, it saves the uid in the SRC_UID field (when direct connection to the gateway: 0x00). After this, the sensor node will adapt the SRC_UID to its own NODE_UID (and increase the hop count) and forward the beacon message further into the network.
When multiple beacons are received on a node, only the best beacon message is saved. This decision is based on the amount of hops to the gateway (recorded in the beacon message) and the SNR value of the received beacon. At the moment, an SNR value difference of at least 10dB is required to outperform a beacon with only one hop extra.
When this process is complete, all sensor nodes should have saved a NODE_UID, which states the most direct connection to the gateway. This process should be repeated every so often, to assure network stability.
| 0 | 2 | 3 | 4 | 5 | 6 | 7+ |
|---|---|---|---|---|---|---|
| MESG_UID | TYPE | HOPS | SRC_UID | DST_UID | LEN | DATA |
Routed messages find their way through the gateway by using the proposed routing protocol. Each sensor node will forward packages, if the packages have not been received yet and if the SRC_UID matches its own NODE_UID. To improve energy efficiency, each sensor node will wait for a predefined time: appending extra incoming (own/forwarded) data to be appended to the to-forward-message.
When to transmit A node will start its procedure to transmit a message on 2 occasions: (1) timer, own sensor data is ready or (2) incoming data to be forwarded. Either way, the node will wait for a predefined time for other packages to come in: between PRESET_MAX_LATENCY and PRESET_MIN_LATENCY.
START START+PRESET_XX_LATENCY
------|----------------------------------------|------------->
possible incoming
messages to append
The PRESET_XX_LATENCY is calculated based on both random values and a history of sending or forwarding data. When the node does not receive a lot of to-forward-messages, the PRESET_XX_LATENCY will evolve towards PRESET_MIN_LATENCY, otherwise (lots of to-forwarded-messages) towards PRESET_MIN_LATENCY. The step up/down is defined by PRESET_LATENCY_UP_STEP/PRESET_LATENCY_DOWN_STEP. This latency is also randomized in a window of +/- PRESET_MAX_LATENCY_RAND_WINDOW.
Message format Messages that need forwarding, and arrive inside the latency window, will be encapsulated inside the message that was waiting to be send.
| 0 | 2 | 3 | 4 | 5 | 6 | 7 | 9 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MESG_UID | TYPE | HOPS | DST_UID | SRC_UID | LEN = 3 bit own length, 5 bit forwarded length | OWN DATA | FORWARDED
|
| 0 | Current | Duration | Remark |
|---|---|---|---|
| Sleep | 5.11uA | - | |
| Wake & Stabilize | 3.42mA | 31ms, 1+CAD_STABILIZE | Note: can be shorter? |
| CAD perform | 18.7mA | 7.64ms | |
| CAD processing | 15.2mA | 5ms | |
| RX | 29.8mA | - | |
| TX | 62.9mA | - | |
| Message processing | 14.6mA | 5.56ms |
