Is LoRa ready for prime time?

This article is from the CW Journal archive.

Small and remote things often need to work on batteries for long periods. Semtech's LoRa (Long Range) is one of the options available. LoRa only defines the physical and link-layer protocols and developments around it may not be compatible with other LoRa-based projects, but the LoRaWAN initiative, guided by the LoRa Alliance, adds the network layer and offers the necessary accreditation for product interoperability.

Semtech acquired LoRa in 2012 and it has taken a while for the protocol to mature. The radio link is based on chirp spread spectrum, operating in the ISM band at 868 MHz in Europe, with a maximum transmit duty cycle of one per cent. It can transport datagrams, with a variable maximum data payload size and without guaranteed delivery, between nodal end points over low-cost, low-power radio links.

Nodes may communicate simultaneously with one or more gateway base stations, managed by a core network server. These network servers may be privately operated or provided as a public shared Software as a Service (SaaS) facility.

Network servers decrypt and de-duplicate messages passing received messages to the appropriate application server that has the specific code to process them. In the reverse direction, datagrams from the application server are routed via the network servers to the gateway nearest to the node.

LoRa uses an unusual spread-spectrum modulation scheme based on chirp FM for low complexity. This helps to make it more resistant to in-band interference; and its flexibility allows a datagram transmission to be spread over a long period, effectively reducing the bandwidth and giving better link budget for long range or in difficult propagation conditions. Depending on the noise level both nodes and gateways may transmit with different spread spectrum encoding, called the spreading factor (SF).

Smart Sensors

Beringar makes LoRa compatible sensors which can collect 15 data points in real time including sound, temperature, air quality,occupancy, and light levels

Most LoRa modules operate at SF12 at maximum power by default. We try to engineer systems operating at SF9 or lower. This has many benefits: larger payloads, less time on air to maximise battery life, and network capacity.

When applications are designed for use in commercial and government buildings where it is often impractical or impossible to connect reliably to any in-building data network, units can be mains powered, and gateways can incorporate a cellular modem for backhaul. Typical payloads range from small messages of under 20 bytes from room-occupancy and environmental sensors, to utility meter readings where messages may be over 100 bytes.

In tall buildings, depending on their construction, a gateway has to be deployed every four to eight floors but if the site involves adjacent buildings, the number of gateways can be reduced as nodes can transmit between the buildings through non-thermally coated windows. Gateway density is determined by ensuring every node can be seen by more than one gateway. By using spreading factor SF9, or below, we have consistently transferred over 90 per cent of datagrams first time – and better than 95 per cent in many cases.

With SF10 or higher we had to fragment large payloads, such as utility meter data. At high SF the idle time required between transmissions could introduce a couple of minutes of latency to transmission of fragmented data, even assuming one of the fragments did not corrupt.

We've had some fun with gateways as well. Simply-configured gateways using a SIM card will send every LoRa packet they receive back over the cellular network, using more data than expected. Another hard lesson was that the inherent one per cent duty cycle also limits total gateway transmit time – and message acknowledgments sent by the gateway count towards this, too.

Antennas continue to be a dark art. Chip antennas failed to give consistent results. PCB planar antennas proved to be directional though used on commercial nodes. Internal antennas are compact and suit in-building gateways, but external gateways often use vertical arrays about a metre long which give useful elevation gain.

It's important to pay attention to the management of radio information provided in each packet received by the core LoRa network. Here are the questions to ask (our custom software routinely provides answers):

How many, and which, gateways can see a node? Ideally, do two gateways (or more) see a node. Most networks will report the SNR and received signal strength (RSSI) of any datagram received from a node at each gateway.

How many packets are getting lost? Look for gaps and step-changes in the sequence number that is incremented with every LoRa transmission (the gateway and node maintain separate counts as part of the LoRa over-the-air protocol). Step changes to zero in this sequence may indicate nodes are being reset, gaps indicate lost packets.

Is the adaptive data rate (ADR) and power management working? Is the spreading factor and data rate reported by the network changing as expected?

What's the estimated battery life? For simple nodes, track the time the node’s transmitter has been active (payload size combined with the spreading factor reported by the gateway).

On-ramp claims higher Data rates and greater range than either SIGfox or LoRa

Firmware revisions added periodic messages from the nodes to our application management information to further monitor the system operation. This included signal strength and percentage loss of packets received by the node. Data was layered into existing status messages from the node that sent information, such as: why the unit last reset (power-on or watchdog-device fired), the current firmware version, or had the on-device management switch been pressed? For mains-powered devices, we switch nodes to Class C operation wherever possible so data can be received at any time.

