NaaS: Network as a Service, a new business model for network operators

Andreas Constantinou 6,506 views
Vote This Post Down +15 rating
 
Loading ... Loading ...

[What are mobile operators/carriers doing with all the intelligence within their network? Nothing much.. until recently, when operators have started opening up their network intelligence to 3rd parties. Research Director Andreas Constantinou looks at the why, who and how of the new NaaS market and this new business model for operators].

connected networkMobile operators/carriers store more information on their subscribers than banks; who did you call and when, text messages sent and received, location, user profile, free minutes/texts remaining and much more. Operators also run a valuable set of services like billing, send SMS/MMS/email, user alerts, voicemail, IVR services, chat.. all of which they have kept to themselves and in a few cases exposed to other networks (e.g. SMS roaming) or resold aggregators (e.g. premium SMS billing, location).

But operators have not really exposed this combined intelligence (user information + network services) to any third party – making this a dormant revenue opportunity. Until now.

Network operators – the worst innovators in the mobile industry
Operators have traditionally been closed to external (3rd party) innovation and slow to innovate themselves. To see why, consider that:
- operators generate in total circa 70% of the mobile industry revenue pie and boast the most comfortable operating profit margins in the industry (circa 35%-45%). With so much money flowing through their hands, operators have developed an ‘ivory tower‘ attitude that’s not conducive to change.

- operators are large organisations (circa 5,000 – 10,000 staff in each country) where politics are abound (esp. in multinational European operators), innovation rarely bubbles up and initiatives which are safe/conservative rather than bold/innovative prevail.

- operators need to cater to mass-market services that need to reach millions of subscribers and 100s of device models. Therefore lowest-common-denominator services and approaches prevail.

- operators have traditionally focused their energy and investments on top-of-the-pyramid partners, i.e. the 10s of mega-brands like Disney and Yahoo rather than the tens of thousands of third party developers.

- network interconnectivity protocols for service roaming across operators have been complex (e.g. CAMEL, Parlay) or proprietary (e.g. proprietary APIs by Service Delivery Platform providers) and definitely less accessible/documented/usable than IP-based protocols.

Vodafone’s Betavine website draws a very lucid picture of the challenges:

“Developing and deploying applications across mobile operators can be frustrating: unlike fixed broadband, mobile network operators have traditionally placed a barrier-to-entry that has hindered developers from innovating on the mobile Web. Proprietary operator APIs, so-called ‘Walled Gardens’, and contractual differences have stifled the creation of cross-operator Web applications (such as buddy finders, where your buddies may all be in different networks). Meanwhile, some of the cool stuff that a network can do (authentication, seamless charging, location assistance, push messaging, connection awareness, etc.) are locked up and hence not utilised. This is a lose-lose for both operators and developers.”

A lose-lose indeed.

From NetCos to WebCos
However, operators are finally moving towards exposing network intelligence to third parties – thus moving from closed network model (NetCo) to an open platform model (WebCo), often referred to as Telco 2.0. This move is happening due to several reasons:

- the fear of becoming a bit pipe, and the (much better!) alternative of service pipe (aka smart pipe)

- the revenue opportunities in making money from 3rd parties who tap into the network (also inline with the move towards a Channel ARPU strategy).

- the opportunity to offer more services to users at a lower cost and better cater to the long tail of consumer preferences.  More choice = more users, less churn.

A new business model is being born. NaaS = Network as a Service, is the application of the SaaS (software as a service) web 2.0 model to mobile operators and the intelligence stored within their networks. (credit for the NaaS term goes to Aepona’s corporate presentation).

NaaS APIs: who and what
As of 2007-8 network operators have been opening up a range of APIs to 3rd parties – for example billing, send SMS/MMS/email, get location, IVR services, get device capabilities, access to voicemail, user authentication and access to user profile/calendar/contacts/favourites/photos.

NaaS efforts have been led by Orange Partner, the 3rd party developer programme of the Orange / France Telecom group. Orange Partner was founded in 2003 (check this interesting historical perspective) withy the community today boasting more than 60,000 members. Orange has developed more than 20 APIs (full catalogue) in four categories which are slowly becoming available across its operating countries. Note that most APIs are alpha currently and available only in Orange France:

- APIs: Contact Everyone, Multimedia Conference, Device Capability Enabler, Localisation, SMS Internet.
- Instant APIs (mostly alpha): SMS, email, location, click-to-call, voicemail, VoiceMashup, Mobeasy platform API
- Personal APIs (alpha): Authentication, Personal Calendar, Personal Contacts, Personal Content, Personal Favourites, Personal Messages, Personal Photos, Personal Profile
- Web 2.0 APIs: Djinngo publisher, Pikeo (photo sharing) platform

