As IoT volumes have grown, and the concept has become increasingly mainstream and business-critical, so a number of vendors have entered the market with capabilities that are intended to ease the task of IoT solution development. One key area that vendors have focussed on is the concept of the IoT platform.
IoT ‘platformisation’ sees software capabilities that previously needed to be built from scratch or adapted from existing other middleware being replaced by purpose-built platforms to simplify the building and deploying of IoT applications. There is a wide range of platform types, including:
This hierarchy is illustrated in the chart below, with Connectivity Management at the lowest level and progressively getting further removed from the end (IoT) device up the stack. In general, each platform type is dependent on the platform types beneath it:
In the sections below we consider a selection of these platform types in more detail, including Connectivity Management Platforms, Connectivity Platforms, Device Management Platforms, and Application Enablement Platforms.
Connectivity Management Platforms (also known as Connectivity Support Platforms) help typically mobile operators to configure and manage cellular connections for IoT devices. They interface to other platforms (such as, for example, AEPs) typically via APIs and will manage the activation, subscription management, network connectivity administration, and billing/rating for cellular connected IoT devices. Increasingly they will also manage functionality related to eSIM, such as SIM profile changes. Additional functionality includes things like anomaly detection and enhanced billing capabilities that combine usage across multiple different mobile networks.
The overall aim of Connectivity Management Platforms for IoT is to enable the management of cellular connections supporting IoT devices at a significantly lower cost point than more traditional cellular network management software, and to enable quick and cost-efficient scaling.
There are two dominant third party providers in the Connectivity Management Platform space (Cisco and Ericsson), and a range of smaller players. Some mobile operators and mobile virtual network operators (MVNOs) have chosen to develop their own in-house platforms, as has been the case with Vodafone. The number of options for Connectivity Management Platforms has grown in recent years as MVNOs and mobile virtual network enablers (MVNEs) seek to license to third party MNOs and MVNOs the capabilities that they have developed in-house.
A Connectivity Platform differs from a Connectivity Management Platform in that it actually delivers connectivity, ideally providing a seamless ‘single pane’ interface to a range of connectivity technologies (including cellular, LPWA, and satellite) supported by different kinds of network operator in multiple geographies.
From a commercial perspective, Connectivity Platforms should offer a single service point at a low entry cost for adopters, and enable a quick time to market. Connectivity platforms should offer a global multi-technology footprint so that devices can be connected worldwide using a range of technologies. Pricing should be flexible, and the platform should support compliance with local regulations around the world, for instance with regard to safe harbour of data and permanent roaming.
From a technical perspective, the connectivity proposition offered should be easy to manage, highly scalable, light touch, and based on open systems. Solutions should be able to support real-time data, and be highly secure. Ideally they should also support Mobile Private Network deployment and management.
Accordingly, Connectivity Platforms are the ideal connectivity provider from the perspective of a systems integrator or enterprise end-user since they ‘solve’ the connectivity problems that are often inherent in IoT solutions development.
The world is suffering from a dearth of true Connectivity Platforms right now, and the closest propositions in the market today are those of the more sophisticated Mobile Virtual Network Operators (MVNOs). The more advanced players in this space are seeking to incorporate non-cellular technologies (such as, for example, satellite and licence-exempt LPWA) into their propositions, and are also working to homogenise their propositions across geographies. Some digital transformation service providers and some hyperscalers have capabilities that could be considered to be equivalent to nascent Connectivity Platform propositions, but in the case of digital transformation service providers at least, it remains to be seen whether these will be offered directly to the market or retained in-house as enablers for their wider businesses.
Device management platforms are another major middleware element. Device Management involves the provisioning, configuration, authentication, monitoring, control and updating of devices deployed in the field to ensure they are functioning correctly and securely. In the context of IoT, and due to the IoT device being connected, much of the device management is handled remotely over-the-air (OTA). Many device makers have their own device management platform, although many third parties and cloud hyperscalers also provide similar functionality, often as part of a wider suite of AEP (see below) or Connectivity Management (see above) platforms.
The main device management standard relevant for low cost IoT is Lightweight M2M (LwM2M). It was developed by the Open Mobile Alliance (OMA), which previously developed the OMA-DM standard for phones. OMA reinvented the OMA-DM standard for IoT as LwM2M. It is built on CoAP with RESTful APIs for device management, exposing device management resources such as security, connectivity, location and firmware upgrades. Another device management standard used in some IoT use cases is TR-069, although this is, like OMA-DM, a very heavy protocol which is appropriate for some less constrained IoT deployments, although typically used for telecommunications equipment.
Often manufacturers of IoT hardware devices, and some mobile (or mobile virtual) network operators will develop their own device management capabilities to get the best performance out of connected devices and steal a march on competitors. As specific capabilities become more widely adopted and built in to, for instance, AEPs, so the need to house such previously ‘differentiating’ capabilities in a device management platform diminishes. As such, in many ways, the role of a Device Management platform in IoT is to enable the device-related capabilities that are ‘just over the horizon’ from the perspective of other platform types.
Application Enablement is probably the platform type most synonymous with IoT. If an end-user talks about ‘platform capabilities’, the chances are they are thinking about Application Enablement Platforms (AEPs). Any enterprise considering developing and deploying an IoT solution will, at some point, more than likely consider options to use an IoT AEP to support the development.
From an IoT developer perspective, an AEP provides the actual application development environment, often supported by drag-and-drop configuration of application components in a graphical user interface. Often AEPs will provide some level of functionality that might be considered to fall within the domain of a different platform type, potentially via APIs (Application Programming Interfaces) to third party platforms. For instance, APIs that support the management of cellular connections supported by a third-party Connectivity Enablement Platform (see below).
At Transforma Insights, we think that it is sensible for end-users to use AEPs to support their IoT developments, but also that there’s more to the story than simply picking an AEP that appears ‘top right’ in a matrix of (say) technical capabilities vs ability to deploy. We think that the AEP platform capabilities offered by vendors typically evolve to be a reflection of the overall strengths of that vendor’s wider business, and target markets. Therefore, it’s a case of seeking the best match, rather than one AEP being better than another for all end-users in all situations.
AEP capabilities are also often resold, or white-labelled, by other vendors and AEP providers, and also consultancies and systems integrators. In this case, it is the capabilities of the reseller that are most relevant, rather than the underlying AEP.
Another key consideration for any end user planning to deploy an IoT solution is the question of ‘build vs. buy’: should the end user buy a pre-packaged solution, or devote resources to developing a bespoke solution that exactly matches their needs?
Essentially, there are two dimensions to consider here:
Taking these two considerations into account, it is clear that if a potential IoT solution can be a competitive differentiator, and integrates deeply into the organisation, then it’s probably sensible for the end-user deploying the solution to invest to build more of the solution so that they get exactly the capabilities that they need.
Unless a solution satisfies both these criteria, then buy-in options should be considered, potentially to the exclusion of significant ‘build’ in the case of low-impact, peripheral projects such as smart parking.
