Tuesday, March 6, 2012

GSMAOneAPI: One API to rule them all?


In June 2010, the GSMA released the specifications for its GSMAOneAPI. “A set of APIs that expose network capabilities over HTTP. OneAPI is developed in public and based on existing Web standards and principles. Any network operator or service provider is able to implement OneAPI.”
The API is based on xml/SOAP, its version 2, available since June 2011 includes SMS, MMS, Location and Payments as well as Voice Call Control, Data Connection Profile and Device Capability.

A live pilot implementation is ongoing in Canada with Bell, Rogers and Telus. It provides the capability for a content provider to enable cross network features such as messaging, call and data control. It is powered by Aepona.

The interesting fact about this API is that for the first time, it exposes some data control indication inherent to the core and RAN networks to potential external content providers or aggregators.
I went through an interesting demonstration on the GSMAOneAPI stand at Mobile World Congress 2012 by a small company called StreamOne, out of the Netherlands.

The company uses the API to retrieve from the operator the bearer the device is currently connected on. Additional extensions to the API currently under consideration by GSMA include download speed, upload speed and latency. These data points, when available to the content providers and aggregators could go a great way towards making techniques such as Adaptive Bit Rate more mobile friendly and potentially make way for a real bandwidth negotiation between network and provider. It might be the beginning of a practical approach to two sided business models to monetize quality of experience and service of OTT data traffic. As seen here, ABR is lacking capabilities to provide both operators and content providers with the control they need.





Of course, when looking at the standardization track, these efforts take years to translate into commercial deployments, but the seed is there and if network operators deploy it, if content providers use it, we could see a practical implementation in the next 3-5 years. Whant to know more about practical uses and ABR alternatives, check here.

1 comment:

Anonymous said...

Network APIs have long existed with the last effort being Parlay and Parlay/X, plus BT 21CN web SDK. The issue has always seemed to be getting adoption at both the service provider and the application developer. Most application developers are not network aware. At a mobile video conference streaming server developers were asking for APIs for just this sort of information, but also the OneAPI team were there too and it as yet does not provide the network feedback that was needed. The Canadian trial is however a useful development, but wonder what the latency to retrieve the information is, because to do things in real-time will require fast transaction processing which has not usually been the case in previous efforts such as LBS etc.