Future-Proofing your LPWAN Device
Deployments for 5G Networks

Webinar Transcript

ARIELA ROSS: Alright, so I think we can go ahead and get started now. Welcome to today’s session on Future-Proofing your IoT Deployments for 5G networks. I’m Ariela Ross, Marketing Manager at Friendly Technologies, the IoT and Device Management Company. Today we are joined by technologist Sean van der Walt who is an IoT expert and our presenter for today. So without further ado, Sean, you want to go ahead and take over.

SEAN VAN DER WALT: Right, thank you, Ariela. Good day, good morning to everyone in Europe, Middle East, and Africa. I believe we have a number of attendees today from the region. Thank you very much. So without further ado, what we’ll do is start the presentation.

The plan for the presentation is I’m going to go through a couple of slides, and then I have a very quick demo at the end of this to just illustrate some of the points that I’ll be talking about.

So today, we’re going to be covering Future-Proofing your IoT device deployments. And we’re really presenting the case for these improvements here. Service providers have been investing quite heavily, moving from 3G to 4G in the past, and that investment involved supporting LPWAN topologies such as NB-IoT and LTE-M. And each of the different regions, whether it’s Americas, Europe, Asia, APAC, use NB-IoT or LTE-M, or both, depending on the particular target territory. So there obviously has been a deployment of IoT devices using these topologies to date. And so the concern now is with your fleet of devices and with the service providers, support of those devices, what’s going to be happening, moving towards 5G. And the standards body 3GPP and the RTU have defined these 5G NR specifications, I think post release 16. And so what that find the deployments of 5G networks at operators around the globe, what’s going to be happening with those older NB-IoT kept in one, or LTE-M IoT devices. So the following kinds of requirements arise when you start looking at what’s going to happen moving towards 5G. Will I be able to support a large number of devices with high connection densities? We’re looking at billions of devices, depending on their particular use cases. And if that spread over quite a big geographical region, will the 5G networks be able to cater for that? And in addition, will your NB-IoT or LTE-M device performance support that as well?

So the next is looking at sort of low cost or the continuance of low cost, because if you don’t want to go and put more expensive 5G chipsets or modules and have to swap 4G LTE to 5G chipsets, and it’s a very cost-sensitive area. And when we start looking at those very high-volume resource-constrained devices with a low footprint, very low amount of RAM, CPU flash, and a low chipset count, you don’t really want to be driving that price point up moving to 5G. The others are looking at ultra-long battery life. So looking at smart meters being able to be operational, in excess of 12-15, even up to 20 years. And how’s that going to be handled in the 5G environment with the new standards. Looking at also coverage in harsh environments, since 5G brings in higher throughputs depending on which categories you’re looking at, and thus using higher frequency spectrum that has an impact on range and penetration. So that’s another consideration for your spectrum being used currently on LTE networks.

And the last kind of major consideration here is that spectrum. So how will my NB-IoT, LTE-M fit into the new 5g NR schema. The good news is the standards body obviously forethought this and there have been modifications made to the standards for 5G NR to ensure that LTE-M and NB-IoT spectrum is catered for within the new spectrum scheme. And so that means that there is a natural future-proofing of your current NB-IoT or LTE-M supported IoT devices running off the current LTE or 4G networks will be operational or at least be operational on the new 5G NR deployments. So, essentially, that means that the standards are incorporated into the new 5G NR, and just so that we clear when we talk about LPWAN and NB-IoT, LTE-M, we’re referring to the CAT-NB1, CAT-NB2 for NB-IoT, and CAT-N1 and CAT-N2 for LTE-M.

So just as a reminder, I’m sure a few of you or a number of you have looked at these sort of figures before. But this just gives you an illustration of some of the main important categories within LTE-M and NB-IoT, and the ones we’re kind of considering here are CAT-N1 and CAT-N2, the higher throughputs on the M2 and as well as with 3GPP release 14, bringing in CAT-NB2, bringing in a few additional features and higher throughput. So really opening up more use cases, for those sort of low footprint devices being able to support higher throughput as well. And I think in the European environment they’ve been using the GSM standard. And they are obviously a number of NB-IoT deployments happening in Europe in some of the target territories, which is a good thing.

