How will 5G affect the connected devices I am designing now?

It’s worth a short recap at this point of how cellular technology has developed over the last two decades in terms of connecting small devices such as asset tracking systems and remote sensors. The most widely adopted system has been GPRS, which is part of an evolved 2G cellular system sometimes referred to as 2.5G. GPRS is specially targeted at slow, infrequent data connections, making it a suitable choice for these usage scenarios. As 3G appeared and became common, GPRS was still used for low data volume applications as the infrastructure and electronics were cheaper for 2.5G than 3G. 4G has seen a further push towards greater bandwidth for mobile web browsing applications but has relatively few benefits for so-called IoT devices, resulting in vast numbers of small cellular connected devices continuing to use GPRS rather than migrating to 3G or 4G.

In 2016, two new LPWAN (Low Power Wide Area Network) cellular radio standards were proposed, known as NB-IoT (NarrowBand for Internet of Things) and LTE-M, a reduced data-rate variant of standard 4G LTE. These have seen a relatively slow adoption due to the need for upgrades to the network infrastructure and high cost for the device electronics. However, the signs are that take-up is now rapidly increasing as older 2.5G networks are switched off in favour of 4G and network operators look to prepare for the mass usage of connected devices.

Back to 5G then. 5G covers three categories of communication, intended for different sets of uses and operating conditions. These categories are Enhanced Mobile Broadband (eMBB), Massive Machine Type Communications (mMTC) and Ultra-Reliable Low-Latency Communications (URLLC). The three categories are at different stages of development, with eMBB leading the way to demonstrate headline figures of throughput, but with mMTC and URLLC still some years away from useful deployment. Cellular LPWAN is a subset of mMTC, with URLLC intended for a role in industrial and automotive sectors.

So what of NB-IoT and LTE-M then? Will they be replaced by 5G mMTC, just as they are gaining more widespread adoption?

Rather than move the goalposts for cellular LPWAN again, the 3GPP consortium that develops the standards has pragmatically decided that NB-IoT and LTE-M will instead be adopted into 5G. This means that developing a connected device incorporating these technologies will be inherently future-proof and will work with 5G networks as these come on stream. While there will undoubtedly be some additional benefits that can be utilised when the full 5G network is available, the core functionality and compatibility of NB-IoT and LTE-M will remain the same, meaning that development can be carried out with confidence.

In terms of timelines, although NB-IoT and LTE-M have been included in the standards for three years, it is estimated that widespread adoption is only likely to happen over the coming three to five years. This is partly due to the infrastructure upgrades required to provide acceptable coverage, but is also due to the current electronics cost, which even in China is still above $3 at high volumes, compared to a typical Bluetooth solution of around $1. The power consumption is also significantly higher than Bluetooth or competing non-cellular LPWAN solutions such as SigFox and LoRa. However, for connected devices where power is not quite so critical, this is not a limiting factor. The electronics costs will also fall over time as volumes increase.

While 5G is an exciting new technology that will undoubtedly offer significant benefits in ultra-high density, bandwidth-hungry locations such as city centres and football stadiums, the 3GPP consortium’s decision to simply absorb NB-IoT and LTE-M into 5G means that designing a connected device to these standards ensures future compatibility; therefore there is no need to wait for the roll-out of 5G before developing cellular IoT connected devices. The advent of 5G simply reinforces the argument for considering cellular IoT connectivity.
 

Written by Richard Gledhill, Senior Software Skill Leader and Piotr Pajakowski, Software Engineer.