In its 5-year history the Orange Partner website has amassed a wealth of information, white papers and documentation and has organised over 40 public events to date for 3rd party developers.

Launched in 2007, Vodafone Betavine is another effort at engaging and capitalising on the long tail of application developers and content. Betavine offers 5 APIs namely sending a text message, a WAP Push message, an application trigger message,  an email, and the ability to programmatically lookup device properties. Vodafone’s Betavine community counts over 13,000 members who have submitted just over 200 applications to date.

O2 Litmus is the latest entrant into the operators’ foray towards engaging the long tail of developers. Launched in late 2008 by O2 UK, Litmus is mainly a marketplace for submitting and testing applications, boasting only circa 200 forum members and a few 10s of applications.

BT’s Web21C (21st century web) SDK is a set of libraries that makes it simple for developers to access BT’s web APIs. BT offers 6 APIs, namely authentication, call flow, conference call, inbound SMS, messaging, and voice calls. BT’s Web21C was launched in November 2006 and the community counts over 9,000 members. The SDK is today accessed via and through Ribbit, a platform that allows developers to interact with telephony networks, which BT acquired in mid 2008.

It is also worth mentioning the several standardisation efforts that are under development around the NaaS market:

- GSMA’s One API: an initiative to standardise the APIs providing network information and capabilities to web application developers. The reference implementation of the One API is provided by Aepona, an SDP solution vendor.

- WIMS 2.0: an initiative led by Telefonica which seeks to converge web 2.0 and telecom new generation services based on IMS

- Open Movilforum: a Spanish initiative to provide 3rd party developers with open APIs to network services such as SMS, MMS and location.

Late to market and slow to mature
NaaS efforts have made significant strides in 2008, but are much late to market and slow to mature. To see why, consider that operator-led NaaS efforts are:

- 3 years behind web affiliate and API programs such as Amazon affiliates and Google AdSense.
- 5 years behind alternatives such aggregators for SMS, billing and location, which emerged out of operators’ reluctance to provide interoperable access to valuable services.
- High charges for API access: for example Orange levies a €500 activation charge for the Contact Everyone API plus €160 for each communications media activated (SMS, e-mail, voice or fax). On top of that developers pay monthly fees of €50 for the API and €40 for each media.
- Lack of intra-country and inter-country reach: APIs are limited to only those subscribers reached by the operator within each country, while there is also a lack of consistency across regional implementations.
- Lack of carrier-grade reliability, which is natural as operators are new to the NaaS game
- No direct route to market for developers: developer programs are often run by R&D teams or otherwise lack direct access to commercial deployment or bundling deals
- Limited operator experience in working with developers, unlike web companies

Outlook: the future’s bright for the middleman
Operators may have recently put significant energy and investments into NaaS offerings, but the above challenges make standalone NaaS offering unsustainable; As with most network services, operators will be outsourcing development and operations to specialist SDP (service delivery platform) providers like Aepona and dedicated NEPs (network equipment vendors) like Ericsson who run wireless network and SDP infrastructure for operators. The cross-operator reach of SDPs and NEPs and their software/service know-how will make the cost proposition unbeatable for operators who will be outsourcing their NaaS services to specialists. This is epitomised by BT’s acquisition of Ribbit, a platform for 3rd parties to access telephony networks, which was acquired by BT in July 2008.

The future’s bright for the middleman who’s able to deploy and operate cross-operator NaaS services, particularly as they will be able to share in the revenue from API transactions. Considering that network operators bring in circa 70% of the 1-trillion-dollar-a-year market, the opportunity for extending that revenue via 3rd party applications is huge.

Comments welcome as always.

- Andreas

12Jan2009
Jerome D.

Interesting post, on a quite trendy topic, whether it is called “telco 2.0″, “two sided business model” or “NaaS”.

There also interesting applications for the concept on devices, and device management that are discussed in this blog entry: http://www.telco2.net/blog/2008/10/guest_post_device_management_t.html

After all, whatever device manufacturers say operators still control “the last mile” to the device and might as well monetize it…

 
12Jan
Stephen Wolak

Well structured argument … particularly the cross network, cross countries issue … GSMA are putting some work into this … see http://www.betavine.net/bvportal/web/guest/projects/resources/api/gsma_api

 
14Jan
Andreas Constantinou

Thanks Stephen – and hope to see lots of innovation coming out of Betavine, as well as One API becoming commercially adopted. Let’s hope the NaaS movement grows and matures at web speeds rather than telephony-network speeds.

