Taking a system level approach to IoT design

5 mins read

To make the Internet of Things (IoT) successful, implementation is critical, but delivering solutions – such as location sensing devices - often requires a holistic approach.

Semtech’s LoRa Edge geolocation solution provides an interesting demonstration of this holistic approach to design, taking advantage of advanced technologies such as direct demodulation and the cloud to deliver not just high energy efficiency but low cost and ease of use.

A common issue with location sensing based on conventional technologies is that a solution often requires integrating multiple RF front-ends at the circuit-board level because, unless the integrator knows that the tags will only be used in a closely controlled environment, they have to be able obtain position information from multiple sources.

Whereas GNSS services operate well outdoors, indoor location will often require the ability to pick up Wi-Fi signals for position triangulation. Another RF interface will also be needed to support low-power RF communication to satisfy IoT applications.

Semtech’s solution uses software-defined radio techniques to collapse these three individual RF front-ends into an integrated unit. Signals from three antennas are conveyed through low-noise amplifiers into a single analogue-to-digital converter (ADC) that feeds directly into a digital demodulator. This makes it possible to handle a diverse range of signals, from LoRa communications in the sub-1GHz band, through to the signals transmitted by the BeiDou and GPS satellite constellations.

The use of software-defined radio makes it possible to home in on specific parts of the incoming signal without having to waste resources on elements that are not necessary to function and to tune functionality according to circumstances and maximises battery life.

An example of situation-dependent signal processing lies at the heart of the requirements for a geolocation tag that can be used both indoors and outdoors. When the tag is asked to obtain its location, it has to determine which location technology will be best. If the tag is outdoors, it should be able to easily detect the GNSS signals. LoRa Edge uses this principle through a low-power scanning mode that an external controller can activate when it tries to obtain a position.

For up to 0.65 seconds, the firmware in the LoRa Edge geolocation solution will process signals expected on GNSS frequency bands. Only if it detects a GNSS signal that has a signal-to-noise ratio of more than -134dB will the receiver attempt further processing. If it is successful, the receiver firmware then changes its processing to algorithms with greater sensitivity to try to find as many as eight satellites with a signal strength of more than -141dB.

With a sufficient number of satellites in sight, the receiver will obtain enough data to support an accurate position fix within 1.65 seconds total. Once it has captured the signals, the receiver can stop processing to save power, unlike conventional GNSS receivers that continue receiving.

This geolocation solution does not attempt to handle the received satellite data locally, rather the data elements are combined into a message that can be transmitted to a cloud service for processing, offloading much of the complex signal processing needed to convert received satellite messages into an accurate geolocation.

If GNSS is unobtainable, the LoRa Edge geolocation chipset can switch to decoding signals from the 2.4GHz antenna. As with the GNSS implementation, the RF engine does not attempt to decode and process the data completely. It focuses only on those elements that are required by the remote cloud service to determine an accurate geolocation, taking advantage of the structure of the Wi-Fi protocol.

The RF engine does not need to transmit any data to nearby Wi-Fi routers, relying entirely on passive scanning. In the WiFi scanning mode, the receiver captures signals that conform to the 802.11b, g or n type protocols that are used on the 2.4GHz band. The receiver firmware can pick out suitable packets by listening for the preamble used by Wi-Fi routers before they transmit any useful data. As soon as the first bytes of packet data are received, the firmware demodulates the signal and captures bytes until it has a full access-point media-access controller (MAC) address. At that point, there is no requirement to listen for any more data from the WiFi access. It will simply store the address and the associated signal-strength value before turning off the RF front-end in order to save power.

Typically, to be able to obtain an accurate location fix from Wi-Fi, the host will need to capture the MAC addresses of several nearby access points. So, the host controller can activate the passive-scanning mode a number of times in succession until it has enough. To avoid wasting power in areas with poor Wi-Fi access, the RF engine can implement a timeout mode, disabling the receiver automatically if no valid packet has been transmitted until the host controller decides to try again.

Once it has a list of MAC address and signal-strength indicates, the host can, as with the GNSS data, pass the data to the cloud for conversion to a geolocation. Using the cloud leads to further savings in energy on top of the optimisations used to only pull as much information as necessary from the received RF signals, pushing battery life from a matter of months to two to three years.

The software-defined nature of the RF engine allows for further cost optimisations. Access to the cloud service to transmit the location requests and other IoT data need not use another RF device. When the receiver has finished acquiring GNSS data, the host controller can switch the RF engine in radio mode to gain access to the LoRaWAN-access features it provides. Once packetised data has been sent, the RF engine can be switched into receive mode ready for response or switch to a low-power standby mode to wait until a scheduled time to receive instructions or a response from a remote server.

Security features

The way that LoRa Edge geolocation solution is configured means choices over where data packets are sent are entirely those of the integrator or service operator. LoRa Edge takes full advantage of the security features of the LoRaWAN protocol. Built-in security is a key component of LoRaWAN and it implements end-to-end encryption for application data. This is on top of a network-level encryption layer that is used to prevent unauthorised nodes from gaining access.

The commissioning process involves a request to a Join Server that performs authentication routines and checks the device’s credentials using standard AES-based protocols. Following that authentication process the join server and device cooperate to create session keys that can be used to protect network messages. Devices can then use similar procedures to authenticate themselves to the user’s own application servers. By doing so, there is no requirement for applications and the network operator to share keys.

The distinction between network and application services is as important for the Cloud-geolocation services as it is for other application use-cases. The design of LoRa Cloud and the LoRa Edge geolocation solution allows for this by ensuring that any location-fix requests are made from a customer’s own application server rather than having the device itself make the request at the network level. In this way, integrators can determine the best application architecture for themselves. If a geolocation should be reported back to a tag, that can be handled at the application layer by the user’s own system. However, in many cases, the data does not have to be stored in the device itself: it can be held in the cloud and distributed only when necessary.

At the same time, the design of the LoRa Edge geolocation solution provides users with a convenient mechanism for storing the encryption keys needed for network and application access. An area of secure memory is programmed with the key data that is used to join a LoRaWAN network at startup and supports the ability to store custom keys for use by user applications. As a secure memory, the keys cannot be read out from the device. Onchip logic performs all the secure and cryptographic operations needed to access LoRaWAN features.

In conclusion, thanks to careful choice of architecture and implementation that extends from the RF interface up to the cloud, LoRa Edge geolocation solution demonstrates how it is possible to use a system-level approach to deliver on the energy-efficiency promise of IoT devices and support easy design-in.

Author details: Pedro Pachuca is Director, Wireless Products, at Semtech