For the Internet of Things (IoT) to achieve its full potential, a number of elements have to be knitted together to form a cohesive and reliable ecosystem. Low-power wide-area networks (LPWAN) will form a crucial part of this as they are designed to allow long-range communications at a low bit rate while consuming small amounts of power. Its low power, low bit rate and intended use distinguish this type of network from a wireless WAN that is designed to connect users or businesses, with LPWAN data rates ranging from about 0,3 Kbps to 50 Kbps per channel.
An LPWAN may be used to create a private wireless sensor network, but may also be a service or infrastructure offered by a third party, allowing the owners of sensors to deploy themin the field without investing in gateway technology. As covered in the previous issue of Dataweek (www.dataweek.co.za/14142r), the state of the rollout of the most prominent LPWAN technologies varies widely.
Ideally, designers will ultimately have a variety of LPWAN options to choose from, depending on their application and its particular requirements. In this article we take a look at some of the technical features of three of the most commonly used (or at least talked-about) LPWANs: Sigfox, LoRaWAN and NB-IoT.
Sigfox
Trustworthiness, which encompasses security, privacy, reliability and reliance, is a key challenge for the Internet of Things. Firstly, this is because the IoT is intimately linked to business-critical processes and secondly because the IoT significantly broadens the surface of attack of business intelligence systems. Sigfox addresses this challenge through a systematic process that assumes that security is relative and will be adapted to the level of threat faced by the application at hand.
Sigfox has gathered a team with extensive experience in the security industry that deals with all relevant aspects, from security by design to active operational measures. This addresses data protection in motion via measures built into the protocol (authentication, integrity, encryption, anti-replay, anti-jamming), data protection at rest via cryptographic storage of data and credentials in devices, base stations and the core network. Reliability and reliance are both native in Sigfox data centres and intrinsic to the Sigfox network architecture to protect against attacks such as DDoS or massive device cloning.
In an effort to support its ecosystem, Sigfox has developed partnerships with internationally recognised security experts to facilitate the introduction of hardware security in devices and provide security assessment schemes for the IoT.
Figure 1. Sigfox is an ultra-narrowband technology.
Sigfox uses 192 kHz of unlicenced radio spectrum to exchange messages over the air using an ultra-narrowband (UNB) modulation technique. Each message is 100 Hz wide and transferred with a data rate of 100 or 600 bits per second, depending on the region (Figure 1). This is what enables Sigfox base stations to communicate over long distances without being impacted by noise. A message with a 12-Byte payload takes 2,08 seconds over the air at a rate of 100 bps. Sigfox base stations monitor the full 192 kHz spectrum and look for UNB signals to demodulate.
Random access is a key feature to achieve a high quality of service, with transmission being unsynchronised between the network and the device. The device emits a message on a random frequency and then sends two replicas on different frequencies and at different times, a technique known as time and frequency diversity (Figure 2).
Figure 2. Sigfox frequency hopping on replicas.
The principle of cooperative reception means that an object is not attached to a specific base station, unlike cellular protocols. The transmitted message is received by any base stations that are nearby and on average the number of base stations is three. This is called ‘spatial diversity’ (Figure 3). Spatial diversity, coupled with the time and frequency diversity of the repetitions, are the main factors behind the high quality of service of the Sigfox network.
In order to address the cost and autonomy constraints of remote objects, the Sigfox communication protocol has been designed for small messages, ranging in size from 0 to 12 Bytes. A 12-Byte payload is enough to transfer sensor data, the status of an event like an alert, GPS coordinates or even application data.
For downlink messages, the size of the payload is static at 8 Bytes. This is enough for triggering an action, managing a device or setting application parameters remotely. The duty cycle for the base station is 10%, which guarantees four downlink messages per device per day. If there are extra resources left, the device can receive more.
The downlink message is initiated by the object. There is a delay of 20 seconds between the first frame transmitted and the reception window that lasts for 25 seconds maximum. The downlink frequency is the frequency of the first uplink message plus a known delta.
LoRaWAN
LoRaWAN defines the communication protocol and system architecture for the network while the LoRa (short for Long-Range) physical layer enables the long-range communication link (Figure 4). The protocol and network architecture have the most influence in determining the battery lifetime of a node, the network capacity, quality of service, security and the variety of applications served by the network.
Many existing deployed networks utilise a mesh network architecture. In a mesh network, the individual end-nodes forward the information of other nodes to increase the communication range and cell size of the network (Figure 5). While this increases the range, it also adds complexity, reduces network capacity and reduces battery lifetime as nodes receive and forward information from other nodes that is likely irrelevant for them. A long-range star architecture makes the most sense for preserving battery lifetime when long-range connectivity can be achieved.
Figure 5. Typical LoRaWAN network architecture.
In a LoRaWAN network, nodes are not associated with a specific gateway. Instead, data transmitted by a node is typically received by multiple gateways. Each gateway will forward the received packet from the end-node to the cloud-based network server via some backhaul (either cellular, Ethernet, satellite or Wi-Fi).
The intelligence and complexity is pushed to the network server, which manages the network and will filter redundant received packets, perform security checks, schedule acknowledgments through the optimal gateway and perform adaptive data rate assignment. If a node is mobile or moving, there is no handover needed from gateway to gateway, which is a critical feature to enable asset tracking applications – a major target application vertical.
Figure 6. LoRaWAN device classes.
The nodes in a LoRaWAN network are asynchronous and communicate when they have data ready to send, whether event-driven or scheduled. In a mesh network or with a synchronous network such as cellular, the nodes frequently have to ‘wake up’ to synchronise with the network and check for messages. This synchronisation consumes significant energy and is the number one driver of battery lifetime reduction.
LoRaWAN utilises two layers of security: one for the network and one for the application. The network security ensures authenticity of the node in the network while the application layer of security ensures the network operator does not have access to the end user’s application data. AES encryption is used with the key exchange utilising an IEEE EUI64 identifier.
NB-IoT
Narrowband-IoT (NB-IoT) is a cellular radio access technology specified by 3GPP (3rd Generation Partnership Project) in Release 13 and subsequent releases to address the fast-expanding market for low-power wide-area connectivity. The mobile industry is establishing NB-IoT as a global coverage solution that enables customers, such as application service providers, to deploy and operate their services worldwide.
According to 3GPP specifications, there are two main Network Attach options to support connectivity:
1. Attach with PDN (Packet Data Network) connection: the UE (User Equipment) is required to establish the PDN connection as part of the attach procedure. This has been the case for all 3GPP EPS (Evolved Packet System) releases up to Rel-13.
2. Attach without PDN connection: this allows UEs supporting CIoT (Cellular Internet of Things) optimisations to remain attached without a PDN connection, which may be useful for cases where huge numbers of devices would keep a connection inactive for very long periods of time and seldom transmit data over it. When a UE is attached without PDN connection, only SMS service is available for any data transmissions and applications are constrained.
There are different data connectivity options for PDN connections available to IoT devices using the EPS:
• IP over control plane (both UDP and TCP) using the control plane CIoT EPS optimisation with IP PDN types.
• IP over user plane (both UDP and TCP), including user plane optimisation and user plane original, available with IP PDN types.
• Non-IP over control plane, using the control plane CIoT EPS optimisation with non-IP PDN type.
• Non-IP over user plan, including user plane optimisation and user plane original, using the user plane CIoT EPS optimisation with non-IP PDN type.
The device (in accordance with PSM, eDRX) will allow transmission of data in both directions. However, there is also the option to request the device to set up ad-hoc connections (not scheduled by PSM, eDRX) by means of triggering the device either via the interface Tsms or Tsp. Each of these options has advantages and disadvantages. The traditional mechanism for transporting information over LTE is by means of IP over user plane (most commonly TCP) and SMS.
Table 1. NB-IoT frequency bands.
Control plane CIoT EPS optimisation transports user data or SMS messages via MME by encapsulating it in NAS (Non-Access-Stratum) and reduces the total number of control plane messages when handling a short data transaction.
For services that occasionally transmit reasonably small amounts of data, the utilisation of the control plane will optimise the power consumption because the amount of signalling required and the ‘air time’ are reduced. Power consumption can be optimised using non-IP, UDP and TCP. Non-IP allows for the use of protocols that have been optimised for a specific use. UDP is asynchronous, which reduces the time of the connection, while TCP will keep the connection open until an acknowledgment is received. However, supporting a network-originated UDP connection might require the use of either a virtual private network (VPN) or IPv6 due to the need to specifically address the device from the server network.
3GPP has defined a set of frequency bands for which NB-IoT can be used, as listed in Table 1. Input received by Mobile IoT Initiative members indicates a variety of bands have been used. Table 2 gives an overview of the frequency bands supported in the different regions. This input suggests only a subset of the bands supported by 3GPP are likely to be used.
Summary
While the South African market waits for network operators to get their acts together with broad deployments of LPWA networks, IoT designers looking to the future need to stay abreast of the available technologies and their features and benefits. The three that are covered above are by no means a comprehensive list and more are sure to enter the market as time goes by, but they provide a technical summary that covers a wide spectrum of applications and architectures.
Hopefully one day soon, enough broad network rollouts will come online that it will become a simple case of choosing the one that fits your application and your pocket, just right.
| Tel: | +27 11 543 5800 |
| Email: | [email protected] |
| www: | www.technews.co.za |
| Articles: | More information and articles about Technews Publishing |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version