The most useful feature added to help install was a routine to make a Class A node send a status message to the network whenever a hidden button on the node was pressed to make it "call home". This provided an opportunity for the network to transmit back configuration and install data, and a flash of an LED on the device in acknowledgement.

The most common operational problem had nothing to do with LoRa: how to prevent mains-powered nodes from being unplugged during tests, and accesible antennas being unscrewed.

With most nodes defaulting to SF12, every network with static nodes now has LoRa's ADR support enabled to adjust the spreading factor and, depending on network, transmit power both for nodes and gateways.

In some cases, ADR had to be enabled in the node and in the network server. We saw most of our links start dropping from SF12 to between SF9 and SF7 after about 20 messages had been exchanged. There was also some reduction in the number of gateways that received the data transmitted by a single node.

All of the ADR heavy lifting is implemented in the network server rather than the nodes or gateways. It's always wise to ask any LoRa server provider for details of their ADR operation before signing up. ADR algorithms are not standardised in the network server, though Semtech has published recommendations.

Most LoRa gateways communicate with the LoRa server network using variations on the Semtech packet forwarder specification. This is quite a basic protocol compared with the S1 protocol used by 3GPP networks. It typically forwards every packet received by the gateway to the server network, together with radio information: SNR, RSSI, and additional information such as timestamp, that may be GNSS/GPS derived for geolocation. To send data to a node from the network server the appropriate gateways are sent the packet together with other information such as the power level and spreading factor to be used.

The network server has a number of key roles in optimising operations. The server determines to which gateway(s) a packet should be sent to reach a given node: usually the gateway with the best received signal strength for a node.

The server also determines and sets the power and spreading factor embedded in each packet sent through a given gateway to a node. It can also monitor received messages from a node, as an option in ADR, and send the node a message to set the power and SF values for transmissions to the gateway.

Policing the security of a link in shared spectrum is clearly important. Superficially, LoRa is reasonably provisioned with encryption at the link level to determine if a message is going to a valid destination. All commercial LoRa servers allocate a system-wide application key, decrypt the data payload, and pass it to the application server by default so the system is easy to use. We prefer to apply different application keys to each device.

Many networks can be configured to allow the data to remain encrypted but, depending on the network server vendor, success is not guaranteed. When a node joins the network, application keys are part of the key exchange and you have to effectively duplicate functions of the network server to independently manage them.

For very secure applications, LoRa should only be part-trusted, and a secure element can provide another layer of encryption above LoRa. The most common use for the secure element is, ironically, not to encrypt data sent from the node, but to digitally sign commands sent to the node. Nodes that can control actuators, regardless of network connection technology, require much more stringent security features than most sensor-reporting applications.

While configuring security we had a mild panic. Associated with every device there is an application Extended Unique Identifier (EUI), a device ID and associated application security keys. What happens if you fall out with your network service provider? You can't afford to reprogram every node.

Tests have now confirmed that IDs can be transferred between different network service providers and the LoRa ID (application EUI) is configured for more than one of our selected providers to ensure the same IDs can be reused across multiple networks. We are now taking this a stage further and will be registering some of our own LoRa addresses (strictly IEEE EUI64).

The integration between the gateway and the network server is probably the most immature part of a LoRa deployment but this is improving and is likely to get significantly better as the LoRa market consolidates.

The protocol between the gateway and the network may vary and a given gateway software load may have to be patched to work with a given network. Many gateways are Linux-based and allow secure socket shell access. There is no standard management protocol between the gateway and the network server. Even basic commands for resetting a gateway may require a vendor-specific login.

A typical LoRa gateway using a cellular backhaul will involve: a dynamic DNS service to find a gateway's IP address on the mobile network; connection security through an HTTPS server on the gateway; and further support using VPN tunnels.

Looking to the future for active buildings, there is a lot of fun to be had mixing LoRa and Bluetooth mesh to integrate additional very low-cost sensors into a sensor cluster. It's also hoped that gateway vendors and network service providers will get together and standardise more of the upper layers of the network.

Most of our focus is now more mundane – to streamline manufacturing, provide software that can test and provision nodes in the factory after manufacture, and pre-provision devices in our network and application servers – or try novel things like printing QR codes on nodes so an installer can scan a node and get directly to configuration web pages on a tablet or phone.

The bottom line is that LoRa is ready for production, provided it is realised that systems integration and operational issues will dwarf the node hardware design effort as a project moves from a bench prototype to an integrated system.