So when we start looking at protocols, in the future-proofing arena there are a few protocols that stand out. I’m not going to go and read and go through too many of these points, I’m going to give you a high-level summary. But essentially, the main protocols we’re looking at is, we talk about structured device management protocols and unstructured management protocols.

So a structured Management Protocol is the examples are LwM2M and USP. Those are defined by a standards body. Each one in that case has its own. And they have well-defined parameterization and well-defined processes for things like parameter updates, things like pushing firmware over the air updates, even software or container applications over the air. So there are very good definitions for all of that within those two protocols. I guess one of the standouts would be the firmware upgrade or firmware over the air is very well supported in those standards. So as far as functions are concerned, we’re also looking at the kind of standard ubiquitous IoT protocol one of them being MQTT.

MQTT comes with a set of challenges on its own, but it is a very easy protocol to work with since its publish-subscribe schema works quite well in disseminating telemetry data. again, although it is catered for by a standards body, it is not a device management standard. So what that means is, the topic structure for MQTT is not well defined for parameterization for many of the upgrades and these sorts of device management functions and features that we have. They have to be custom-defined and custom implemented in A management system or back end system to be able to cater to that device. So that means there could be a variety of different manufacturers supplying MQTT protocols for the different types of devices. And they will all be potentially implemented in different topic structures and it makes that a little bit more complex to handle.

And CoAp is sort of a real stripped-down unstructured protocol of being an application protocol. it is used by IoT edge devices. It is a very, very low footprint type protocol. But again, any of the data payloads, or parameterization, or firmware updates, and so forth are all custom defined and as such, presents some issues around integrating that. But from a future-proofing point of view, you can clearly see if you start standardizing on device management standards, which are well defined, there’s a lot of interoperability between edge devices and management systems.

So when we look at some of the features there, again, I don’t really want to go into great detail, I’ll give you a couple of highlights at points here. If we look at LwM2M and even USP, the two are, let’s say fairly equivalent in terms of their functions and features. There are some standouts. So LwM2M caters for in addition to IP based protocols, also non IP protocols, and we’ll cover a little bit of the NIDD, so the non IP data delivery type per edge device, and we’ll cover some of that. But for LwM2M it is a very, very well thought through, well-defined device management protocol for resource-constrained IoT devices. Payload mechanisms like CBOR, Opaque, TLV, and JSON, so different types of payloads can be defined and can be very, very optimized such as using a CBOR or even Opaque. And also supporting a good set of security schemas from edge device through the network, up to application objects. So the example is OSCORE support in LwM2M and supporting the full ambit of all the device management functions, including, most importantly, with LwM2M is the data orchestration components, so we call it to observe and notify. So that’s where you’re able to actually advise or configure, a set of edge devices in terms of what telemetry data you would like to consume from those devices. And the criteria for that, such as the update rates, or potentially out of balance values, or delta value changes, or so forth, that those updates happen then autonomously.

As far as USP is concerned, it’s quite a new standard. So from a data point of view, LwM2M was defined in February 2017, more than four years ago as version 1.0. And we’re up at version 1.2, which has been ratified as of today. USP is a fairly new, defined updated protocol from the old broadband TR-069, it’s now become TR-369 but with USP. And in this case, they’re again, very well-defined structures to handle the parameterization updates, firmware, and over-the-air updates, doing bulk statistics and telemetry and bulk collection of data from edge devices. And cloud-ready, right. I mean, we are talking about internet cloud integration capabilities. So you can see WebSockets and STOMP as a defined application layer of protocol. So there’s a lot of forethought brought into the new USP standard. MQTT as we’re aware, TCP based connection orientated and MQTT does present issues on low power devices. If the device is going into battery save or sleep, your connection sockets are breaking down, and it means extra overhead in the applications to reestablish sockets, and it just wasteful, there’s a lot of overhead, and so forth. With CoAP it’s obviously very streamlined. But again, the custom definitions for the payloads. There is some, obviously supporting TLS. But it’s probably not as optimized as LwM2M when we’re talking about that. So a big kind of con, there would be that end-to-end proprietary. You have to define the edge devices, payloads and parameters, and any workflow like firmware updates, and you have to really go and implement that in the Management Server again. And that also counts for the Management Server having to try and work with those types of different devices. It does present quite a big challenge.

