In this week’s episode Matt looks at the emerging requirement in IoT for cloud connetors, as well as the associated topic of IoT SAFE. He also digs into findings from a survey last year on who are the most (and least) favoured vendors in IoT. Finally he shares some of the findings from Transforma Insights' work on connected cars.
You can access the podcast here, or via Google, Apple, Amazon or Spotify.
An approximate transcript of the podcast is available below:
Welcome to this week’s Wireless Noodle. Today I want to look at a few diverse areas, all related to IoT. The first is the concept of cloud connectors. This is an area we’ve been digging into quite a bit recently and it’s worth exploring. And I’ll also look a little at something called IoT SAFE, which is a related topic. Second, I want to share some findings from a survey we did actually last year, but it makes for interesting reading, related to which are the vendors in IoT that are most favoured by IoT adopters. Finally a quick run through some forecasts we at Transforma Insights did looking at connected cars.
Cloud Connectors
The concept of the IoT cloud connector has recently emerged as a differentiator for cellular connectivity providers and IoT platform vendors as mechanism for more easily delivering data from IoT devices into cloud platforms which are increasingly hosting IoT application data. The key role is to apply the appropriate protocols and security demanded by the cloud platforms and to deliver the data as seamlessly as possible.
In a recent report we looked at the reasons for the surging demand for cloud connectors, most notably the growing adoption of constrained IoT connectivity, and the functionality that the connectors deliver. It also examines the approach taken by some of the leading providers of this functionality, including connectivity providers, IoT platform vendors and vendors of device management solutions, and we also consider the commercial angle, including considerations of the expected demand for such capabilities, the positioning of this functionality and the competitive landscape.
There are three main trends driving the increasing demand for cloud connectors: the greater use of cloud when architecting IoT solutions, increasing reliance on constrained connectivity technologies and the demands of cloud providers relating to how data is delivered to them. The combination of these three factors create the requirement for cloud connectors.
First up, the growing use of the cloud. Put simply, more and more IoT applications need to deliver data to the cloud. While most IoT applications continue to deliver to on-premises servers, anecdotally the proportion shifting to the cloud is quite rapidly accelerating and within the next 5 years the majority of IoT applications will be hosted with the likes of AWS, IBM Cloud, Microsoft Azure and Oracle Cloud.
The benefits of using cloud are clear in terms of scalability and simpler integration of data storage and analysis. This is particularly exacerbated by the growing interest of the cloud providers in building their IoT capabilities, including aspects such as edge computing.
Another major trend in IoT is the increasing adoption of Low Power Wide Area (LPWA) technologies for connecting devices, including LoRaWAN, Sigfox, NB-IoT and LTE-M . According to Transforma Insights’ IoT Forecast Database, by the end of 2030 there will be over 4 billion devices connected using these technologies, up from a few hundred thousand today.
These technologies are deliberately designed to reduce cost and maximise battery life by reducing the functionality in terms of data throughput and frequency of communication. In so doing, these constrained LPWA connections tend to make use of a specific set of protocols designed for ‘connectionless’ rather than ‘connection-oriented’ communication . For instance, they tend to use the Constrained Application Protocol (CoAP) over User Datagram Protocol. The main alternative to CoAP is MQTT, but typically it would be inappropriate to use that as a technology in these constrained networks because they are much ‘chattier’, generating much more overhead. Up to 90% of the energy in sending MQTT messages is consumed just by the protocol handshake. For devices with no power constraints it’s fine to use MQTT. With power-constrained devices, generally it’s not.
The use of these constrained IoT devices (which I talked about a fair bit a couple of weeks ago) creates a bit of a headache for the cloud providers. The major cloud platforms support only a limited number of protocols for data delivery. All of them require the use of TCP-based protocols, rather than the UDP-based which are favoured by the constrained NB-IoT and LTE-M, and they all require encryption. Constrained devices cannot support end-to-end encryption (as it necessitates a much more data/battery intensive handshake for authentication) and cannot connect directly into public clouds.
These requirements from the cloud providers do not existing in a vacuum. There has been a gradual increase in the requirements for higher levels of security across the IoT and these requirements for superior levels of encryption reflect that.
As a result of not being able to deliver data using ‘other’ protocols into the cloud there is a requirement for a ‘cloud connector’, i.e. an element on the network where the data is adapted for delivery into the cloud. It handles encryption using DTLS (Datagram Transport Layer Security) and protocol conversion (typically from a third-party vendor such as IoTerop, Friendly Technologies, Tartabit or AVsystems).
Effectively this means that the transport layer security is applied from a point on the operator’s network (typically the connectivity management platform), with a reliance on network layer security within the network perimeter and up to that network node. In the report we go into some of the possible architectures.
The cloud connector functionality would typically sit at the operator’s Connectivity Management Platform (CMP) as the natural aggregation point.
So, the rise of constrained devices and the increasing demand for cloud integration will certainly drive the need for cloud connectors. These will become table-stakes functionality for serious connectivity providers. Direct monetisation will be difficult; they will instead form part of a set of functionality (spanning hardware, connectivity, application and more) positioning the provider as a trusted application optimiser. I talked about this back in Episode 28. Further to this, we will see more and more connectivity providers adopting cloud-native approaches to provide more seamless access for clients to cloud functions.
IoT SAFE
There’s also another related topic which has been the basis of another report I wrote recently, that’s IoT SAFE.
The ‘IoT SIM Applet For secure End-to-end communication’ (IoT SAFE) is a mechanism for ensuring end-to-end security for IoT data flows, from device to cloud. It establishes the SIM card (or potentially any other secure element) as a hardware ‘Root of Trust’, i.e. a source that can always be trusted. The IoT SAFE SIM removes the requirement for a dedicated hardware security module (HSM) and places its security function within the SIM card.
A software application is installed on the SIM to store private keys and certificates to authenticate the end device and provide credentials for the IoT application. It establishes Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) sessions with the other end point (typically a cloud server).
To ensure that communications over a public network are secure between end-points (e.g. an IoT device and a cloud server), both are given associated keys. The management of these keys has to be handled very carefully to ensure no security slips. In the case of IoT SAFE they can either be provisioned at time of manufacture or established by the mobile network operator or other service provider over-the-air remotely. In either case this allows for mutual authentication between the device and the cloud.
Essentially, IoT SAFE is about applying to end-to-end transport a similarly high level of security that SIM brought to network access. Rather than just authenticating the SIM onto the network, this authenticates the IoT application into the cloud. So, highly relevant in the context of cloud connectors.
IoT SAFE offers an upgrade on security for IoT devices and particularly for the increasing number delivering data directly into the cloud. It also helps with scalability of the provisioning of such devices. There are alternatives that are more applicable to constrained devices, in the form of cloud connectors, and demand is as yet unproven. While enterprises often highlight security as their greatest concern, it remains to be seen if they will embrace additional layers that come with some associated costs.
Check out the report we published on exactly this topic: 'IoT SAFE promises greater security for cellular IoT deployments but demand remains unproven'.
Who’s hot and who’s not in IoT?
Back in March Transforma Insights published a report ‘Hyperscale cloud providers are rated as top vendors by enterprise IoT adopters’ which looked at enterprise IoT adopters’ attitudes towards dozens of leading IoT vendors and the extent to which they were aware of and keen to use their products and services. The report includes a lot of analysis of the opinions of those enterprise IoT adopters, including which vendors’ IoT offerings they are aware of, which they have used, and which they would use again.
The report was based on a survey we did back in 2021. And we’re launching a 2022 into field now, looking at specifically connectivity providers.
Who are the most preferred vendors in IoT?
But what did the 2021 survey tell us? Well, firstly there is a notable top tier of vendors encompassing major IT vendors, particularly cloud providers, and a couple of communications service providers. The top 5 consists of Microsoft, Google, Oracle, IBM and AT&T, all of which score very well in terms of awareness of the products and interest in using again. Others in the top 10 include AWS, SAP and Verizon.
Overall, there is a very strong correlation between organisations using a particular vendor and their willingness to recommend them. There are two implications here. Firstly, that there is a group of vendors with which adopters have an established relationship and whose services they almost inevitably anticipate using in future. The second is that smaller vendors find it harder to establish stickiness with their customers. There are a few vendors that buck this trend and score relatively well on reuse despite not being particularly widely used, namely Deloitte, Deutsche Telekom and Verizon.
And who are the least preferred?
The reverse of the analysis is to look at a ranking of vendors by the proportion of respondents who have said they use them but would not use them again. The companies that score highest (or lowest, depending how you look at it) tend to comprise smaller IoT platform providers, such as Particle and C3.ai, and IoT MVNOs, such as Pelion, Aeris and Kore.
Connected cars
Back in June, Transforma Insights published our 'Connected Car Overview, 2020-2030' report, which provides a summary of our view across all of the various connected vehicle applications. I thought it was worth sharing a few highlights as it’s one of the hottest spaces in IoT.
In total the connected car space will grow to 2.5 billion connections by 2030. The single most important Application Group within the space is Vehicle Head Units, i.e. the factory fit telematics unit. Our recently published report on the subject will show 1.8 billion connected vehicles in 2030. In addition to this our Connected Car Overview report takes a more holistic view of the market and includes a further 0.7 billion aftermarket devices as part of its figures.
For mobile network operators, the connected car is one of the most significant sectors. It accounts for 28% of cellular connections at the end of 2021, falling only slightly to 26% in 2030. As a sector with a large number of mobile, high bandwidth cellular connections it’s perhaps unsurprising that Connected Car contributes 23% to overall IoT spend in 2030, despite having less than an 8% share of all IoT devices.
The automotive sector will be particularly important for 5G. Over 58% of 5G 'non-mMTC' (i.e. excluding the Low Power Wide Area technologies) connections in 2030 will be found in connected cars. Even so, LTE will still account for more new vehicles in 2030 than 5G does.
Of course, whilst connected cars are important for 5G, it is becoming increasingly likely that 5G will become equally important for the automotive space. Although IoT in the automotive space is now a fairly well understood and mature market, the 5G features around ultra reliable low latency communication (URLLC) has a crucial role in supporting vehicle-to-vehicle (V2V) and vehicle-to-everything (V2X) communication. If you want more of an explainer on that functionality, check out our page on 5G IoT.
These technologies are likely to play an expanding role in enhanced safety features in all vehicles, and will be vital for the successful operation of autonomous vehicles in the future. This will eventually become a driving force behind the adoption of 5G in new vehicles. That said, it’s easy to overstate the importance of connectivity technology in autonomous vehicles. They need to work autonomously whether or not they have connectivity. So, while 5G (or even 4G) connectivity is important, it can’t be something on which the vehicle relies.
All interesting stuff. Check out our various reports linked from a recent blog post. Link on the wirelessnoodle.com ‘Connected cars will hit 2.5 billion connections in 2030, driving cellular IoT and 5G adoption’.
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.
Next week I’ll be talking about a few interesting IoT protocols and functions. Specifically Matter and Thread which promise to open things up in the connected home, NWDAF which is an intriguing feature of 5G (but perhaps one for the future) and Lightweight M2M, the standard for device management.
Comments