In a world where the number of enterprise IoT devices is growing so fast that it’s hard to keep track, isn’t it about time they had their own network? How do we progress towards an IoT-Native environment where IoT devices can be efficiently connected to applications while maintaining a high level of automation across device and data management?
Actually, it’s possible now, with the introduction of Sprint’s dedicated, distributed and virtualized IoT core network. It’s the first such network in the industry, says Nishi Kant, chief technologist for Sprint IoT.
For a while, it was fine to keep IoT and cellular traffic on the same network. But as IoT devices have advanced and, in many cases, become absolutely mission-critical to the companies that deploy them, sharing a single network is no longer prudent because such a topology forces traffic to be first commingled and only separated later. Such traffic should be separated on earliest opportunity so it can have flexibility in routing and connecting to end applications.
“When you look at traffic characteristics and use cases, the IoT side is so different,” Kant says. “You may have meters that chirp only a few times a month and need low data rates, but then you may have drones that not only require higher bandwidth but can be extremely delay-sensitive.” A separate network can better accommodate those needs; for example, the delay-sensitive traffic could directly be routed from RAN edge to enterprise IoT application without affecting consumer traffic.
With a common network, there is always a risk that error propagation on one side of the network can bring everything down. A brief outage may be tolerable when you are dealing with a temporary inability to make a phone call or send a text, but not when it comes to intensive manufacturing processes, healthcare monitoring, or utility monitoring. In such instances, lost data to and from sensors could be incredibly costly or even affect public safety. Moreover, due to lack of user interface or absence of human at IoT troubleshooting requirements are likely to be different from a typical consumer scenario.
“These are not hypothetical risks,” Kant emphasizes. “There have been published reports internationally of network outages related to the mix of traffic on a single network. With such different signaling and storage patterns for these types of traffic, you inevitably have to make compromises when you try to carry both through the same software functions.”
Distributed network benefits
The distributed nature of the dedicated Sprint IoT network maximizes intelligence at the edge, tailors that intelligence to specific enterprise needs, and reduces latency for vital IoT applications.
Rather than move traffic a great distance to a limited number of national core network data centers, Sprint takes a smaller footprint approach, locating micro data centers as near as possible to where enterprises will need to do their data processing.
“Instead of trying to predict where IoT processing will be needed, this is a very flexible approach. If there are increases in IoT traffic in a particular area, or if a company plans a big deployment in a region, the packet core network can be brought right to them, rather than forcing their data to travel to a distant fixed location,” Kant says.
That brings up another good reason for a dedicated network, Kant points out, since IoT traffic patterns can and will be very different from consumer traffic patterns.
“You might have a factory far from a city, with lots of IoT instrumentation. The IoT traffic would then look very strong in that area, while the consumer traffic would be very small, since it is more remote,” Kant says.
Reducing latency is a major benefit of a distributed network since the processing is done so close to the generation of the data. Kant uses an example of a company in a mid-sized city that uses drones to deliver medicine.
“If your drone data had to travel to a distant city to the core and then come back to your command center, that longer path introduces unnecessary latency,” he says. And in an application such as this – or even more so with autonomous vehicles – every millisecond counts.
The distributed locations also serve as convenient hubs for bringing non-cellular devices into the fold. E.g., if an enterprise has both cellular and LoRa IoT devices as part of its operation, both can be brought together at these edge sites and then fed to the application. Devices and data can be managed uniformly, irrespective of how they are connected.
Because the Sprint network is dedicated, it was easier to make it more virtual. While most providers are moving to virtualization, carrying all traffic on a common network makes the transition from a “box-based” infrastructure to a virtualized, software-based infrastructure far more challenging and time-consuming.
“Being virtual means the enterprise and the provider don’t have to commit to a hardware footprint far in advance,” Kant explains. “They can deploy whatever is needed for the short term, and if they see traffic is exceeding expectations, adding capacity can be a simple matter of adding server blades and growing the software footprint.”
This truly dynamic response to traffic demand can also be less costly, since the need for idle hardware – sitting there just in case you need it – is eliminated. And at the same time, the capacity of the network can be shared.
“With self-contained units of network function, you can use the same hardware infrastructure to host a number of these units,” Kant says. “You get economies of scale that not only offer enterprises the fastest possible response times to their capacity needs, but also gives them more options and choices in terms of where and how they run their applications and how they choose to share their capacity with third parties.”
How is all this managed?
The Sprint IoT network operating system consists of a set of platforms for subscription management, device management, and data management and analysis.
- Subscription management is optimized for eSIMs – embedded SIMs in the IoT devices – and handles the entire lifecycle of those eSIMs as well as traditional SIMs.
- Device management encompasses all of a device’s capabilities and current states, for remote management for any IP-connected device, including any and all firmware updates.
- Data management and analysis is a broadly extensible capability, with a wide library of options already available. It offers ultimate flexibility in the way data is reported, how it is pushed or pulled from the IoT devices, and how it is aggregated, filtered, and directed for further data curation.
“The whole idea is to gain insight and focus on actionable, useful data out of the sea of data,” Kant notes. “With this platform, an enterprise can put its data into an analytics engine and perform analysis ranging from simple, rules-based processing through to comprehensive machine learning or AI analytics.”
Platform options are customizable to each enterprise’s need, Kant points out, and users can get as much or as little as they want of the device management or data management and analytics capabilities, depending on what they choose to perform in-house.
While the RAN, the radio access network, will be the first to be enhanced by the arrival of 5G, the distributed core IoT network will be in all the right locations to provide edge processing capacity and low latency path for 5G traffic.
Even with 5G’s capacity and low latency, an enterprise still needs an IoT network behind it that is able to maintain and enhance those latency gains, provide localized processing, and help turn data into intelligence in as little time as possible. That is the prerequisite for IoT solutions fully delivering on their promise.