Andreas

 
14Jan
Stephane H.

Nice post Andreas. It would have been interesting though to dig deeper into the “how to generate revenue” problematic around telco APIs to understand whether the future for the middleman is really so bright.

There are different sets of NaaS APIs which serve different purposes and different business opportunities.

Take the social-oriented and personal APIs (like messaging, contacts, authentication, contents). One would think that they bring a great symbiosis between the internet and telco worlds (it would be indeed pretty cool to be able for instance to seamlessly send SMS messages from my Outlook app, or even to automatically stream my mobile pictures into Flickr and get phone numbers resolution of my Facebook friends based on my SIM card address book). But then the question is ‘will it generate money for operators?’

Most of these APIs won’t. End-users won’t be willing to pay for leveraging mobile data (like my contacts, contents and messages) within Internet apps, nor developers. At best the NaaS APIs will indirectly drive new subscriptions to operators’ services (like SIM backup offering).

Looking at enterprise and application-oriented APIs there is apparently more potential of incremental revenue for the operators. Location, IVR, voice (click2call, conferencing), multi-channel broadcasting, SMS sending APIs can generate revenue. But they face serious challenges depending on who is charged to use the service/API. If the end-user pays (on a per-txn model for each location query or sent SMS for instance), the API needs to solve the charging complexity (through the user’s operator) and the API should also be operator-agnostic to make it appealing to the developer. There are potential technical solutions and this is where the middleman can play a key role of API aggregation; unfortunately it will take quite some time to get enough operators joining the movement to see compelling cross-carrier telco-enabled Internet apps and to make a business out of this aggregation. If the developer or application provider pays for the API usage, it is actually a B2B model where the developer has to pick the operator of his choice to build his app with telco-enabled features ; in this case operators compete with each other (Orange has obviously taken the lead here), there is no business for the middleman and the scope and potential of the API isn’t mainstream anymore but simply for niche apps.

All this means 2 things:
- The lack of strong business incentive will severely slow down the involvement of operators in the NaaS market. Some carriers though, like Orange who doesn’t exclusively focus on pure ARPU-generation (by valuing the innovation factor around Naas) will lead the market but still it will be a long journey before making real money.
- The interest in the telco NaaS offering by the Internet community is highly undermined. In addition to all the barriers you mentioned (lack of interworking, lack of global reach,…), the lack of revenue-share models (‘how the developer makes money?’) limit the value of NaaS-enabled features for Internet applications; Internet developers will keep finding workarounds and the cheapest alternatives rather than leveraging carriers capabilities (for instance getting location directly from the device instead of querying the network), reinforcing the dreadful “bit pipe” curse. Micro-payment and voice-oriented enterprise-type APIs could be exceptions to this though (this is probably why BT acquired Ribbits for over $100M for voice services).

Under these conditions, in my view, the future for the middleman and the NaaS market are not that bright…

 
14Jan
Andreas Constantinou

Hi Stephane,

Very thorough argumentation on the monetisation of NaaS which I did not dig into in the post.

True, social information cannot be charged for (the likes of Facebook make money through ads and that’s because they control both the APIs and the web real-estate; on the contrary operators control the APIs but not the handset real-estate).

Location can certainly be charged for, but it has to be on a bulk basis rather a per request (it’s far too expensive as it is. cell-ID is preferable to GPS only for large population coverage).

B2B APIs can certainly be charged for. Voice and SMS APIs can also be charged for. Also more apps = more users = more service consumption and less churn, which positively impacts P&Ls.

In general, there will be a variety of pricing models that can be applied depending on the NaaS API; some will be free, some charged for.

I think the issue operators have is that they are not keen to experiment; they ‘d rather follow proven monetisation strategies, as everyone who has signing authority has 3 and 6 months P&L targets.

Yet, as with any new market, someone has to test the waters and try out revenue models. This someone has to be operators, as the window of opportunity is finite. It will be 2-3 years before GPS is everywhere and Facebook has phone APIs and EU forces voice prices down lower and lower. Operators (at least those with vision) have to move fast – no one else is going to open up this market for them.

Andreas

 
15Jan
Kevin Smith

