Wireless Noodle Episode 28: What is constrained IoT?

This week's episode looks at the concept of constrained IoT, delves into some recent headlines concerning particularly M&A in the IoT space, and a look at recent developments in embedded SIM. 

You can access the podcast here, or via GoogleAppleAmazon or Spotify

An approximate transcript of the podcast is available below:

Welcome to this week’s Wireless Noodle. This week I want to mostly delve into a particular aspect of IoT, related to cellular-connected devices and that’s the concept of ‘constrained IoT’. There’s also a bit from me about the fate of Sigfox (which is a good example of a constrained technology if ever there was one) as well as a look at some other news that’s been making the headlines and a dive into eSIM and iSIM. 

Constrained IoT 

A few weeks ago I spoke about an article I wrote in IoT Now which is well worth a read. Well, I thought I’d run through some of the highlights for you dear listeners.

Increasingly, IoT is focused on addressing lots of devices in increasingly inhospitable environments. It does this by slimming down the features and functionality of the offering to make it more appropriate. Last year, we at Transforma Insights published a report on what we termed the ‘Thin IoT stack’. It looked at a set of technologies across the IoT stack that are specifically aimed at dealing with the constraints of power, location, space, processing and several other factors. Across each of five layers of the IoT stack (device hardware, device software, networking, middleware, and edge computing and machine learning) there are optimum technologies including system-on-chip, chip-on-board, embedded operating systems such as TinyOS and RIOT, networking technologies such as MQTT, CoAP, and LPWA technologies, thin middleware, and data processing techniques such as TinyML. All of these elements of the IoT stack, that are now optimised for IoT are potentially useful for IoT deployments, and will provide a boost for the markets. If you’re interested in the Thin IoT concept more broadly, I recommend checking out the blog post 'The five ‘P’s that constrain IoT and necessitate the ‘Thin IoT’ stack' I wrote on it recently. 

Wide area connectivity for IoT is increasingly defined by the arrival of technologies to overcome constraints, particularly battery life. The whole reason for the development of Low Power Wide Area (LPWA) technologies a decade ago or so was to operate where there are constraints on the availability of power. According to our IoT forecasts here at Transforma Insights, LPWA technologies (both licensed NB-IoT/LTE-M and unlicensed such as LoRaWAN) will account for 64% of all new public network connections in 2030. There is also a lot of hype today about the potential for low earth orbit (LEO) satellites to address IoT, something I spoke about in Episode 25.

Local area networking is also getting in on the act. WiFi has historically dominated this space, at least for indoor consumer connectivity. However, we expect Thread, off the back of the standardisation of the Matter smart home interoperability protocol, to become increasingly widely adopted. So be aware anyone not already working with Thread/Matter. You should be. Details of our recent report are here: 'Will Matter (and Thread) help vendors finally crack the smart home market?'

The constraints of low bandwidth low power devices will also dictate the choice of protocols used. At the Transport Layer, most deployments will choose between the IP protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP is ‘connection-oriented’, i.e. it will need to establish two-way communications with the receiver, deliver data packets in the correct order and to resend any lost packets. In contrast, UDP is ‘connectionless’ meaning that it will send data packets without consideration of whether the recipient is ready and won’t seek acknowledgements of receipt or retransmit lost packets etc. The result is that UDP is a lighter protocol and therefore far preferred for constrained IoT. There are further implications for the associated messaging protocols: MQTT and CoAP. Both were designed to make efficient use of network resources, but CoAP is inherently more appropriate for constrained environments, being based on UDP. MQTT is more secure and provides more of a guarantee on delivery, but it is chattier.

Also closely related to protocol selection is security. The aforementioned CoAP/UDP has a more limited set of security capabilities than TCP-based deployments. It’s not inherently insecure though. Most IoT security issues relate to the hardware or the application rather than the networking. Nevertheless it’s a little less secure.

