Internet of Things: Technologies for connecting sensors
When developing IoT solutions, the connection of things is an essential aspect. Various options are available based on the type of scenario. When the primary goal is to log data for e.g. using big data technology to make decisions, there is a wide range of technologies available for implementation.
In scenarios involving long distances – such as implementation in public spaces, agriculture, or large industrial parks – 2G- and 3G-based methods or WiFi are used for connecting metering devices. Yet in addition to these two old options, there are many further technologies for connecting sensors whose deployment can be advantageous depending on the particular scenario. Those options will be presented. Standards used on the local level, such as Ant+, BLE, ZigBee, or zWave will not be covered here.
WiFi and 3G both require too much energy for battery-operated sensors, especially when higher LTE data rates are in use. An additional aspect for WiFi is, that the physical distance an individual network can cover is extremely limited. On the other hand, communication on mobile provider networks takes place in public space so additional measures need to be implemented in order to secure communication. One alternative would be to link with individual mobile providers who handle the corresponding measures (e.g. via closed user groups or VPNs).
M2M communication on mobile networks
The necessity for energy-saving communication has also been recognized by 3GPP, which is why LTE Release 8 introduced five device categories, which were expanded to ten categories with LTE Release 10 (also called LTE Advanced).
LTE Cat-1 currently represents the only LTE category available in the world that is intended for M2M communication and also facilitates streaming of video and audio feeds. If always-on is not required, then a battery lifetime of five years is possible.
3GPP’s LTE Release 13 standardized the low power wide area networks within LTE: LTE Cat 0 has become LTE Cat M1, with NB-IoT and NB-M2M becoming LTE Cat NB1. Both of those, just like the release’s third M2M standard (EC-GSM-IoT), are not available everywhere yet (as of June 2018: at most in the labs of mobile providers).
While the availability of hardware (prototyping and finished product) has improved in recent months, no valid statements can be made as of yet regarding the energy consuption of the individual standards. However, based on significantly lower maximum transmission output, significant increases should be possible here.
Alternatives to mobile communication providers
In addition to the mobile provider networks, there are further LPWAN signal standards being used for IoT applications. All in all, they operate within the ISM and SRD bands. SRD band bears the advantage of not having to go through approval processes for deployment. The drawback: These frequencies are not available exclusively and, depending on the corresponding regulatory authority, must meet certain requirements regarding transmission output and capacity load.
D7A (DASH7 Alliance Protocol) comes from ISO18000-7, an RFID standard largely used in military settings. Prevalence is still relatively low, especially in Europe. The same goes for hardware options, whether it be for prototyping or production. However, it is the sole protocol to support communication among terminal devices.
Sigfox is a proprietary communication standard from the eponymous company. Similar to mobile providers, Sigfox itself runs its own network with base stations and provides access over the Internet. The company is aiming for worldwide coverage, which should have been achieved in Germany at the end of 2017, according to Sigfox. The company indicates a range of 3 to 10 kilometers in urban environments, and up to 50 kilometers in rural areas. The respective terminal devices communicate exclusively with the receiver stations (gateways) and are permitted to send 140 messages daily of 12 bytes each. For terminal device control, four messages of 8 bytes can be sent. New terminal device types have to go through a certification process set by the company, which provides for a stable network overall.
LoRaWAN is a network protocol based on the proprietary LoRa standard from the Semtech Corporation. That protocol is defined by the LoRaWAN Alliance and is available free of charge. While LoRa can be used for communication among terminal devices, LoraWAN relies exclusively on communication between terminal devices and gateways. Networks run by mobile providers can be found in South Korea, the Netherlands and Switzerland. Additionally, on the international level, there is the community-run TheThingsNetwork. Messages are encrypted end-to-end. It is relatively simple to set up one’s own network. Ranges are similar to Sigfox. While the LoRaWAN distance record exceeding 700 kilometers, represents a rather atypical operational scenario, it does demonstrate the protocol’s potential, as only 25mW of transmission energy was used. LoRaWAN itself does not specify any message sizes or frequencies, but compliance with frequency utilization does require short messages.
Sigfox and LoRaWAN are both supposed to facilitate lifetimes of 10 to 20 years based on a 2500mAh battery. In addition to the three aforenamed protocols, there are further solutions, of which some are selectively implemented and others representing a new standard. Meriting mention here would be Low Power WiFi (IEEE 802.11ah), nWave, and Weightless-W/N/P.
Which technologies are best suited for sensor connection?
The first factor to consider in choosing a communication protocol will be the deployment scenario. If power supply is no issue, and if coverage is only needed for a small area, then WiFi will be suitable: Setting up the infrastructure is comparatively straightforward and the hardware for infrastructure and terminal devices is available in all price segments.
If coverage is needed over larger areas, it becomes time to separate the wheat from the chaff. If a large volume of data is going to be transmitted, then there is no getting around mobile standards. While it is important to control the terminal devices in addition to capturing data, mobile standards are advantageous; since nWave doesn’t offer downlink functionality and Sigfox and LoRaWAN are significantly limited due to frequency load.
It’s also necessary to take a look at latency. On public networks in particular, messages can take several seconds to arrive and may even get lost during transmission.
On the other hand, if saving energy is a primary goal, then there is a clear advantage to the alternative processes, and here in Europe Sigfox and LoRaWAN. The decision criteria here will then be the costs of operation (managed service with SLAs vs. in-house operation or use of community infrastructure), coverage (can be improved in LoRaWAN with in-house receiving stations), hardware availability, and costs for sensor connection.
Author: Lars Koehler