LoRA WAN stuff often not seen

Normally when using LoRA WAN developers most often have to work with either the device end (firmware) or the application end of the LoRA WAN infrastructure. This usually means that one either develops code and radio hardware for embedded devices or sensors in which case on most often uses code like the IBM LoraMAC-in-C library and chips such as the SX1276 that’s also included in boards like the RFM95W and the development board LoRA32U4-II or licensed compatible cores directly embedded in microcontrollers such as the STM32WL that’s also used in most sensors developed by Alpion.

On the other end application developers mostly use solutions like TheThingsNetwork or proprietary solutions like the Bosch IoT suite that either allow one to register to a whole network using protocols such as AMQP or MQTT - or even allow direct hosting of applications that simply register callback handlers like servlets or Amazon’s AWS Lambda infrastructure to handle incoming application messages. Some of these services might be a little easier to scale and allow moving applications dynamically to the network edge, others may be less easier to scale but simple and free to use. All have in common that the network is normally totally transparent - except for delivered information about all gateways that have received application packets.

The stuff one normally doesn’t come into contact with includes:

• Message transport encryption
• Gateway operation. This is sometimes also done by motivated contributors as it’s the case for the things network
• Gateway to network communications (Backhaul)
• Upstream message routing
• Deduplication of received messages
• Downstream message routing and queuing which is particularly problematic due to timing and geographic constraints
• Processing of broadcast messages

This blog post tries to shed some light on these normally hidden parts on an introductory level. If you want to host your own LoRA WAN network you should already know that stuff - maybe there will be a blog post on that topic later on.

Short recapitulation of LoRA device classes

As has been previously mentioned LoRA supports different device classes.

• Class A devices are always in sleep mode except when they want to transmit data. Server side applications are only capable of scheduling downlink packets after uplink action occurred. Downlink packets are queued on the backbone network until reception of messages on any gateway attached to the network. The downlink packet is transmitted in the first or second receive (1s and 2s) window after the device transmitted it’s uplink packet - the network may use either the first or the second but not both downlink windows. Downlink packets are sent usually on the same gateways that have received the device packets.
• Class B devices synchronize their internal clocks to a periodically transmitted beacon. This beacon is sent by all gateways simultaneously (this is done by utilizing GPS as a time synchronization mechanism). The beacon is normally transmitted every 128 seconds. Receive windows are scheduled relative to the beacons which enables downlink to these devices even when they’re not actively transmitting data - on the other hand it requires the network to know which gateways should transmit which frames without seeing the devices transmitting. Because of this class B devices are currently not supported by the community operated TheThingsNetwork but can be used on private networks
• Class C devices extend the receive window to infinity - which means they are always capable of receiving whenever they are not transmitting. This requires - compared to class A and class B - substantial amounts of power and is normally not suited for embedded applications. Again the network has to be capable of determining which gateways should transmit the downlink message - again class C devices are currently not supported by the community operated TheThingsNetwork

Message encryption

First off this sounds like a problem that at least device developers have to be concerned with but that’s mostly hidden inside the LoRA MAC that’s used. All messages on LoRA WAN are encrypted with two keys - the network key and the application key. The network key is a secret shared by all devices using the same virtual network. The network key as well as the allocated device address range define which virtual network is used. This is required since all LoRA WAN devices of all networks share the same frequency spectrum - and one normally doesn’t want different networks to interfere with each other. Note that gateways don’t know network IDs and are not capable of decoding messages. They’re using at most device addresses as well as device EUIs for routing. They even don’t interpret application EUIs that are used as target addresses. Since the network key is shared by all devices and has to be embedded inside the device this doesn’t really provide meaningful security. When using activation using OTAA instead of pre-activating devices this key might also be dynamically generated.

The second key used is the application key. This key is normally only known to all devices sharing the same application as well as the application or the infrastructure that’s delivering messages to the applications. In case it’s known by the infrastructure as it’s also the case for TheThingsNetwork it doesn’t really add any security either and since the key is still shared by all devices it also doesn’t do in any other case.

There might be two dynamically created session keys that are generated during OTAA device activation. In this case a network session key and an application session key is derived from the application key. The network session key is used to validate integrity of messages by the help of a message integrity code. Some networks like the TTN also use the network session key to handle non unique device addresses to map devices to unique DevEUI and AppEUI. The application session key is used again to encrypt application payload - if this provides any security depends on where the encrypted channel is terminated.

In case of dynamically generated keys security is depending on the secure storage of the application secret inside the device themselves. In theory it’s of course possible to use unique secrets per node to prevent compromising the whole application in case a single device is readout. Randomness required for session key generation is provided by the network which also effectively generated the session keys.

Note that OTAA requires persistent storage on the device nodes itself since it requires a monotonically incrementing device nounce that’s used to prevent traffic replay attacks.

Gateway operation

Gateways are the radio access network of LoRA WAN. They are capable of covering large areas spanning hundreds of kilometers in diameter on high spreading factors and are usually capable of scanning all channels simultaneously. They use specialized concentrator hardware like the SX1257 general purpose radio - these are simple frontend chips that provide IQ samples of receivers and accept IQ samples for their transceivers - and a custom baseband processor like the SX1301. Usually two radio frontends are required even in case one just wants to cover a single band like the 868 MHz range used in Europe. The SX1257 can be used for any band in the 860 to 1000 MHz range. For other frequency bands other transceivers like the SX1255 (400-510 MHz) are required. Note that the RF frontend is usually tuned for a specific frequency range so it’s usually required to use different RF frontends (filters, antennas) for 868 MHz and 900 MHz frequency bands in different regions.

