If there’s too much latency in that journey, you’re going to see potential effects on your IoT application or service’s overall speed, reliability, and security. The market’s also seeing the rise of regulatory challenges in terms of data sovereignty and local regulations that add even more complexity in the mix—and so also impact efficiency.

Often, potential speedbumps occur at what’s called the point of ‘internet breakout’—i.e., the point at which data traffic passes from a public mobile network out onto the public internet. The problem is a lot of existing internet breakout solutions don’t offer deep, granular control over how and where remote IoT application traffic is routed.

That’s a serious vulnerability in the overall robustness of your IoT stack. Routing the data–without which an IoT application doesn’t really add value–to the home network via the public internet introduces delays, exposes traffic to security threats, and can’t be directly controlled by IoT service providers.
Without real visibility and the ability to quickly react and optimise your IoT data flow, then, you’re very much on the back foot. What’s needed: a way to control traffic at a granular level before it reaches the public internet.

Often, potential speedbumps occur at what’s called the point of ‘internet breakout’—i.e., the point at which data traffic passes from a public mobile network out onto the public internet. The problem is a lot of existing internet breakout solutions don’t offer deep, granular control over how and where remote IoT application traffic is routed. That’s a serious vulnerability in the overall robustness of your IoT stack.“

To achieve that, you need to work at the edge. If we can do that, then the application of control (policies) at the network edge offers considerable benefits; you’re going to protect the traffic, get optimised routing, and deliver better performance to the customers you worked so hard to onboard for your great IoT service.

You’ll also be safer. It’s simply a fact that when it comes to cybersecurity, the weakest link is almost always the public internet. That’s a bit unfair, as the internet was designed to allow anything to communicate with anything; that’s just perfect for applications such as the web, but for most IoT-style devices and applications, it’s far from ideal and just too clunky.

Using the right network for the right use cases

Really, then, we want to avoid the public internet as much as we can, as the kind of super-tight IoT communication we’re after here is only required between the device and a limited number of systems. The good news is that the basics are there to achieve this. Very handily, the world’s mobile operators are connected to a vast global network called the Internetwork Packet Exchange, or IPX.

Essentially, IPX a ‘private internet’ separate from the everyday internet. When mobile devices are in different regions–and particularly when they are roaming—calls and messages all use IPX to transport the data back to the home network from where it is forwarded to its destination. What we can do, then, is piggyback off IPX to get what we want here. That’s to say, we can use IPX to – in many cases avoid the internet entirely and use this cleaner pathway instead. Doing so will allow a service provider to control the path that this data takes, and in one move improve performance, reliability, and security.
For some IoT applications, this is even more compelling:

• Where performance is important for example, streaming applications such as security cameras benefit from low and predictable latency
• Where regulatory requirements dictate that the data must remain with a particular region or country – such as payment terminals or connected health.
• Where secure, controlled connectivity is required into a small number of central systems either hosted, or in public cloud.
• Where devices do not have sophisticated security capabilities of their own or are difficult to configure or control due to their location.

However, IPX on its own isn’t the whole solution – we need to add another ingredient. This home network can be geographically distanced from the device itself, and from the data’s destination, which introduces unnecessary ‘data miles’ making the whole end-to-end process complex and inefficient.

One approach is to use the features of edge to our benefit and create edge ‘hubs’ at strategic points on the global IPX structure. That helps a lot, as it immediately removes the need to bring the data back to a single, central point, and so brings significantly improved performance, as well as other benefits (of which a big one is making it easy to bring new connectivity tools like SD-WAN to the mobile edge).