Beyond Voice, SMS and IP services In IoT

Mobile networks started off with voice, SMS became a success by accident, and by the time 3G data usage increased mobile networks took off and now 4G seems to have enabled video everywhere. In IoT, the dominant used service on a mobile network is data usage – either on the public Internet or via private channels (APNs).

So, after having said this the question is obvious: Is this it? Are new mobile services not evolving? I would say that they absolutely are evolving – particularly in the IoT space.

What are the upcoming service evolutions, then? I think that everybody in our industry knows by now that when it comes to low-power wide area (LPWA) standard development organizations, vendors and mobile operators have responded to LORA/SIGFOX with standardized technology known by the names NB-IoT and LTE-M (also referred to cellular IoT, cIoT). The industry couldn’t wait until 5G was standardized, hence an intermediate step for cellular IoT has been defined.  While a lot of focus has been on radio technology related access aspects it is somewhat lesser known that a further service evolution beyond voice, SMS, and (IP) data has been defined. Some service evolutions have occured before 5G standardization, but also during 5G standardization. This post will go through both.

IoT evolution: Non-IP Data

For certain  IoT use cases – for example, smart metering or temperature readings – it is all about exchanging a small piece of information instead of a large quantity.   When we talk about mobile data today we mean that a device has an IPv4 or IPv6 address and we encapsulate the application data with  IP (and also TCP/UDP) headers before transferring it to a device.

Although this proven concept is very successful it is not very efficient when you just have a meter reading of a few bytes. Then non-IP data (sometimes also referred to as small data) comes into play: why not remove all the overhead and only transfer the data itself over the radio interface?    Or, why not re-use SMS? Unfortunately, that is not possible due to SMS requiring MSISDNs and also being text oriented. So it is really not the best tool for the job. Non-IP data also re-uses existing proven cellular encryption end-to-end, so everything from the device up to the mobile core network is encrypted and authenticated, which is also the case with SMS.

Non-IP data implementation options

There are two ways you can exchange non-IP data with a mobile network for an IoT use case:

– API driven: In this scenario, the operator has an API which exposes non-IP functionality into the network.  A new operator-based network element called Session Control Exposure Function (SCEF) makes this possible. A SCEF will provide the IoT application with a  secure interface where the data can be dropped or retrieved from the device, usually via both push and pull mechanisms – a great solution for developers since they do not need to understand any network technology and only interact with an API. The API is specified in Open API 3.0 format and standardized by 3GPP in TS29.122 (it uses the 3GPP Common API Framework from Release 15), so if all operators implement that it will be a more common approach. API driven also has a huge security advantage due to the fact that a device does not have an IP address, which means that it is not reachable on the Internet.

Some of the drawbacks are that it cannot re-use an already established operator roaming ecosystem (it will take time before this becomes possible), and that if you want to use the Non-IP data service from different operators then you could potentially end-up with different APIs.

-IP/UDP tunneling: In this scenario, the edge of the mobile network (the PGW in the mobile core) adds an IP and UDP header when the data leaves the mobile domain. To send data towards a device the server sends the data to a per-device assigned IP address and a well-known UDP port. The mobile core then strips all headers before transferring it across the mobile domain (but still encrypting it as it does with all other traffic).  To receive data on the servers the process is reversed and data is also sent to a well-known UDP port. If we compare the two options quickly their main characteristics are:

5G evolution: Ethernet

In 5G the service evolution continues – voice is still the top via IP (as was already done in 4G via VoLTE), SMS remains,  and IP data and Non-IP data (referred to as “unstructured” in 5G) continue to be supported.  So, in which direction can technology now go?  The key lays in the first 5G use case, which is the further evolution of mobile broadband (more or less competing with DSL, Fiber, and DOCSIS).  Instead of going up the protocol stack (and removing the headers) we are going down the stack adding another header: Ethernet.

In 5G the standards will allow ethernet end-to-end from the device all the way up to the edge of the mobile network (instead of previous generations where it starts at the IP layer),  so you can address a device by MAC address. And on that note, I expect VLANs at the demarcation point, which potentially will identify connections towards devices.

It will be interesting to see how this will develop in the market over time and if we will be able to make use of it in IoT use cases as well. We already see customers who do overlay tunnels (having a burden of overlay protocols). Maybe we can help these customers by providing layer 2 services? Anyway, still a few years to get there, but we will for sure keep an eye on it!

So, to conclude: it is from Voice, SMS, IP data towards a non-IP data and Ethernet that the mobile service world is evolving.

And note! It is 2G, 3G, 4G, cIoT and then 5G. A lot is already happening with cIoT today in mobile networks. Don’t make the mistake of missing the cIoT boat just because you are waiting for 5G.