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.
No comments:
Post a Comment