Hi Andreas, I like the article and the use of NaaS (although you may not know that Naas is also a town near Dublin :) . I’m the project leader for the GSMA One API, and just wanted to add that for it to be succesful, it is absolutely crucial that developers let us know what they want and in what format. We have put in a year’s work on what the operators can offer as a common set of functions, and have readressed previous complex telecoms interfaces (such as Parlay X) into RESTful and lighter WS APIs (see the Reference Implementation Beta at http://oneapi.aepona.com). But this is our best guess (albeit with some early developer involvement); so for the API to be truly relvant and valuable we need as much developer involvement as possible to help evolve the APIs. We have a seminar at Mobile World Congress and hope to start getting useful feedback to help steer us.
All the best,
Kevin

 
03Feb
Andreas Constantinou

Hi Kevin,

Good to hear about the momentum behind OneAPI (and no, did not realise about NaaS being an Irish town!)

I would suggest presenting OneAPI at one of the WIP Jam sessions (there’s one at MWC next week), which is a good forum for addressing (and getting feedback from) developers.

Also, the OMTP guys should be able to give you some good pointers regarding engaging developers, as they are quite successfully doing just that with the BONDI 1.0 SDK.

Best,

Andreas

 
10Feb
Kevin Smith

Hi Andreas,

The good news is that we will be at WIP Jam on the Thursday so hopefully will get a chance to learn from you and your readers! We will have a demo running (assuming our batteries last that long…)

My colleagues in Vodafone R&D Spain are heavily involved in BONDI development and we work closely to help share learnings and align the two API offerings.

Best,
Kevin

 
10Feb
giovanni zappelli

Very interesting conversation; I would like to contribute with an article I co-wrote on NaaS services offered to different industry sectors.

Following excerpts are straight to the point:

A: Network Capabilities Exposure

Network capabilities comprise the wealth of information and services that reside in the mobile operator’s network. The most striking of these, beyond access, are:

1) Identification: By means of any SIM card, every subscriber gets out on the mobile internet with an ID and will bring it along any time he or she moves around; the intelligent use of this identity information simplifies cumbersome (mobile) log-in procedures, increasing service accessibility and usability.

2) Location: Cellular networks are special in that they know where you are. In urban areas, accuracy can be within 10–100m. Th is may be not suffi cient for navigation, for which satellite-based systems are better, but it’s useful for other, less demanding applications.

3) Status: Cellular networks incorporate status information, such as whether the user is on or off , whether a large or small bandwidth is available, whether the user is willing to receive services or not.

4) Payments: Cellular networks provide standardized micropayment means, with direct charge to the user’s mobile account. SMS has established itself as universal bearer, but more-sophisticated methods like on-navigation purchase areon the way. (The extension to standard payments is the next logical step, whereby SIM-based authentication, reinforced by security procedures, is a key ingredient.)

5) Messaging: Simple text or multimedia messaging is an
increasingly powerful means of communication between a
networked enterprise and customers or citizens for promotions, alerts, and informing.

B: Key Subscriber Information

Among the key information residing in mobile networks is
user data: demographic, contextual, behavioral.

The value of this information is almost totally untapped. However, the game is tricky, and privacy implications are of paramount importance. But even in aggregated, anonymous form, current data-mining capabilities allow for great value extraction for the operators and possibly for third parties.

C. Middleman role

Th e variety of capabilities and services calls for a transformation from the current vertical integration model (such as when selling ringtones) toward an independent, industrialized, whitelabel service broker. The service broker would standardize network service interfaces and make them available to a networked enterprise working with multiple operators’ services. Th is would, in the long-run, create a market for brokered capabilities, in which each transaction has a value to the mobile operator at market prices.

This monetisation chime is echoed by Vodafone CEO’s recent interview: http://www.totaltele.com/view.aspx?C=0&ID=443352

Full article available at:

http://www.ericsson.com/ericsson/corpinfo/publications/ericsson_business_review/pdf/208/8_monetizing_attraction.pdf

Comments are welcome!

Giovanni

 
13Mar
Niall Halpenny

Hi Andreas,

Firstly, I do like your article and this is a topic that I have been banging on about for years. Ironicially, I am from the town of Naas that Kevin Smith referred to above, which roughly translated into English means meeting-place. How apt if it were a reality.

But as we see iPhone 3.0 hitting the market, and when I look at what is really happening on the ground in terms of Cloud computing, what’s missing from the mobile world is speed and commitment.

So unless we are to become the “dumb” bit pipe, we have to see a true change of heart and a level of true openess and inclusiveness on the part of the mobile operators.

Regards,

Niall

BLOG: http://danu.typepad.com/my_weblog/

 
18Mar
mahita

Operators may have recently put significant energy and investments into NaaS offerings, operators have been opening. operators are large organizations in many countries . The lack of strong business incentive will severely slow down the involvement of operators in the NaaS market.The interest in the telco NaaS offering by the Internet community is highly undermined. operators have traditionally focused their energy and investments on top-of-the-pyramid partners like Yahoo .

 
25Mar