The decision regarding which network is to be used is an early consideration for IoT deployments, but how do you determine availability and which network will give you the best solution and project outcomes?
The short answer can be captured in two words, evolution and innovation. Over time, IoT sensor technology has evolved in capability, potential for scale and reduction in cost per module, creating a demand for new wireless network protocols and methods to support the new sensor types, many of which rely on battery power and infrequent messaging at long range, and over a wide area.
Doubt, uncertainty and fragmentation in the IoT market, combined with increasing sensor hardware and software innovation, have led to the creation and fielding of several network connectivity options, each with their own attributes.
In recent years we’ve witnessed the growing expansion and evolution of one dominant IoT Network type, the Low Power Wide Area Network (LPWAN). The early entrants to this market, LoRaWAN and Sigfox, use free-to-air radio spectrum, and have had time to establish themselves across the world. LoRaWAN in particular has been a runaway success as an IoT Network connectivity option, dominating the market with over 40% market share of new connections, which is projected to continue adding market share through 2025.
On the cellular side, for new IoT network protocols NB-IoT and LTE-M (evolutions of the 4G spectrum that have now been adopted under the 5G standard), there is still an element of catch-up in progress. The GSMA was late in ratifying the standards for these IoT protocols and ultimately their deployment by Tier 1 carriers came sometime after the initial rollouts of the first LPWAN network connectivity protocols.
Despite initial predictions claiming that the cellular IoT Network variants would dominate the IoT connectivity market and squeeze LoRaWAN and Sigfox to the margins, there has been a lack of intensity in UK rollout of
the cellular IoT network programmes (at the time of writing, LTE-M has been enabled in the Eastern half of the UK, and NB-IoT has ‘holes’ in its’ coverage, particularly in the Eastern side of the UK). This means that IoT cellular LPWAN work has been largely limited to testing in the UK, while production rollouts are dominated by Private Council LoRaWAN installations and innovation programmes on public network variants of both LoRaWAN and Sigfox.
Globally, analysts project that there will be a 50:50 split in LPWAN network deployments between the free-to-air (unlicensed spectrum) and cellular variants (licensed spectrum) – the competition between these network standards will continue for some time to come. In particular, once 5G is fully rolled out and there are radio modules at a workable cost point for IoT, 5G protocols will also have an IoT element for the cellular side that will bring increased scale and efficiency in terms of its capability to connect millions of sensors per square kilometre.
Which network type or protocol to use?
As with most projects, cost of delivery for data is a primary concern that must be addressed. LoRaWAN and Sigfox are now at a level of maturity where the devices are cost-effective. Initially, cellular was a much higher cost, but is now starting to achieve cost-effectiveness. But in terms of usage costs, for NB-IoT and LTE-M, users are still paying for data usage on the network (paying by the byte), whereas LoRaWAN leverages the free-to-air spectrum facility and charges are based on device licensing, and in the case of Sigfox, per message.
Even though there appears to be a clear differential in terms of cost models, the choice of network and protocol isn’t straightforward. As IoT rollouts become more commonplace, there are elements within a LoRaWAN environment that create cause for concern. With multiple devices sharing the LoRaWAN spectrum there can be potential collisions on the network and lost messages. In order to ensure each message arrives, the LoRaWAN protocol and software controlling the network has been adapted further to mitigate against this happening by spreading messages across multiple channels, monitoring message counters, and other techniques.
Identifying the parameters of the use case and the nature of the deployment is very important. If a message with telemetry data only needs to be sent when there is a status change, this won’t necessarily create network congestion on a LoRaWAN Network. Regular 15 minute monitoring from multiple sensors in an area may however require additional gateway capacity to ensure spreading the sensor message load. But if your use case requires guaranteed delivery of traffic within a specific time period, or a constant stream of messages cellular protocols such as NB-IoT and LTE-M may need to be used.
Use cases
Another consideration is the protocols certain sectors are already using to gain traction. There’s been a tremendous uptake and interest in LoRaWAN among local government that see it as a mechanism they can use to scale multiple use cases at once.
In the utility monitoring sector, NB-IoT appears to be the protocol gaining the advantage. No gateways are required as signal towers are the enablement point and it has deep penetration under the ground with good signal strength to reach its destination. But when it comes to monitoring elements deep within buildings, LoRaWAN can be more effective compared to what NB-IoT can do from the outside in. Refrigeration and temperature monitoring is one such example and LoRaWAN can provide an effective protocol in this instance, measuring the temperature deep inside the building, all the way down to the probe where intensive monitoring and data collection is critical.
For a use case such as measuring readings intermittently, on an alert basis or once an hour, you need to conserve battery power so the sensors last a long time and will likely be leading towards the unlicensed spectrum. Whereas within a healthcare monitoring scenario, such as in someone’s home or in an ambulance on the move, readings will need to be sent through immediately, so will need to rely on the licensed spectrum, such as LTE-M.
Blended connectivity
Currently, there is no one protocol that is optimised for every use case or can cover an entire estate. The solution is to deploy a hybrid model, one which blends different connectivity protocols together, from the unlicensed and licenced spectrums, to achieve total estate and use case coverage. A blended approach is inherently flexible, cost-effective and scalable for those looking to reap the benefits of mass-scale IoT but uncertain as to how and where to proceed.
Longevity is crucial for the success of an IoT deployment. No business wants to rip and replace the technology after ten years. It’s clear that LoRaWAN in particular is on a growth trajectory that will provide that longevity. And the eventual maturity of 5G will also become another option for IoT projects, with much more efficiency in terms of capability to connect millions of sensors. 5G may be a way off yet, but it’s likely that many estates of devices and networks will eventually have parts of them consumed by 5G.
With a blended model of different protocols covering each estate, to make it efficient and streamlined, it’s important for a single platform to be used that can bring it all together and be received, read and analysed in one place. NB-IoT, LoRaWAN, LTE-M, Sigfox are all becoming industry-standard protocols that are each received in a different format. But they can be streamlined into one hub that intercepts the traffic and converts it into a protocol that the receiving application requires. By working with a partner offering all types of IoT connectivity in a blended solution, projects can be rolled out in the confidence that each protocol has been considered and is supported, to maximise the functionality, practicality and cost-efficiency of an entire IoT project.
Author details: Nick Sacke, head of IoT and products at Comms365
