1. IoT Platforms Providers: Silent yet Significant
Partners?
Posted by Dennis Ward
inShare5
Service providers (SP) have been offering machine to machine (M2M) services for more than a decade, but it was not until a
couple of years ago when Internet of Things (IoT) capabilities came to the fore via SP and aggressive equipment provider
marketing that businesses and the public took notice. To manage the expected exponential growth of devices and application
intelligence SPs have partnered with IoT platform providers. How do these platform providers fit into the IoT ecosystem? What
functions do they provide? What pain points do they address? And what does the future hold for such essential entities?
Moving to enhanced IoT/M2M platforms
Traditional M2M systems were monolithic, purpose-built solutions constructed to scale vertically but not necessarily
horizontally, for example, telematics (fleet/asset tracking) use case. Trucks were outfitted with purpose-built GPS devices, and
the underlining software applications were hardcoded to address one specific function. The SP’s delivery platforms, OSS and
BSS functions were clearly defined and possibly located on clustered servers. If a company wanted to add trucks it could.
However, an SP had to build a new process for each company that wanted the same service; consequentially, the SP’s operation
expenses, capital expenses, manpower and skill sets increased.
To handle the expansion in devices, OSS, BSS, data, application and security management SPs turned to platform providers to
provide distributed platforms, which use virtualized software defined network technologies to build horizontally distributed
solutions that enables the SPs to exponentially grow their user base and reuse hardware and software assets. In most of the
platform solution designs, these key functional blocks are employed:
Device connectivity layer: This entity is the link between the core system and the access device at the customer premises. This
entity sits behind the OSS provisioning layer of the SP and are secure connects to the customer premises equipment. Some
platform providers itemize data flows and perform least cost routing functions at this stage. Several protocol formats are
supported at this level: Message Queue Telemetry Transport, Constrained Application Protocol and Extensible Message/Presence
Protocol for message transfer. Embedded software stacks will allow local analytics and storage to occur at the edge depending on
the IoT Gateway used; therefore, only necessary data and signaling will need to pass through the network, reducing overall data
traffic.
Application integration/development layer: The entity is used for the distributed applications that can be developed. The
software is open web-based APIs, such as REST, XML, JSON, SOAP, Python, Ruby and JAVA. Third-party analytics, data
storage applications and backend services such as SIM provisioning and billing functions can be integrated at this level.
Platform management layer: Each platform provider includes its middleware of integration code to connect the device and
management planes. This interface also includes a real-time management interface such as a web browser for visualization and
rules creation for activities.
Most of the platform providers to date primarily do not have a SIM provisioning feature; the SP’s OSS provisioning services has
that responsibility since the SP actually owns its SIMs and device access to their networks. Jasper, a platform provider is
attempting to provide an abstraction between all carriers to produce a global SIM. This is extremely important for IoT
deployments because it allows IoT assets to be anywhere in the world. Although Jasper does not have a cloud application
platform, it differentiates itself in that it has a cloud solution that focuses on the SPs’ OSS and BSS edge: mobile service
management, real-time engagement, support diagnostics, billing and business automation. AT&T has an exclusive strategic
partnership with Jasper in the U.S. to handle its IoT provisioning.
Dealing with pain points
Partnerships between SPs and PPs for the most part work well in addressing most customers’ needs; however, there are still
issues with developing applications with the existing tools or integrating an existing application. Because industry standards are
fluid there still exists many protocols, custom middleware and software tools to manage. PPs have to administer many device
partnerships and revenue sharing models in the value chain. Although some solutions are working, in some verticals meeting the
quality management standards, such as Sarbanes-Oxley, may affect the way the SPs/PPs implement their internal and external
controls. Providers must also constantly address the issue of security at the edge, core, analytics and data storage plains.
Looking to the future
As the IoT industry matures the role of platform providers in the ecosystem will become more significant. SPs’ legacy OSS
platforms will be more tightly integrated or replaced by platform providers’ offerings. As devices and applications increase in
complexity PPs will have more control and be able to dictate better deals for their customers by brokering through numerous SPs.
Savvy SPs will either partner with or acquire PPs. Right now, the platform providers’ horizontal services layers are still

2. fragmented. To improve the normalization process between PPs the industry standards bodies will need to converge more
quickly.
Learn more about Dennis Ward by visiting his community profile here.