The IoT explosion: what can network operators learn from SMS when implementing IoT
The Internet of Things market is growing at an exponential rate. It’s set to quadruple in size, growing from $900 billion in 2014 to $4.3 trillion by 2024[i], with more than 30 billion connected devices in use. But the huge number of devices and subscribers accessing the network will have consequences for operators. Operators will need to prioritise traffic – can you imagine if the smart grid were to stop working to prioritise advertising boards?
If you think back 20+ years, this could be likened to the advent of SMS. When SMS started to take off the volume of messages posed problems for the voice network. This was due to voice calls being susceptible to the smallest delay which caused connections to drop. The solution was to offload SMS messages and reroute them to give the priority to voice – the revenue generator. This problem wasn’t anticipated and the solution was a reactive rather than proactive response from the industry. Service providers risked missing out on revenue generating opportunities as they weren’t prepared this change in consumer behaviour.
So what can network operators learn from SMS when implementing IoT? How can they ensure that networks are architected in advanced rather than waiting for the latency problem to arise as it did with SMS? What do they need to do to make sure that the revenue earning applications are not impacted if there is too much traffic on the network?
Firstly, it’s paramount for operators to have an understanding of how to build a network that will be able to cope with the level of traffic expected as well as the different use cases, throughput requirements and power consumption across IoT applications. There are a number of different applications – some have high data throughput such as augmented reality or a low tolerance of latency such as smart home control. Not ensuring that the right network architecture is in place for each application could have a detrimental effect on the Quality of Experience (QoE) for the end user. Similarly, the amount of connections as well as the sheer number of applications are likely to cause concern. The underlying transmission protocols, Stream Control Transmission Protocol (SCTP) and GPRS Tunneling Protocol (GTP), need to be able to support the huge number of IoT connections trying to access the network simultaneously.
The question then for operators is how to maintain enough capacity in the network, and more importantly, manage the connections for the revenue generating traffic without creating bottlenecks? Typically, GTP solutions have been able to handle up to 25-30,000 Packet Data Protocol (PDP) contexts per application but operators now need to be looking towards coping with millions if not billions in light of the expected rush to be connected. By foreseeing this huge surge operators can prepare appropriately rather than waiting for it turn up unexpectedly at their door. By enabling GTP processing to be off-loaded, traffic capacity can be increased by accelerating data paths and removing bottlenecks, which in turn, accelerates the GTP tunnels and packet filtering. This results in higher performance and vastly improves QoE.
Typical network architecture for IoT deployments also show that backhaul connectivity from RAN to the core network can be accessed through any method of public internet broadband connection. A dedicated connection is not required and can be deployed without additional investment in backhaul. If there is no intolerance to low latency the core network can be hosted in the cloud. Even access to the core network over the internet is available if QoS is not important. Multiple IoT application servers can be hosted on the same cloud based Evolved Packet Core (EPC).
Millions, potentially billons, of connected IoT devices is very different than having large numbers of traditional subscribers connected so the EPC must be able to scale accordingly. As a result, many operators could host a parallel LTE network only for IoT devices.
Network analysis through Deep Packet Inspection (DPI) can also be pivotal in developing the network infrastructure for IoT. With DPI, operators can ensure their infrastructure is able to cope with demand by identifying how and when end-users are accessing the network. It’s important for operators to have packet processing capabilities that are aligned with rapidly increasing data consumption habits, but that are also fit for purpose when it comes to a smarter network.
It’s clear that IoT and the promises it brings are set to heavily shape the telecoms industry. Consumer demand to be consistently connected and to digitally communicate with anything from another phone to our kettle and many industrial applications such as industrial robotics and environmental control, highlight that this phenomenon is not going away anytime soon. As a result, the reliability of these connections will become vital for the growth and success of the IoT revolution. Dedicated IoT networks are being implemented and many are predicting that 5G will go some way to supporting the vast number of connections, but there are still likely to be problems with performance and reliability if the right solutions aren’t implemented.
For now, it’s important for operators to understand how SCTP, GTP, DPI and EPC can work both separately and together to enable the capacity that mass scale IoT network deployments will need. As new technologies develop that require network connectivity, it becomes incrementally important that basic network requirements, such as a reliable signaling process, are prepared and fully functional for IoT technology to run successfully and generate revenues. By being prepared and ensuring that they are not caught unawares as they were with SMS, operators can ensure that this technology is successful not just for them but also for the consumer.
[su_box title=”About Robin Kent” style=”noise” box_color=”#336588″][short_info id=’104741′ desc=”true” all=”false”][/su_box]
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.