When looking to understand LoRaWAN and its ideal use cases, and limitations, it is important to understand a bit of history. LoRaWAN (then called LoRaMAC) was developed by Semtech (the sole owner of the LoRa PHY IP) in collaboration with IBM Research (they subsequently left the project). The assumptions when the protocol was designed were:
These are important assumptions, because the resulting protocol has:
In order to support the 1% duty cycle limitation for the gateway, in particular, many tradeoffs are necessary:
Since all uplink messages are unacknowledged and uncoordinated, LoRaWAN is considered a “pure-aloha” scheme. Such a network has about 18% efficiency. This means that 82% of packets are lost when a LoRaWAN network is fully utilized. Since most messages are unacknowledged, the end node does not know its message was missed. In order to prevent this, some users may transmit more often, thus compounding the problem. Read this easy to understand post about Aloha Networks.
If acknowledgements are added to this system, the efficiency fails even more. This is because whenever the base station is transmitting, it cannot listen. The end nodes do not know that the gateway cannot hear them. Since the gateway can only transmit 1% of the time, this only results in about 1.65% additional packet loss.
Additionally, if someone else is using a LoRaWAN network, all of their traffic counts against your capacity as well. This is because all of the gateways are tuned to the same common frequencies.
Another important consideration for LoRaWAN is the near/far problem. Since LoRa only has 20-30dB of co-channel dynamic range, nodes that are close to the gateway drown out nodes that are far away. This is less of a concern in large MNO networks, since ideally several gateways are in range.
Our friends at The Things Network have put together this piece on LoRaWAN Limitations as well.
All that said, the ideal use case for LoRaWAN is:
Some Automatic Meter Reading is a great example of a good use case for LoRaWAN. For meters that update the reading, say once per hour, it does not matter if some readings are missed, as long as some make it through.
Symphony Link solves many of these problems. Briefly, here is how:
1. Framing: The gateway transmits a frame header every 2 seconds, which contains information about which uplink channels are available and when the uplink window opens.
2. Compressed acknowledgements: In Symphony Link, by default, all uplink messages are acknowledged. To accomplish this, all acknowledgements are mixed together into one compressed message that all nodes (that just transmitted) receive.
3. Variable uplink/downlink time slotting: The gateway decides how long it needs to transmit based on queued downlink traffic. It tells nodes when the the downlink window is complete, so that the nodes never transmit when the gateway is not listening
4. Uplink time slotting: Because of the synchronous framing, the uplink windows are slotted which adds about 100% more capacity. This is further increased by adding a variable CSMA window before each transmission.
5. Variable power and spreading factor: The end node receives the RSSI of the framing message of the gateway and dynamically adjusts its power and spreading factor to match the link plus a setable margin factor. This maximizes capacity, mitigates fast fading, and prevents the near/far problem mentioned above.
6. Quality of service: Nodes register a QOS factor (0-15) with the gateway, and this limits their ability to access channels in each frame. It also provides a way for the gateway to limit uplink during times of congestion.
7. Multicasting: By assigning groups of nodes into multicast groups, the amount of downlink needed for control and file streaming is limited.
8. Fixed 256 byte MTU: 12 bytes is too small for most applications. Symphony Link provides a fixed 256 byte MTU, and handles all the sub-packetization (by SF) and retries at the MAC layer.
9. Firmware over the air: Because of the powerful multicast features in Symphony Link, firmware files can be steamed out to nodes.
10. PKI based session AES keys: Symphony Link does not used fixed key encryption. Every node established a secure AES session using Diffie-Helmann, with the node public key provided by the server. This is known industry-wide as the most secure channel encryption scheme.
Want to learn more? Get in touch.