When cellcos effectively entered the broadband access business by way of all-you-can-eat flat rates, most did so with the underlying fear that they would be transforming themselves into "dumb pipes" - mere access channels giving their users access to over-the-top services that cellcos would rather be selling themselves.
Since then, with the rise of dongles and internet-ready smartphones like the iPhone, they've been nervously watching that now familiar chart of data traffic (and the associated costs) spiking while corresponding ARPU flattens or shrinks. And it's well understood by now that cellcos won't be able to raise ARPUs simply by jacking up access fees. They have to either add value to the pipe, or find a way to make money from the services game without resorting to the walled gardens that, for the most part, users have abandoned in favor of web brands and app storefronts.
That was a major theme underlying this year's Mobile World Congress, as delegates talked about the new mobile services value chain and the operator's role in it. Tellingly, many of them blame Google for trying to build a mobile data model that relegates cellcos to bit-pipe status - a charge that Google CEO Eric Schmidt denied during the Q&A portion of his keynote, arguing that Google's push for cloud-based services will become "the backbone of everything you do."
Whatever one thinks of Google's role in mobile, the good news is that the term "dumb pipe" is becoming swiftly anachronistic as the mobile industry becomes increasingly aware that their pipes aren't as dumb as they look.
"We're hoping to see an end to the use of the dumb pipe term. It's outdated and pretty meaningless in our eyes," said Thomas Wehmeier, principal analyst within Informa Telecoms & Media's industry research division, in a blog post on Schmidt's MWC keynote. "Operators have far too much data to ever be turned into dumb utilities. They need to turn raw data into structured information and then draw insight and knowledge about usage trends and user behaviors from that."
That awareness has also led to a resurgence of interest in service delivery platforms (SDPs) as a tool for not only unlocking that data, but also creating opportunities to work with third parties to make additional revenues. Industry efforts like the GSM Association's OneAPI are also working toward that end. Much of the technology is ready - the question is whether operators and regulators are prepared for the paradigm shift required to implement it.
Let the third parties in
Ironically, SDPs are nothing new - they've been around for ten years in some form or another - so much so that the definition of an SDP tends to vary (see "What the hell is an SDP?", p.6). However, operator interest in SDPs has risen considerably in recent months, says Jyrki Holmala, head of sales for the business solutions unit of Nokia Siemens Networks.
"Operators are looking to add new services, increase the speed in which they add them at a lower cost and simplify the whole process. SDPs enable them to do that," he says. "That's been true for some time. What's driving it more now is of course the whole broadband phenomenon that's going on now, even in emerging markets. Also, multimedia services are becoming easier to implement. Markets also are becoming more mature, so operators are looking to diversify their portfolio of offerings for consumers."
The chief attraction of SDPs now, according to Kristofer Kimbler, senior analyst and executive editor for the Moriana Group, is their ability to serve as a common horizontal platform stretching across vertical service silos, which means a shared management platform for different services, which in turn means lower management costs and faster service rollouts.
Moreover, SDPs also promise to enable operators to leverage assets they already have to make their pipes "smarter:" rich subscriber profile data, universal authentication mechanisms (i.e. SIM cards) and advanced billing and charging mechanisms, as well as the network itself.
But the real payoff, Kimbler adds, is the capability of SDPs to enable third-party businesses to tap into those network assets.
"Using SDP as a B2B-enabling platform could possibly empower service providers to truly capitalize on their unique and expansive knowledge of their customers, if they can cut through the hype and figure out what is really out there and what is best for their situation," Kimbler said in a recent TM Forum report on SDPs.
For proof points, one need look no further than the big brands of the Web 2.0 era: Google, Amazon, Skype and Facebook, all of whom owe their success in no small part to adopting business models that attract third parties and support best-of-breed IT infrastructure, Kimbler says.
"Amazon did not take a walled-garden approach; it was not afraid to open the door to competitors, not even high-street brand competitors," Kimbler says. "Rather than approach other stakeholders as potential 'free-loaders' taking free rides on their networks, CSPs have an opportunity to generate revenue from third parties anxious to leverage CSP strengths - namely the close relationships with customers, and a wealth of data about customer preferences, location and habits," as well as OSS/BSS processes such as fulfillment, assurance, real-time charging and billing.
Operators are already getting the message, says Holmala of NSN. "Our customers are mainly using SDP to enable a third-party ecosystem. No telco can do everything by itself, so they're industrializing the process of introducing those services. They've just needed the tools to enable that."
Apps hype
Kimbler (via the TM Forum) lists a number of service opportunities for operators that get their SDP strategy right, from revitalizing core voice services (think real-time charging for prepaid and apps with a click-to-teleconference feature, for example) to real-time data for mobile ads, context-aware data for location-based services and m-commerce, to include mobile banking and remittance services.
At the moment, the biggest hype is centered around app stores. Cellcos have wanted a piece of the app store action for awhile now, and a number of them have already launched them, including China Mobile, Telstra, Maxis, Vodafone and Verizon Wireless, among others.
But while app stores may look like a cash cow waiting to happen, Kimbler warns that operators "will have the major challenge of creating a business model and platform that will be easy-to-use and rich enough to attract developers. Only then can they build a robust portfolio of both free and paid applications."
That said, there's no rule saying cellcos have to do the app storefront themselves. They can use white-label app stores from GetJar, Handango and others to save on capex and reduce rollout times. They can also adopt the shopping-mall model to create an environment for retailers to come in and set up whatever storefronts they want. That's what Telstra is doing, and for a simple reason, says CTO Dr Hugh Bradlow: "The real-life shopping center owners I know are extremely rich."
There can be only OneAPI
Another challenge for operator-hosted app stores is that the real attraction for developers is using the network's assets to give their apps more functionality. The problem has been that network APIs can differ from one operator to the next, and apps developers have enough headaches developing apps for all the different operating systems and platforms scrambling for market share without having to create apps geared to every operator's network.
The GSM Association has been addressing that issue with its OneAPI initiative, which uses Aepona's universal service platform to create common representational state transfer (REST) and web service APIs initially for network functions messaging, location-based services and payment under a single developer community.
"OneAPI is a web services tool - whether you're an enterprise developer working in an IT shop or a guy in a basement developing your first app, it's the same set of tools," explains Larry Baziw, director of next-generation services strategy at Rogers Wireless. "One of the goals of OneAPI is to resonate with the developer community and simplifying how you get onboard - a simple sign-up process that you can do in a couple of hours, so you can start to send stuff and get rewarded quickly, use the tools you're accustomed to using."
Aepona CEO Al Snyder touts the ability of the OneAPI reference implementation to give apps a standard way to tap capabilities that can't be replicated on a handset with an over-the-top (OTT) solution by leveraging what Aepona has typically described as network as a service.
"As a developer, imagine the ability to take an enterprise application, maybe at a regional level, maybe in healthcare or oil and gas, and developing an application where you can mash up multiple network capabilities to create a service, then adding things to it like automatic click to conferencing tied to location," he says. "For financial services, for example, it could be credit card fraud prevention, adding location and messaging together at an ATM. That's the kind of service creation environment you have through a carrier via OneAPI."
Snyder adds that those capabilities can also extend beyond a given operator's platform. "You can go into a specific vertical and develop a very powerful application, get it distributed through a storefront or distribution system that has power behind the carrier at a larger level, and then being able to take that across carriers. So now you can do things like click to conferencing across networks."
While it's early days for OneAPI - only a handful of operators are supporting it at the moment, none of them in Asia - it's slightly more than just talk. In February, Canadian operators Bell Mobility, Rogers and Telus launched a commercial trial of OneAPI with all three operators sharing a single gateway through which developers can create network-powered apps that work across all three networks. The results will be used as a benchmark for future pilots, according to the GSMA.
The pilot will also serve as a potential litmus test for the overall apps market and what kind of retail experience users want, says Nauby Jacob, VP of user experience and content at Bell Mobility.
"OneAPI enables the market to evolve to the point where we could see carriers become retailers, or the other way around, where a company like Best Buy gets into the mobile content business," he says. "Then the market will decide if that's what it wants."
APIs exposed
One significant catch to making one's pipes smarter is that the tools to leverage those smarts have to be able to get to the rich data inside them - and that's going to depend on how the network stores user data already, says Holmala of NSN.
"With some of the legacy systems deployed in many networks, a lot of the information is fragmented in different parts of the network," he says. "So the object is to consolidate that, centralize it and link it to different apps."
Sandip Mukerjee, VP of business strategy and marketing at Alcatel-Lucent, adds: "The network needs to be instrumented so these APIs can be exposed. You're not going to have an abstraction activity for every single major capability in the network."
Meanwhile, equipment vendors are already scrambling to capitalize on the need to link apps with IP networks with service layer architecture solutions promising to do just that. Juniper Networks is promoting Junos Space with open APIs allowing operators and third parties to develop new services to run over its MX routers. NSN is leveraging its professional services experience to help operators build individual service layer solutions. And Alcatel-Lucent is proposing a blend of the two, with plans to offer a suite of tools for apps developers and content owners to access network functionalities, and a cloud-based aggregation service called Open API that will serve as a creation environment and test bed for apps, both of which will be bundled into its professional services portfolio.
Other vendors are focusing on different ways to leverage network intelligence. Tellabs, for example, says it will leverage advanced deep packet inspection technology (via its recent purchase of WiChorus) and analytics to help monetize services.
"Let's say Google wants to get information to my handheld, and we can use the packet core to allocate QoS and bandwidth so HD video can get to my phone and maybe Google will pay an extra amount of money for that," says Tellabs CEO Rob Pullen. "Or take an app where you can look up restaurants in that area. We can take it to another level where all of the restaurants know you're in that area and send you specials and coupons, and if you use that coupon, the service provider gets a fee for that. We can use the intelligence in the core to offer these kinds of personalized services in the future."
Privacy and neutrality
To be sure, operators will have to be careful about a tiered bandwidth pricing strategy - especially when it's aimed at content providers - depending on the local regulator's position on net neutrality.
In fact, that goes for tools that depend on leveraging user data profiles to create apps and services, which will have to comply with local privacy regulations governing the use and security of such data.
On the bright side, there are standards already available that can help cellcos manage profile information, such as the Open Mobile Alliance's Global Permission Management (GPM) standard, says Moriana Group's Kimbler.
"The OMA is addressing how requested data can be shared in a secure, controlled manner - i.e., "ask consent" responses," he explains. "In that example, consent is asked for and if procured, an SDP can 'secretly' expose subscriber data through web services or other APIs that apply OMA GPM. That is just one example of how service providers can monetize useful information without compromising subscriber privacy and security."
What the hell is an SDP?
One of the challenges operators face in implementing service delivery platforms is navigating through the vendor jargon. Different vendors have been known to use the term "Service Delivery Platform," "Service Delivery Framework" or "Service Delivery Environment" to describe the same basic concept, even though the details may be different.
Moriana Group and the TM Forum offer this list of characteristics that every SDP should have, regardless of the name.
- A layered architecture that follows the principles of service-oriented architecture (SOA) to facilitate integration with service providers' operations and business support systems
- A foundation of standard commercial off-the-shelf (COTS) hardware and software
- Open communications and IT standards rather than vendor-specific solutions
- Common execution environments, data repositories and sets of standardized service enablers to be shared by services and applications running on the SDP
An ability to expose selected network and service capabilities to third parties in a managed and secure way.