Now, as far as performance is concerned, our device management protocols are LwM2M is designed for a very low footprint. So those battery-operated, resource constraint type devices, you can see in terms of bandwidth utilization, it is very low, in some studies, it is measured to be 88% more efficient than MQTT. 88% more efficient, that’s a huge amount when you’re talking about having to traverse data over a very narrow NB-IoT type per data channel. It just makes it much more efficient. But obviously, LwM2M being scalable, being able to provide high availability on the management server-side, and as far as the edge device and the management server is concerned, but for the edge, it’s a fairly low investment, because they are off the shelf SDKs and clients available for LwM2M since it’s been in operation for a number of years now already.

So similar for USP, except USP I would kind of more target and gear towards gateways and more complex applications. Maybe they generally could be powered, it could be battery operated, but generally, power type gateway applications where USP then quite excels in terms of their integration into the IoT and into the cloud domain. But again, having been able to have multiple servers, high scalability, high availability and there are some developments at present to provide open-source USP clients, and those are available of some of the standards bodies, and in this case, being the broadband forum.

Now, from an MQTT point of view, yes, typically a medium type footprint device. You do see them on a low footprint IoT device. But again, depending on the communication channel. If we’re talking NB-IoT, it does present problems using MQTT. So we’re really looking at those kinds of medium footprint type devices. Maybe always powered devices, so more bandwidth, more power consumption. And it’s a publish-subscribe protocol. So you publish and subscribe on topics and so it’s quite an easy protocol to work with. So that’s quite a big benefit for it. And probably one of the reasons why it’s quite widely used today. But again, there are no defined device management structures there and that presents always a bit of a challenge.

CoAp as you can see, very low footprint, low power consumption. But from an investment point of view, we would perceive it as a higher investment, because you have to go and custom defines all those data models for your devices, you have to really go and reinvent the wheel, and that makes a bit of a steeper investment curve there on trying to implement CoAP in an end-to-end solution.

When we start looking at those devices now, how do these things actually connect? So there’s usually a couple of different connection schemes. So from a management server, you can go through a cloud environment through the access network. So now luckily, 5G NR is supporting the NB-IoT, LTE-M devices. And that means we can connect through any of those access networks. So you can go through a cloud API type integration with devices typically those are like devices you might get from Amazon or like Google devices, Nest, and so forth. So one can do those two API integrations, but not very interesting. More interesting is those connected IoT sensors. So they’re either IP connected. So with the UDP or TCP, UDP stack on the edge device, in LWM2M we don’t need to use TCP. So we can have UDP, but IP nonetheless, depending on the type of protocol. And there’s also the possibility of using non-IP for NB-IoT and LTE-M. And I’ll go through that in the next slide. The other options are, you may have some on-site gateway with a particular type of RF connection. It may be like a 900 Mhz or telemetry, or 400 MHz telemetry type link, connecting to a bunch of IoT sensors. And in that case, a good option there potentially is using USP in the gateway. And then the gateway actually performs the USP translation back to the H device via the RF network. And last but not least, on that connection scheme is the lower end type gateway, that’s just one example. But generally, there would be an IP connection to it. And so using any of the sort of management protocols, so that’s one option. The other is LwM2M version 1.1 brings in non-IP management functions to LoRaWANdevices. So we’re quite looking forward to those sorts of projects coming up now. But that’s another whole topic to be talking about.