This creates challenges for delivering to the cloud, and particularly drives a need for ‘cloud connectors’. AWS and Microsoft Azure will not accept DTLS-based security (i.e. the kind of security supported by UDP). This means constrained IoT devices, i.e. the majority of IoT devices, need some kind of proxying and protocol conversion for them to be delivered to the cloud. The solution is a cloud connector, where data is delivered to a network element, which handles protocol conversion and encryption to then deliver to the cloud. A number of communications service providers such as EMnify, Telefonica and Verizon have this functionality. Ericsson also has it as part of its IoT Accelerator.

There are several other areas where there are further implications, including device management (which I’ll talk about in a few weeks in the context of Lightweight M2M) and edge computing. But they’ll have to wait.  

I will, however, mention one final element – probably the most critical – the application. Here there is an overwhelming need to adapt the application to suit the constraints in which it is being deployed. Highly ‘chatty’ applications will cause havoc for low power devices, or where the devices can only send a few messages a day. 

The overarching trend, and one that we come back to again and again is that there is an increasing requirement for the constituent elements of the application to be optimised with each other. That includes hardware, connectivity, protocols, device management, data processing, networking and the actual application itself. Many technology vendors increasingly get that. Take, for instance, the offering from Wirepas, which optimises across connectivity and hardware, or like Deutsche Telekom IoT’s IoT Solution Optimizer, or the recent announcement from Eseye for its Infinity solution, which includes a connectivity optimisation capability, or the recent announcement of Semtech’s acquisition of Sierra Wireless. More on this in a bit.

Top priority for anyone building an IoT application is to ensure that all these elements are optimised to work with each other. Easier said than done, of course, but there is a clear future path towards much greater requirement for the supply of these aspects to be done in a coordinated way. If you want to know more about this, check out the article where I go into a bit more detail on a few areas.

Hot M&A news

I mentioned it earlier, but the big news of the last few weeks was that Semtech acquired Sierra Wireless and Telit merged with Thales’ IoT hardware business. 

On Friday 29th July Telit and Thales announced that they were combining the assets of Telit with those of Thales’ IoT hardware business into Telit Cinterion. That was followed on 2nd August by the news that Semtech Corporation would acquire Sierra Wireless.

These announcements affect all three of the triumvirate of cellular IoT hardware makers that dominated the global market as little as a decade ago. Going back ten years, collectively Cinterion, Sierra Wireless and Telit accounted for the majority of IoT shipments. However, since then competition has bitten and they now find themselves as minority players.

The requirement to gain scale in the face of (particularly Chinese) competitors goes a long way to explain why each would want to find greater scale. But the two deals demonstrate a rather different approach. Telit Cinterion is a straightforward merging of like companies. The Semtech/Sierra Wireless deal has more complexity, given Semtech’s position as the leading player in the LoRaWAN ecosystem.

We believe that the Semtech/Sierra Wireless acquisition will have by far the greater impact. It creates a vendor with a broad and complementary set of capabilities, whereas Telit Cinterion is simply a scale game, albeit important for the future of Telit. However, to really benefit from the combined assets, Semtech will need to find ways to cross-optimise the various IoT solutions elements that it provides, rather than simply act as a one-stop-shop.

On the subject of recent acquisitions, actually not that recent. But back in April, to end a long running saga, including a bidding process, Sigfox was acquired by one of its Sigfox Network Operators, UnaBiz, which operates in Taiwan and Singapore. Then as of July this year, Unabiz announced that Sigfox will continue as a technology (what it was best at) and not as a company (well, the least said about that the better). I still think there's room in the market for this kind of very low bandwidth, very high latency tech. There's plenty of use cases that will be fine with that. Assuming it can be delivered at an appropriate price point (which was also a big issue for Sigfox). That and the fact that LoRaWAN has been pushing on in recent years.

