Coined by vendor Aepona, it describes how operators can offer the combined intelligence of the user information and network services they hold to third parties. Operators know who users called, when they were called, the user’s location, their profile, the free minutes, texts and data remaining in their package as well as applications downloaded and content purchased. They also run a useful set of services such as billing, user alerts, interactive voice response (IVR) services, chat and messaging which third parties can tap into to deliver, charge and promote their offerings.
This isn’t a new idea is it?
No, the concept of operators deriving additional revenue from providing their data and capabilities to third parties has been an industry goal for years. The likes of Vodafone, Orange and O2, for example all have third-party developer programmes that are designed to help them mine the long tail of application developers and content. Orange Partner, for example, was founded in 2003 and radically pre-dates the emergence of the NaaS concept, although it is a textbook example of NaaS. Its community now has more than 60,000 members and has developed more than 20 application programming interface (API)s in four categories for its partners to use. However, these are only now becoming available across its operating countries with most currently available only on the Orange France network.
Vodafone came to the NaaS party later with Betavine which now offers five APIs which include; sending an SMS, a WAP push message, an application trigger message, an email and the ability to look up device properties to ensure compatibility. Betavine now has approximately 13,000 members who have submitted more than 200 applications.
O2 made its NaaS move even later with the launch of O2 Litmus in late 2008. Litmus is predominately a marketplace for submitting and testing applications and has around 200 members.
Don’t these proprietary approaches limit the possibilities?
From the point of view that each third-party provider has to integrate with each different approach, there’s certainly a limitation in terms of the repeat work required to make use of each operators’ APIs. The waters are further muddied for both operators and third-party providers because NaaS is just a conceptual umbrella term rather than a unified standardised approach. However, standardisation efforts are underway beneath that umbrella. Of further concern is that there are several standardisation initiatives being worked on which could give rise to a counter-productive range of non-standard standards. These include the GSMA’s One API which aims to standardise APIs that provide network information and capabilities to web application developers. Another initiative, being led by Telefonica, is WIMS 2.0 which is working to converge Web 2.0 and new generation telecoms services based on IMS. Anothrt initiative is Open Movilforum, a Spanish project to provide open APIs to services such as SMS, MMS and location.
So NaaS is a nice concept but the reality is hugely fragmented?
The lack of reach across multiple operators in multiple – and within single – countries poses a significant barrier to the success of NaaS initiatives. Currently APIs are purely limited to those subscribers reached by a given operator in a given country. This coupled, with a lack of consistency across regional implementations means NaaS offerings are hugely varied in scale and scope. The picture is further complicated by a current lack of carrier-grade reliability. That’s understandable given the novelty of NaaS offerings but confidence is critical if third parties are to buy into the concept. In addition, few operators offer a direct route to market for third parties. Much NaaS activity is confined to carrier research and development teams and third parties generally don’t have access to commercial or marketing teams and bundling deals.
Are carriers too far behind to catch up?
This all seems so archaic in comparison to what’s happening on the traditional web. Web affiliate and API programmes such as Amazon Affiliates and Google Adsense are, at a conservative estimate, three years ahead of operator-led NaaS efforts, which also lag at least five years behind alternatives such as using aggregators for SMS, billing and location.
Operators have limited experience of working with developers and a reluctance to engage with third parties continues to characterise the operator sector. NaaS is further challenged by the high charges levied for access to APIs. Orange Partner, for example, charges c500 to activate its Contact Everyone API and c160 for each communications medium activated. Developers also pay monthly fees of €50 for the API and €40 for each communications method. Considering the millions of subscribers available to address in this way, that could be perceived as good value but only for major third parties such as Disney. Small developers will have to think twice and that’s a further limiting factor.