So from a Device Management Server point of view, of course, the data that is being ingested, so we call that managing that data through a data orchestration. The data orchestration in the device management platform basically chooses what devices, what parameter or what sort of resources, what parameters need to be monitored. And that then can be pushed up into big data lakes, which could be analytics platforms, cloud environments, or upstream applications. And that’s typically how this would be all put together. So from a device management point of view, you could have as it shows administrator, technician, or end-users in a multi-tenanted device management platform, and it could be a software as a service or a cloud-hosted service as well.

So from a particular device, point of view, we were talking about those constraint devices. So when we talk about LwM2M in this edge device, this is typically what the protocol stack looks like. And so the future-proofing here, there’s a couple of interesting bindings. So the standard of LwM2M for version 1.0 is LwM2M, CoAp, DTLS, UDP, or SMS bindings. And with version 1.1, and then the update on version 1.2, brought in some of these additional bindings. So you can run what we call cellular IoT. So essentially, and you can see the binding cellular IoT on the right. This provides for the non-IP data delivery from an application server to the UE at the edge. And we’ll go through that shortly. But it’s also providing bindings for lower end, so you can use TCP with TLS if you really wanted to. And there are a few other options there. So it’s very well defined, there’s a lot of support for it now. And there’s a lot of vendor manufacturers adopting LwM2M into the products. And I think security is quite a big important one. If you start looking at applications like metering, you want to make sure that there’s revenue-grade security built-in. And so the DTLS or TLS in this case, depending on which bindings you’re using, secures the device to a server, and OSCORE gives you the object application security as well. So there is multiple levels of security built-in.

We may look at an MQTT device, something like this, as I said it could be battery operated, but potentially a power device. So of course MQTT version 3 using TCP. So this is typically the protocol stack, either IPV4 or IPV6. But of course, you could use MQTT-SN for sensor networks that does operate over a UDP protocol. And maybe a little bit more optimized than using MQTT with TCP. But still, you have all those issues around those publish-subscribe topics and having to define all the management structures for that. So that’s typically what that would look like.

USP as I was mentioning, is well defined for forgetting these more complex gateway applications. And in addition to all the good features around parameterization updates, monitoring control, firmware updates, and so forth, there are also the abilities to push container applications to edge gateways. And as I said there are internet cloud-based integration capabilities, which LwM2M has as well, but that comes in from an application server point of view. However, the USP protocol now caters to a lot of that native integration.

One of the ways we’ve looked at doing a gateway integration, we’ve used, for example, MQTT clients in the device, and we’ve had, Zigbee, Z wave sensors. So typically, this is used in our smart home platform. And so the MQTT, Zigbee, Z wave-type client built into the gateway caters for the translation of all the parameterization. So we’ve built in the data structures for doing device updates, being able to collect sensor information, being able to control actuators on the edge of the Zigbee network. So that is an all-complete and integrated end-to-end solution that we have already implemented.

Alright, just talking about some of the clouds. So this is a screen that generally kind of explains what our integration at a carrier network would look like. And so within a carrier network deployment, you’ll have a device management platform. One of the beauties of this is that we’re treated as a central device registry. So that means an operator doesn’t need to have a myriad of management platforms for different IoT verticals like one for telematics tracking, and another one for smart cities, and another one for metering. So when you’re using the management standards, like LwM2M and USP, and you’re using this device management platform, you can bring onboard any of your devices in the field. So you’ve got a single asset registry, you’ve got a single point of contact to do complete end-to-end lifecycle management on that device, from provisioning, all the way to de-provisioning to firmware updates, and any configuration and so forth, optimizing between. You’ll notice in this diagram, there’s our RDBMS database, which’s the device management data. So all the kind of parameter updates. And then there’s a real-time database. And that’s the time series database. That’s the store for all the monitored data, telemetry data coming in from all those edge devices. And there’s a number of ways of getting this up into upstream applications. And I’ll give you a quick view of that shortly.

