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 fragmented. To improve the normalization process between PPs the industry standards bodies will need to converge more quickly.
I have successfully registered my SIP endpoints (which we have developed) with Broadsoft sandbox environment. I can make basic calls without problems. When I try to conduct feature tests like Call Waiting (CW), Call Hold (CH), and Call Transfer (CT)...
I am trying to find if there is any Pros or Cons in deploying MPLS with separate customer AS for each site as opposed to one AS. The end goal is to be able to inject default routes from two DCs and be able to make a subset of sites follow one default rout...
So I have attempted the below config: l2vpn
backup disable never
xconnect group Xconns
In one of the discuss, it was initiated to us that there is a specific DB size for example:1 GB and breaching of which will led to crash of Iedge process.I want to replicate the scenario by creating load of user by tool in the lab and track the CDM db uti...
Some 15 years ago we had implemented a PWLAN service by deploying SSG on IOS and Cisco SESM (Subscriber Edge Services Manager) as the web interface (i.e. captive portal). Fast forward, SESM becomes EOL, gets replaced by Broadhop SME. Some years later...