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.