So, apologies I needed to mention. So when we are talking about 5G NR, you will see operators deploying SCEF elements in their network. And that SCEF element allows us to onboard non-IP edge devices. So there are there’s a mode in NB-IoT and LTE-M for the modules to work in a non-IP fashion. So in a non-IP fashion, what we do is we have integrated with a number of the equipment vendors providing SCEF and we do that through that t8-API as indicated on the diagram. And so to illustrate that in a little bit more detail, the 3GPP and the LwM2M standards talk about this integration at great length and so this has already been integrated. So when we look at LwM2M protocol stack in the UE, the edge device on the left here, you will see their data paths, whether using SMS bindings, or the IP or if you’re using non-IP through SCEF. And those are the various mechanisms of getting to these types of NB-IoT or LTE-M devices, the edge.

On the right is giving you a bit of an interface diagram. And what we do with our LwM2M server is we use that t8-API for MT and Mo, and also for triggering any device wakeups, and so forth. But the non-IP interface comes in through that t8- API. With the t8-API integration, it means we can then also register the device on the central device registry and we can perform certain actions on that device as well.

One of the big integrations that have been done is we’ve actually integrated our One-IoT engine, so this is a device management engine. And we’ve provided a protocol bridge for the AZURE IoT environment. Now, why would that be needed? AZURE IoT already caters for things like MQTT and AMQP and a few specific protocols, but AZURE IoT doesn’t cater for LwM2M, they don’t cater for my OMA-DM, USP, TR-069, and so forth, and some of the other custom protocols. So what our bridge interface does, is it actually provides a central device registry again. And when any device is registered on our platform, a device twin is automatically created dynamically, as well as a device template. So the device twin will be the digital copy of the physical device in the field. And so any updates or even firmware updates on the device will be actioned on that physical device twin. And the device template is provided dynamically in IoT Central so that when you develop a dashboard or IoT application in IoT central you have all the interface options to be able to control or update your device twin and consequently, dynamically, asynchronously, the physical device is updated at the edge. This is something we have finished released on November 20, 2020, so last year, and this is a very exciting development. But the same thing, the similar concept could be done with Amazon and Google, and other clouds as well. You’d ask why is this important? Well, if you have IoT enterprise applications you’re developing in AZURE you may want to actually develop your IoT dashboard applications in AZURE IoT Central. And by doing this, you get full end-to-end integration for all your device feeds.

There are other ways without performing all those IoT device twin, and it has certain features and functions. But if you just want to do daily ingestion and do data analytics, and you want to do specific applications in your enterprise application, there are various ingestion options here, you could utilize a REST API, or any of the stream queues, such as we already do, Kafka and AMQP protocol streams up into Cloud. And the same with Pub/Sub, and any of the other kind of main standard stream queues. So those stream queues allow the various different cloud environments to ingest that data directly into the cloud environment. And we have a multi-tenanted approach to that in the management system. So that means sub-tenants or lower-level tenants can actually set up their own connection streams, and then [inaudible 34:38] AZURE IoT as well as these AZURE upstream cloud interfaces.

So quickly, I want to get to a conclusion and give you a quick view of what this looks like with different protocols pushing data and displaying that. So from a conclusion point of view, so moving into the future, and being able to support IoT, these NB-IoT, and LTE-M devices in these 5G NR networks, you want to really try and focus on these standards-based measurement protocols. So whereas far as possible, you’re defining devices or getting manufacturers to develop devices, they generally will try to take the easy route, as in just reuse MQTT that they may have had in something else. But if you’re following a standards-based approach with light-weighted frame or USP, it provides for all those benefits we were talking about earlier. Using these optimized management protocols like LwM2M you get much lower power utilization. So that really helps to keep your devices going for a longer period of time, even on the 5G NR networks. Efficient over the air transmissions, so both management data and telemetry data, interoperability between devices and management servers, built-in security mechanisms from transport protocols, for data protection, and application security. So that’s quite an important one to focus on. Some of those, like the CoAps and the MQTTs and so forth generally won’t have some of the more advanced security mechanisms that an LwM2M USP has. And so of course, a big one is there’s adoption by some of the bigger carriers and customers around the world, as this is a very shortlist. But you have tier ones adopting LwM2M in the deployments of the IoT applications.