The baseband module provides LoRA message handling and delivers received packets to a local software stack. It supports time synchronized transmission of at least a single queued downstream packet. This is required since downstream timing has to be precise as the receive window is pretty tight as well as - on the other hand - to allow time synchronized network wide broadcast messages that are required for class B devices. This messages can be used to support downlink even in case a device does not transmit uplink messages at the given time.

Note that gateways usually don’t know which devices are present inside their covered region - this is usually handled by the network layer above. Gateways usually are operated using pretty dumb packet forwarding and can be built using really cheap hardware. Hobbyist gateways for example can be built around concentrator boards like the iMST ic880a or the RAK2243 concentrator board. Hobbyist usually use hardware like small IPC computers or the RaspberryPi although it’s even possible to use microprocessors like the ESP32 to provide all necessary infrastructure for a LoRA WAN gateway.

Gateways do require some kind of backhaul - this is usually done using Ethernet, WiFi or even a mobile network uplink such as UMTS/LTE/5G. Traffic is usually routed using IP towards a gateway. In many cases a simple packet forwarder that transmits all received packets using UDP and accepts downstream messages from the same UDP endpoint is used. The drawback of this simple UDP protocol is of course that it totally lacks authentication or encryption and the use of unreliable UDP which might lead to packet loss - depending on ones view on the radio network the latter might not be problematic anyways. The advantage of using the UDP protocol is that it’s really simple to implement - but of course it’s susceptible to forgery of packets by rouge entities when used over public networks such as the internet or in case anyone gets access to the backhaul network. More advanced gateways might use (sometimes proprietary) advanced protocols - such as the new TTN protocol that’s currently deployed that’s encoding messages using protocolbuffer and gRPC requests over TLS tunnels or over TLS encrypted MQTT messages. Both of these protocols support encryption and transmit messages using TCP. Even more advanced gateways may automatically determine the message routers they connect to dynamically by using a management and autoconfiguration protocol.

Gateways do usually also use a GPS receiver. This is used to be capable or precise microsecond timetagging of messages as well as precise downstream timing of broadcasts. Of course GPS is also used for network synchronous broadcasts.

Upstream (device to application) message routing and deduplication

Messages received by gateways are usually delivered to some kind of inbound router infrastructure. In smaller networks a single router exists per region, on more complex infrastructure this routing might be distributed as usual for a larger network. Since messages are capable (and most likely do) of arriving on multiple gateways at the same time the network performs deduplication. This of course requires queuing messages for at least a short time till messages from all gateways that are capable of reception have been able to arrive. Usually the metadata submitted with each packet includes a list of all gateways that have received a packet as well as the time tag of the reception and the received signal strength indicator. Using time and RSSI one can do a coarse localization of devices in case they’ve received by multiple gateways - that’s called multilateration and is required at least on a really coarse scale to support downstream messages for multiple devices. The requirement to queue inbound traffic till all gateways have been seen as well as network latency between gateways and the router stage is a huge contrast to the requirement of providing downstream messages in a timely (exactly 1 second or 2 seconds after the downlink window) manner especially in case they should be generated dynamically by the applications.

After the packets have been received at the router they are usually routed towards the application servers using the application EUI as routing key. In case applications are currently offline nearly all network infrastructure provides some kind of limited message queuing capability to store messages till the application is available. More advanced networks provide the ability of a fanout to a number of application servers as well as dynamically rebalancing servlet / lambda based applications into the regions they are required dynamically.

Downstream (application to device) message routing

Downstream messages are messages that should be delivered from application to devices. Since downstream is not possible at all times for class A and B devices downstream messages have to be queued. The network has to keep track of all gateways that it wants to transmit messages for a given device EUI on - it has to keep track of the estimated location of devices. Broadcasting on all gateways is only an option in really small scale LoRA WAN networks. To do this networks usually keep track of the gateways that have seen nodes during the last uplink message as well as the geographic location of gateways. Some network infrastructure also performs multilateration and motion estimation - or at least calculates the maximum possible locations of a device. Using this data downstream packets are scheduled for transmission - a time tag is attached to the message and it gets transmitted to all gateways that might have the node in range. At the tagged time the message is transmitted.

Since downstream messages are sometimes produced in reply to upstream messages but the receive window for class A devices in only 1 and 2 seconds after upstream and has to be broadcast synchronous for class B devices networks supporting class A and B devices do have to support a downlink message queue in which messages for devices are enqueued till the device is seen by one of the gateways. Depending on gateway intelligence the downstream message is transmitted to the gateway in case the gateway provides an upstream message to the router or is pre-published on all possible gateways so the gateway can lookup locally cached messages for all devices in it’s range. The latter strategy is better in case of timing when using unreliable backhauls but requires way more storage and logic on gateways as usually is available.

In case gateways have enough resources to host message queues containing thousands of messages on might also provide edge compute capability and dynamically move applications towards the gateways.

Processing of broadcast messages

Broadcast messages are a special kind of message. They are transmitted at fixed intervals and might be used for time synchronization of all devices inside a network. They also trigger a receive window in all class B devices so they provide a method to transmit downstream messages even in case no upstream is happening. They are usually scheduled on the network routing layer and transmitted on a tagged time by all gateways at once. Of course this also allows nodes to perform some kind of coarse triangulation of their position in case they know the location of gateways.

Application servers

Depending on the structure of the network application servers that host handlers for messages might even be part of the network. Applications might be rebalanced into areas in which devices running a particular applications are present - this could be thought of some kind of edge computing. In this case the queuing and routing system has to be aware of the location of running applications and might interfere with applet lifetime.

This article is tagged:

• Tutorial
• LoRA