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'm trying to do some lab here and just some odd behavior.CE1(AS20)----PE1(65000)----(65000)PE2----CE2(AS20) I have two routes, 192.168.255.7/32 and 192.168.255.77/32 being advertised from CE2 to PE2. For .77, I did some random prepends. CE2#rou...
I am trying to built an EVPN VPWS service with port-active load-balancing. One end of the VPWS is with two PE's (NCS55A2, PE-1 and PE-2) connected to a customer LAN the other end is a single PE (ASR9K - PE-3) connected to another customer LAN. in between ...
Hi all,i have ASR1006 working in my network and now i need to install new line card ASR100-6TGE on this box but the power supply is ASR1013/06-PWR-DC is this working ?Chassis type: ASR1006Slot Type State Insert time (ag...