And last but not least, on the 16th August it emerged that Google Cloud IoT Core is being retired on August 16, 2023. It’s what I’ve described as the most Google of moves. This is exactly what I was talking about in my ‘Does Google Cloud have a trust issue’ blog post 18 months ago.  and also on episode 18 of this podcast. How can you trust a company that just retires products that become inconvenient to run?

eSIM and iSIM

Finally, I wanted to talk about eSIM and iSIM. It’s something I’ve talked about a bit a few times on the podcast. Over the years the SIM card itself has shrunk in size and eventually become a piece of embedded hardware, in the form of the eSIM in 2016. And since then has then the integrated SIM (or iSIM) arrived in 2018 seeing the SIM functionality become software-based and implemented in a system-on-a-chip hardware.

The embedded SIM provides a number of benefits in terms of being able to build IoT devices that are smaller, more robust and more secure. However, the biggest implication comes from the fact that the SIM card is not removable. As a result, it was necessary to develop the capability to change the SIM profile through a mechanism other than physically swapping out SIM cards. That mechanism is remote SIM provisioning (RSP). This could be considered another additional benefit of embedded SIM (along with security, size and ruggedness) but it is not an exclusive feature of embedded SIMs. Remote management is a feature that could also be applied to removable form factors too. 

RSP was specified by the GSM Association in 2014, initially for ‘machine-to-machine’ (M2M) devices, and then in 2016 for consumer devices. It consists predominantly of the management of IMSIs (International Mobile Subscriber Identities) on the device, i.e. adding, selecting or deleting IMSIs as appropriate to connect to the correct network. I won’t go into the specifics of how the RSP provisioning works other than to note that the ‘Consumer’ pull variant worked a lot better than the ‘M2M’ push variant, but the lessons have been learned and there’s a sort of hybrid ‘IoT’ version is imminent. So some of the bumps have been ironed out.

This has a bunch of commercial implications. Regulatory compliance is a lot easier as you can avoid being clobbered for permanent roaming infringements. Supply chains are more efficient because there’s no need to ship a SIM. It offers insurance against network switch off. And theoretically it allows the customer more ability to negotiate with connectivity providers. I say theoretically because really almost no-one has used it in anger. Today it’s used as a way to localise connectivity, and as an insurance policy. That’s how we see it. And that’s backed up by the fact that a lot of the providers of these services (i.e. mostly the old SIM vendors) seem to be pivoting to selling based on a flat fee licence rather than per switch that they were previously anticipating. 

We’re certainly not down on eSIM though. It can drive out a lot of cost in the lifetime of the device due to compliance, supply chain efficiency, lower power and other factors. Check out the white paper we wrote with Quectel for more details: New study shows 8-13% saving on lifetime connectivity spend from using eSIM/iSIM in IoT . 

Next week

Just a reminder: if you’re enjoying the podcast I’d be obliged if you could leave a review. It’s much appreciated. 

What else do we have for you today? One request and one plug. The request relates to 2G and 3G switch-off as mentioned a couple of episodes ago. The request is to hear from anyone who has been through a 2G (or 3G) switch off process themselves. We want to hear about experiences from real world customers. So if you know of anyone who has been through one or you are someone who has, I’d love to speak with you. Can be completely anonymous and we’re happy to share results of the findings of the research.

And another plug – we have a stack of webinars coming up. We announced our 2022/23 series of webinars a few months ago. They’re coming up on the 26th September, looking at 5G and mobile private networks (aka private wireless). In November we’re looking at how Digital Transformation will save the planet. That’s all tied up with the Clean Dozen work I spoke about earlier. In January we’ll provide a summary of the work from our annual CSP IoT Peer Benchmarking Report, which is due out in Q4. In March we’ll delve into the opportunity associated with applied AI, and in May next year we’ll share our IoT forecasts.

Next week I’ll be talking about the fun task of forecasting the AI market, a bit about a new network technology 5G RedCap, and we’ll take a walk through smart metering of all stripes, electricity, gas and water.

I hope you can join me.

Comments