GSMA targets net gains through OneAPI

The GSM Association has set up an industry-wide initiative to help make mobile operators’ network capabilities more accessible to third-party application developers. Dubbed OneAPI, the project has developed some commonly supported APIs and is already in beta trial phase using software platform technology from Aepona. Telecoms.com spoke to Graham Trickey, senior director at the GSMA, about the project’s progress so far and how the OneAPI project intends to improve the lot of the mobile operator.

Telecoms.com: What are the key problems that the OneAPI initiative is addressing?

Graham Trickey (GT): The whole thing started about two years ago when I was the director of another project called Mobile Internet. At that time, we were looking at what was going to happen as a result of the mobile and internet worlds coming together. Out of that, we realised mobile operators had lots ands lots of assets that we thought were valuable to various people, particularly to [application] developers. So, one of the things we decided to start as a project – as a result of that previous project – was to look at how we could facilitate third-party access to mobile networks. That started in January 2008. The objective was to decide on a small number of APIs, which could get support from multiple operators, with a view to getting a common set of APIs across various operators. We achieved that but we went a couple of stages further. We actually produced a reference implementation that developers could not only use to gain access to the details of those APIs, but to actually run a sandbox and prove that things work. We also found that we could map the OneAPI calls to the existing proprietary APIs that a number of operators already had. That meant that developers could access, through one portal – hosted by Aepona – live connections to networks for developing and testing their applications across multiple countries in the world.

Telecoms.com: What progress has been made in terms of operator and developer participation?

GT: We’ve have a whole range of operators involved: Vodafone, Orange, Telefonica, T-Mobile, Telstra, ‘3’, Telenor, Telecom Italia, Swisscom, Telus, Rogers, and Smart Communications. It’s a pretty good cross-section of major operators, which are also involved in our executive management committee [at GSMA]. Initially, we were looking at developing APIs from square one but we quickly realised we could base at least a web services version of these APIs on the work done by Parlay X [a simpler version of Parlay to define web services that can be accessed via the internet]. We have ended up with five APIs: messaging, location, charging, user-profile – demographic, as well as whether the customer is pre-paid or post-paid – and a data connection profile.

Telecoms.com; How long will it take before commercial services, based on OneAPI, become available and what needs to be done before that can happen?

GT: We already have the APIs implemented for development purposes through the Aepona portal, which allows developers immediate access to test. For commercial operations, the developers can go direct to the operator to try and find a deal. We can’t directly affect commercial availability, but what we didn’t want to do was to just have this as a bit of paper without showing how it works. This is why we have adopted the development route and to run it from the word go as a beta testing project. It is up to individual operators when they do this, which comes down to demand.

Telecoms.com: How many developers are involved?

GT: The portal’s been running for almost a year and we’ve had about 500 people signed up to it. Around 250 of those are developers. In the week of MWC in Barcelona alone, I think about 40 to 50 developers signed up to the portal. It’s very small at the moment but until we got to this critical point of having something we could show and people use, there wasn’t much point in advocating it too much to the developers.

Telecoms.com: Is the OneAPI project recognition by operators that walled gardens haven’t worked and that they are also feeling the threat of so-called ‘disintermediation’ more than ever from the various app store announcements by device manufacturers, which threaten to ‘steal’ their revenue?

GT: As this project stared more than a years ago, I don’t think you can say app stores have been a factor. But the walled gardens comment is valid. And operators have realised that they need innovation but they are not in a position to provide all of that themselves. They need to team up and coordinate with developers. The minute you stand back and ask why you haven’t got many developers working on mobile compared to working on the internet, the answer comes quite quickly: we actually haven’t helped the developers all that much. Operators recognise that they need to develop an ecosystem of developers to capture the application innovation they want.

Telecoms.com: What benefits are there for the application developer using OneAPI as opposed to working with the various app stores that are available?

GT: In terms of app stores, applications are really about writing code to run on a particular type of device. The initial success of Apple focused on one operating system but now there are multi-phone and multi-platform app stores. But all of that is just about getting an application running, and most of those applications are games, which are standalone. So what does OneAPI add? Well, if you don’t have any APIs into the network, you are pretty limited in what you can do. With network APIs, you have the ability to send a message, the ability to find a location of a device, the ability to charge an application to a user, and to understand what data connection they are on so you know if you can send video or not. If you don’t have access to these network APIs, you can’t make very personalised or interesting applications. OneAPI is an enabler for developers to make useful and interesting applications

Telecoms.com: What difficulties do developers face in terms of getting access to those network APIs in the absence of OneAPI?

GT: As every operator has its own proprietary set of APIs, developers have to re-learn everything for each operator, which is clearly silly. It also means they have to maintain a different set of code for each operator, on top of having a different set of code for each phone. This can quickly get out of hand. The cost barrier of working with more than one operator is reduced significantly with OneAPI. Moreover, the application becomes portable across multiple operators around the world rather than just with a particular operator in its own backyard. There are significant cost savings and opportunities for developers, while operators can get faster access to better applications

Telecoms.com: Has GSMA done any work on evaluating the operator revenue opportunity through using OneAPI?

GT: We’ve looked at this briefly and it’s something the project will be looking at during 2009 in a little bit more detail, as we wanted to get the technical side sorted out first. I think the bottom line is that some APIs won’t be charged for by operators but others will. There are various mechanisms that can be used to charge for APIs and I think the revenue share model will also be very attractive for developers and operators to work together on. Operators would like to have common APIs and they have supported us on this, that but they will also want to differentiate so they will still have their own ASPIs to help them to do this. They will also differentiate on business models. We want to make sure the basics are in place to make this as easy as possible.

Telecoms.com: Why did you choose Aepona?

GT: There were one of the vendors who made their interest known in the project, and some of the people in that company were involved originally in the Parlay X work. There can be other reference implementations in the future but Aepona were kind enough to offer their assistance and it was something we were grateful to accept. There is, however, no requirement for people to use Aepona to use OneAPI. They are just offering a facility as a reference implementation.

Telecoms.com: Do you have any quantifiable targets for OneAPI going forward?

GT: We currently have six mobile operators using OneAPI and we want to continue to build on that. Any operator that is in the process of implementing APIs, we are actively going to try and persuade them to implement OneAPI as a base rather than go proprietary. We need to make sure that there are several commercial routes to market for this. We are actively talking to service aggregators, which might be the fastest way to get the solution in place as it could be done to today. We’re also working with operators to try and streamline the process, such as working out what the typical terms might be in a contract and put them into a template, which makes it easier for developers to understand. The whole idea is to make it easier for the developer. We’re also looking at the possibility of whether it would make any sense to have a central portal, possibly run by the GSMA, which would act as one point for developers to sign up to a contract.

Telecoms.com And the time frame for commercial launch?

GT: Of the operators on board now, I would expect them to have commercial solutions certainly in the first half of this year. But that also relates to demand. That’s why I want to get to the developer communities and make them aware of OneAPI as much as possible.