The purpose of this weblog entry is to firstly provide some specific real-world examples of how opening up the network (exposing the Telco API) can significantly improve existing applications and stimulate revenue.  And secondly, look across some of the addressable markets the Telco API opens up.

Mobile Communities
airG's mobile community has more than 30 million registered users worldwide and is interconnected to more than 100 mobile operators and media companies including Sprint Nextel, AT&T, Rogers, TELUS, Virgin Mobile, Orange, Boost Mobile, Vodafone and MTV.  I reviewed airG in a previous weblog entry.  It claims to be the largest inter-carrier mobile community in the world; and most importantly compared to its mobile community peers it's making a profit.  This is through its revenue share agreements with operators.  Simply, airG stimulates traffic, and in doing so shares in that revenue stimulation.  Their services include the standard community features such as profiles and messaging, but they also include anonymous chat for flirting, and a range of services for posting and viewing community members' content.
The first step on any community tool is signing-up, and it's the first in a series of barriers that can stop people joining.  With the information an operator has available in their network within three clicks a customer could be signed up and have sent a friends invite to all the people in their phone's address book already on the community through just exposing single sign-on and the customer's address book. 
Video streaming is another tough problem for application developers because of the variety of phones and the variety of video playing software on the phones.  Many operators have invested in video streaming solutions for their handsets, exposing this capability provides value to many application developers, and enables operators to win revenue share agreements, and stimulate new services not possible without their involvement.

Prepaid eInclusion Application
An interesting eInclusion application is InLiving developed by KNH (Kirklees Neighbourhood Housing) and Creative North (UK application developer), with input and testing from local students.  InLiving is a tool that housing organizations and local governments can use to help create successful and sustainable tenancies for 16 to 24 year olds.  
A critical challenge with this application is the majority of people targeted for this service are on prepaid, if the account is empty they cannot participate.  Exposing a wholesale data capability would enable the housing association or local government to pay.  ARPU (Average Revenue Per User) estimates range between $2-4 per month, this stimulates data usage (non-SMS) within the prepaid segment.  This is an example of an application an operator would never consider in its product roadmap; yet it exists today and can be significantly enhanced through the Telco API.

Communications enabled Business Processes
The primary challenge facing businesses today is human latency; the time it takes to get people together to discuss a problem and then make a decision.  As a simple communications enabled CRM (Customer Relationship Management) use case:

• Jim is a broker at an investment bank that uses Salesforce.com.  One of the bank's fund recommendations had been dropped; which requires he explain to his team how to present this to their 'top 10%' customers.  
• Using the Operator's widget for Saleforce.com, he clicks on the task which automatically sets up the conference call to his team which includes recording and speech-to-text for legal recording purposes.  
• For those of his team not on the call, they get a voice message marked urgent with the conference call's transcript.  

Such applications exist today, from suppliers such as Sylantro and Broadsoft.  The application has been shown to improve broker productivity by over 30%. With just an IP connection (whether in the office, at home or on the road) a broker has access to their communication tools.   The retail value of such a feature is approximately $800 per seat, a monthly charge could be in the range $45-60 plus communication costs.
In a relatively controlled environment of the enterprise's VPN (Virtual Private Network), an operator could expose conferencing, messaging and call control APIs, and potentially mash up messaging with a voice-to-text service provided by a third party such as SpinVox.

Operator Community Widget
We're already starting to see operators such as Verizon creating Facebook pages and encouraging people to become fans.  This is just a first step, the potential of participating in online communities is far greater.  Facebook provides an open environment for applications, similar to what an operator can create.  The experience of launching an Operator branded application on such an open platform can provide essential learning for an operator in what it takes to create a good application development community.
Here is a simple use case of what an operator could do with a community widget:  

• Sue sees her friend Jo has added the 'Operator app' on her Facebook profile so she tries it to see what it can do for her.  As Sue adds the app she also confirms the download of the widget to her mobile phone.  
• Whenever Sue wants to update her Facebook status message she can now include location information.  
• At lunch she checks the widget and sees Jo has just downloaded a song they were talking about last week, from her widget she also selects to download the song to her phone.  
• On her way home Sue stops at the local market, and while there receives a message saying Jo is close by, so she calls to see if they can meet for over tea.  
• After dinner, while watching IPTV, Sue quickly checks her widget for updates as it saves going over to the PC.  There are no new updates, but the Operator is advertising a 'one free premium VoD movie' voucher, which she selects.

This use case shows the wide range of service capabilities an operator could expose such as content, customer profile, single sign-on, location, preferences, presence/context, and IPTV.  The business model for the operator would be to insert itself into the 16%-20% of online time being spent for social communications; enhancing that experience; and using it for both advertising and stimulating consumption of operator services.

Social Network Integrated Friend Finder
SNIFF lets customers locate friends using their mobile phone, even if their friend is on another operator's network. SNIFF provides rules based control over privacy and how location information is shared.  SNIFF integrates with Facebook and other popular social networks.  Launched in Sweden and the UK where it operates across all operators.  Pricing is roughly $1 per SNIFF (location check).
One of the application's challenges, common to many location applications, is age verification because of location privacy concerns, hence the SNIFF application could be assigned an adult premium rate SMS code, which would deters customers.  In addition, the process of using a credit card to prove the potential customer is 18 or older presents a further barrier to entry.  The operator can in some cases have age information available; exposing that would enable a seamless user experience especially when combined with single sign-on.  SNIFF is just one of many location applications motivated to partner with operators to provide a smooth user experience.

Ad-Sponsored Services
Virgin Mobile USA announced the Fund My Phone application; this extends the operator's Sugar Mama marketing program to Facebook's social networking platform.  Consumers earn airtime for their fellow Virgin Mobile subscribers, scoring free minutes as ads are viewed.
Over 700,000 Virgin Mobile USA customers have joined the Sugar Mama initiative since its 2006 launch.  By viewing ad spots, responding to branded text messages and completing surveys customers can earn free airtime.  Virgin Mobile USA still earns revenue for its airtime, it's just the customer pays with their time and through an advertiser it's converted into cash for Virgin Mobile.


These are just a few of the many thousands of applications that can benefit from the Telco API.   Taking a broader market perspective and examining the potential markets the Telco API can address:

• Location based services (LBS).  Enable 3rd parties to aggregate and experiment with innovative LBS.  LBS market size is estimated to reach $59B by 2011, source ABI Research.
• Mobile Advertising.  Under policy control enable some customers to pay for services through viewing advertiser messages, e.g. Virgin USA's Sugar Mama.  Total US advertising spend last year was about $150B, with $21B being online.
• Community services.  It's not just enabling access to online community services, operators can add their own widgets to those communities.  A small market by revenue compared to others in this list, though it does have lots of 'eyeballs' with Facebook reaching 100 million users on August 26th 2008.
• Wholesale access.  For the prepaid segment this enables services to be sent even when their balance is zero.  It can be used by advertisers or local government bodies.
• Telematic services.  OnStar (US based telematics provider which uses the Verizon Wireless network) has achieved more than 4.5 million subscribers in '07 and is the largest telematics service provider in the world.  With monthly subscription plans ranging from $17 to $70.
• Enterprise mash-up services. Enabling operators to integrate communication services into businesses processes.  Business process management in just the US is forcast to be a $6B in 2011, of which mashing up communications could take a significant share.
  
• Content delivery over IP.  Enable content to be delivered and charged for using multiple methods, not just traditional premium messaging, a $50B market in '07.
• Set top box (STB) Widgets.  Enable 3rd parties to put applications on IPTV STB, not just local traffic and weather, but local community services (e.g. restaurant menus, local services, local government).  Enable services between the mobile phone and STB such as remote program record and viewing content on either device.  IPTV market size is predicted to top $17B by 2010.
• eHealth and telemedicine.  Integrating communications into health care systems, e.g. remote diagnostics and remote healthcare visits.   The health care industry is roughly $4.5T worldwide, and $2.2T in the US.  There's lots of potential in this segment!
  
• General Experimentation.  If an operator is not convinced ad-supported gaming will work, then let some of the many providers experiment in their market.  The Telco API provides a mechanism whereby operators can outsource risk, letting the market decide, c.f. Telecom Italia's NexTIM.  This last point is critical to the importance open innovation plays in enabling a operator to expand the capabilities of its product development process.

In summary, this article sets out just a few of the many thousands of applications enhanced by opening the network through the Telco API.  As well as giving just some of the potential markets (and revenues) such opening can address.  An operator's product development process can not address these opportunities, only by opening the network with the Telco API and getting out of the way of developers / 3rd parties can an operator access this untapped revenue potential.

Video in operators has a long history.  In the beginning, AT&T built the first Picturephone system in 1956; by 1964 the "Mod 1" was tested between exhibits at Disneyland and the New York World's Fair.  The trial results indicated that people found the picture distracting for most conversations, and were not prepared to pay significantly extra - so it didn't catch on.  Once digital technology came on the scene the CCITT (Consultative Committee for International Telegraph and Telephone, later to become the ITU) created the H.120 standard for video conferencing in the early 1980s; video conferencing has been around for over 20 years!  As digital signal processing technology improved, ISDN (Integrated Services Digital Network) videophones became available.  Because it required an ISDN line, specialized equipment, and customer feedback showed it to be a 'nice-to-have,' so the barriers outweighed the benefits.

I joined the 'video party' in 1991 when I did the technical due diligence on the PSTN (Public Switched Telephony Network) videophone, soon to become the BT Relate 2000.  Customer feedback described the picture as 'like a moving frying-pan' to 'just recognizable.'  The market quite rapidly decided that it really wasn't good enough.  At the same time as having fun with PSTN videophones, I also worked on building the first Video on Demand system, demonstrating the BT adverts running over one of the first DSL (Digital Subscriber Line) systems from Stanford University (John Cioffi had not yet formed Amati). We showed some BT adverts running over a couple of kilometers of telephone line.  The BT board loved it and ran a video on demand trial.  There was customer interest, the challenge was price points.  In essence we were providing customers with an E1 (2 Mbit/s) line and getting about $10 per month; when the rest of BT was charging business customers thousands of dollars per month for an E1 line.  Hence VoD had to wait over 10 years before BT started commercial deployment.

Today we have an explosion of video devices and services, from YouTube, through mobile video telephony to HD video-on-demand.  YouTube is now approximately 10% of global Internet traffic, and in the UK the BBC's iPlayer service is now approximately 15% of all UK Internet traffic.  Add in video related traffic from other P2P (peer to peer) services, and well over half the internet traffic today is video related.  However, the sad fact is that after all the investment operators have made in video over the decades, all this traffic is just using the operator as a dumb pipe.  And the two video services you'd expect to be similarly following internet video in terms of traffic, i.e. mobile videotelephony and MobileTV, are clearly not.  

Mobile video telephony is a failure, back in 1999 when I was working with operators in creating the 3G business cases, some of the revenue models had video-telephony accounting for 20% of calls by 2008, generating roughly 50% of call revenues.  Today, video calls in many operators can be counted in the low thousands per day, while voice calls are counted in tens of millions.  It's the same problem as SMS, unless most people can use it, no one uses it.  Less than half the phones shipped this year have a video-telephony capability, so the situation isn't going to change anytime soon.  For MobileTV, the situation is a little more complex.  There are now at least 15 separate Mobile TV technologies, this complexity stifles the market.  Japan has now shipped more than 20 million ISDB-T (Integrated Services Digital Broadcasting-Terrestrial) mobile handsets, and Korea has 8 million T-DMB (Terrestrial Digital Multimedia Broadcasting) devices, many of which are not handsets.  However, the devices are used for the free-to-air services, so it does not improve ARPU (Average Revenue Per User) for mobile operators.

Put simply, customers are prepared to pay for their experiential video (stuff you sit down to watch on the TV), but expect the interactive stuff (newsclips, YouTube, etc.) to be free.  The line between experiential and interactive is blurring.  I hear often quoted that US students do not buy cable, they watch TV on their PC.  In the rest of the world student can not afford cable!  And most of those ex-student once they're earning get their HDTV, PS3/Xbox, and HD cable/FiOS.  Video Subscription revenues are not going away anytime soon, in the limit the customer will decide the mix of subscription (Sports/Premium), ad-supported (VoD), and download-to-own - just like people today pay for HBO to get quality content without the annoyance of adverts.

But back to the interactive video services, which account for the bulk of internet traffic.  An operator could look at this purely as providing a driver for customers to buy internet access.  Unfortunately, for mobile broadband operators the economics are a little tough to take such an approach, as discussed in this previous weblog article.  This is another example of why operators need to consider open access, that is the Telco API.  By exposing capabilities that make it easy to stream content to mobile phone / STB (Set Top Box), or extract content from mobile phones, or ensure quality of service to the mobile phone / IPTV STB, in addition to the many other capabilities an operator can expose to make an application developer's life easier.  In doing so an operator can then share in the revenue stimulated, whether it be through subscription, usage or advertising.

I'll be covering these topics and more at the Dialogic One Event in the keynote session "Carrier Video Services Trends and Opportunities" on 21st October in San Diego.

Over the past couple of years I've been helping operators understand ways they can harness open innovation.  Using a quote from Henry Chesbrough, UC Berkeley, from his book 'Open Innovation' to explain:

"Open innovation means that valuable ideas can come from inside or outside the company and can go to market from inside or outside the company as well.  This approach places external ideas and external paths to market on the same level of importance as that reserved for internal ideas and paths to market during the Closed Innovation era."

There are a number of examples of operators putting in place the programs to enable them to harness Open Innovation such as:

• O2Litmus - covered in this article
• Verizon's Open Developers Initiative - covered in this article
• Telecom Italia NexTIM - covered in this article
• Telenor Content Provider Access (CPA) - covered in this article
• Orange Partner - covered in this article
• And many more such as SingTel Partners Program and Sprint's Business Mobility Framework.

In this work I've spent most of my time with the application development community understanding their needs, and getting them in front of operators so operators understand what application developers need, NOT what operators think they need.

Just picking on a few of the critical issues:

• Capabilities from the network (e.g. location, presence, billing, address book, messaging, single sign-on, age verification, short-code provision, call control etc.) must be exposed by REST (REpresentational State Transfer) and/or SOAP/XML.  Simple and stateless, like the popular APIs (Application Program Interface) on the internet.  Not ParlayX, which is too complex, does not have credibility with application developers and hence will stifle open innovation.
• Don't nickel and dime application developers, charging for each location dip or presence check will stifle open innovation.  Rather the operator should create the conditions to share revenue, open innovation enables an operator to outsource risk and some operational costs.
• To date most operator ADCs (Application Development Communities) have been ineffectual compared to a direct sell into the operator, so there's a significant credibility gap.  If an operator launches an ADC, it must used.  The ADC must be owned by at least the CMO, ideally the CEO, and processes put in place so it becomes part of 'business as usual.'

Web2.0 open innovation models such as Apple's iPhone App Store, Programmable web, Facebook, Google's APIs, and SaleForce.com's AppExchange provide a template.  For example, Facebook in August this year achieved over 100 million users, with over 24,000 applications and 140 new applications added per day. 

Operators provide the ideal channel to market for many applications, with control over their network and devices, a billing relationship with the customer, a nationally recognized and trusted brand, high-street store presence, and a strong position in the industry's ecosystem.  However, if an operator is not as effectice as the Web 2.0 models menioned above, developers will ignore then.  Which means service innovation is lost to over-the-top services, further pushing operators down the path to become just an ISP (Internet Service Provider). 

O2 Litmus, O2's planned co-development community, headed by James Parton is not yet launched, but its unique approach already has the internet chattering about what is coming with articles in Paul Golding's WirelessWanders, Contagious Magazine, MobileNews, and Infibeam to name just a few.

I must disclose that I was fortunate to be asked by James to help him in talking extensively with developers around the world; to listen to what they need; their problems in developing and launching applications on mobile and broadband networks; their problems in working with operators; understanding from them what works and what does not work in the many operator and internet-centric application developer communities; and gaining their frank feedback on the ideas behind O2 litmus.  It was the most extensive research project I've seen in this space.

I've helped a number of operators around the world in understanding the potential of harnessing the service innovations coming from the internet.  In my opinion, O2 has made the right critical first step in treating developers as customers, listening to their needs, and crafting O2 Litmus to meet those needs.  Check out O2 Litmus, and sign-up for when it soon goes Alpha; it has the potential to fundamentally change the application developer community landscape, providing a template for the rest of the telecom industry.

Secure User Plane Location (SUPL, pronounced supple) in essence enables applications to directly talk to the AGPS (Assisted Global Positioning System) unit on the mobile phone, without the need to pay the operator for a location dip.  SUPL potentially side-lines the operator out of providing location information; without the need for a costly, complex and power-draining full GPS (Global Positioning System) unit on the phone.  From an operator's perspective, SUPL is a simple way to avoid the expense of a control plane location solution, instead using user data (IP) so it's part of the IP stack in the phone, provided they are able to control access to the SUPL API (Application Program Interface) on the phone.

Generally operators view SUPL with suspicion because AGPS chip-sets on the market lack a common SUPL API.  Many AGPS phones lack a SUPL API, one large mobile operator estimates less than one third of their AGPS handset has a usable SUPL API.  The method for an operator to ensure privacy management of SUPL when a customer is using a third party application remains unclear as its a handset issue not network PCE (Privacy Control Entity) issue.  When customers click "yes' when a widget asks to use their AGPS unit, do they realize that widget is now tracking them?  And when they find out they're being tracked, who do they complain to?  How do they stop the tracking?  The call will likely be to the operator to whom they're paying that monthly phone bill, so its' going to end up being an operator problem.

There is also a lack of agreement on handset APIs for autonomous AGPS, handset initiated AGPS and network initiated AGPS - a major gap.  In some cases the API is chipset defined, in others its handset manufacturer defined, with generally no operator or operator group taking control of the current situation.  Many operators are worried about privacy with SUPL, and many are waiting for the large operators in their market to define the standard.  Hence we have a 'chicken and egg' situation with everyone looking at everyone else to solve the problem.  Now with that said, SUPL has had some success in Japan and Korea; however, operators there tend to have far greater control over the value chain, especially handsets.  Also some vertical solutions have appeared, such as the TCS Navigator which uses their own SUPL server, and is described in my Mobile World Congress 2008 Summary weblog article.

It's also important to realize there is no definitive location technology that works throughout an operator's network.  GPS and AGPS do not well indoors, hence there is interest in handset based triangulation technologies such as A-FLT (Advanced Forward Link Trilateration) to provide enhanced location information indoors.  So we're seeing hybrid location technology solutions across CellID, enhanced CellID, AGPS, SUPL, and handset based triangulation.  This complexity in both the handset and network is delaying operators' decision making on advanced location infrastructure.  So even through LBS services have been a potential for over a decade, we're still waiting to see them take off.

The problem I've described above is similar to that faced by the On Device Portal, discussed in these articles on ODP Evolution and ODP Landscape.  And the solution to both these problems is likely the same.  If operators define a standard secure API for mobile phone browsers to access capabilities on the phone such as the SUPL API, address book, or the many other goodies isolated on the phone (just like you can do with your PC web browser today), then many of these problems would go away.  And it would go a long way down the road in operators opening their networks to the innovation made possible by the millions of developers on the internet, which brings me back to my favorite topic of the Telco API - think of this as the Telco Handset API, the complement of the Telco Network API.

In a previous weblog article I discussed how the Telco API is much more than a method of exposing capabilities from telco networks to third party applications.  As these slides show, Telco API.pdf, the Telco API impacts all services in an operator's business.  Using the classic demand curve, we can break its impact into three main segments:

• Operator Branded Services.  Here the impact can be in enabling 3rd party features to be mashed up with an existing operator branded service, or as a standard within the operator to enable capabilities to be efficiently reused across operator branded services.
• Co-branded Services.  Any emerging category of services, exemplified by 3 with their X-Series, that co-brands services, e.g. Skype powered by 3.
• Long-Tail Services.  There are three important categories within the long tail.  Enabled Applications that do not necessarily have an operator brand association (e.g. 1800 services).  Endorsed application with a preferred search position and endorsement of the operator.  And the wild wild west of Internet Applications.

The previous weblog article described how the Telco API has the potential to raise ARPU by between 12-36% depending upon the operators' situation.  Adding a little more 'meat onto the bones' of the enabled services, this sample database shows a small subset of applications and application categories, their positions on the demand curve, potential business models and example suppliers.
 
The business model is broken down further into pricing options, addressable segments and longevity (is it a fad or a core service).  This is a critical change in service management for operators, voice and messaging are examples of core long-tern services; but many new services are more likely to be fads; that gain some traction and then fade into obscurity.  Some even consider social networks a fad!

The number of services in the full database is rather long, and faces the classic issue: is it a service or is it a feature.  For example, 'Brewey finder' can only exist within a package of location based services from an "operator branded" perspective.  However, there is a small segment of the market that would just want a brewery finder, here it may exist as a standalone third party application, and perhaps due to some inspired cross-marketing achieve a level of adoption not possible if it were operator branded.  This is an important point in evaluating the services enabled by the Telco API - operators must let their ADCs (Application Developer Community) freely innovate with services that may appear competitive to some operator branded features, in the limit the market will decide based on the value an operator presents to the customer.

Here is a list of just some of the services in the table.  As you can see it's a mix of specific services and broader service categories.  The reason is in part because it is a small sample from a much large database, and also because some service categories are understood in more detail than specific services:
Ad Insert Platforms; Ad Supported gaming; Address Book Community; Asset Tracking; Bill management; Blogging / MicroBlogging; Brewery finder; Call Management, CityInformation; Co-branded Widgets, Internet Mobilization, STB Widgets; Communication enabled business processes; Community enabler; Community Widget; Conferencing / Collaboration; Conferencing widget for social network; Content search and display; Converged Communications; Couponing; CRBT (Caller Ring Back Tone); Create mobile / STB content; Dating; Directory Services; Earthquake!; eGovernment; eHealth / Telemedicine; eInclusion; elearning; Emergency Alerts; Enhanced Voice; Enterprise Community; Enterprise LBS; Enterprise mash-up enabler; Enterprise mobilization; Family Management; Family Security; Family smart limits...

While at the Voice Peering Forum I met an innovative 'Voice 2.0' start-up called Fonolo.

If you need to call your bank, airline, operator, car rental agency, travel service, or one of those many other companies that waste your time by making you wait on the phone; this service does all the IVR (Interactive Voice Response) navigation and waiting for you, then once connected to an agent calls you back.  Its one of those applications that immediately reminds you of the frustrations of waiting on the phone for 30 minutes to then go through the same conversation you've had for the past 3 months about a billing error that keeps recurring.

It also keeps track of your calls, logging everything including the conversation, so for those companies that "may record your conversation for training and quality purposes;" you can now let them know you're recording the conversation for your records to be used later if required.  I've used the service a couple of times, and it "does what it says on the tin."  You can select where you want to go for a range of companies' IVR menus, and it calls you once connected to an agent.

Currently it's a free stand-alone application, set-up takes less than a minute and it works on any phone, you simply click on the webpage, get on with your life, and when the agent is connected you receive a call.  This does lead to the potential of missing the agent as you're on another call, buy you can always 'fonolo' the company again.

It could be offered by operators as a per-use or subscription based VAS (Value Added Service) to help their customers manage the frustrations with IVRs.  From a call center manager perspective this could lower their agent's efficiency while they wait the few seconds to be connected.  However, given the person using the Fonolo service will be in a more pleasant mood, the calls could be completed much faster, so overall it could be a gain.  It's one of those issues that only the market can decide.

One difficulty I see in mass-market adoption is I'm not sure people use call centers often enough to make this a subscription service, if it's a per-use model then awareness is a problem, and of course we have the background that on-line/web self-care is becoming increasingly common.  However, there will be a segment of power-users, to which this is a compelling time-saver and aligned to the way they conduct their lives.  

This issue of mass market adoption got me thinking about how the contact list on my phone suggests people's names as I type in 'U,' then 'N' from the keyboard.  Having this as a suggestion, e.g. 'Fonolo: United 1K international reservations' would make the use case a mass-market 'no-brainer.'   Just like when you start typing a URL (Uniform Resource Locater) on your browser and a number of suggestions pop-up.  The contact list / browser of the mobile phone is definitely emerging as a vital link in how operators can make it easy for customers to add cool little applications to their communications experience as part of their Telco API plans.

For the passed two years in helping operators and suppliers innovate around the concept of the Telco API, I've built a list of web / voice / telco 2.0 application developers that could benefit from the Telco API.  Currently the list is at about 800 companies, but it's always under revision as there is significant churn, consolidation, and new companies being added.  The list is in no way a complete picture of the relevant application developer landscape, just a continuous work-in-progress.  Attached is a sample of the web / voice / telco 2.0 list which shows the companies alphabetically, and was in part developed with Ideas and Plans.  The Category and Rating sections are simply methods I use for selecting and prioritizing the list based upon specific customer needs.  I've learned through painful experience its critical to keep the categories and ratings simple to avoid the list becoming burdensome to use and manage.

Defining the categories:

• Context Based, services that use presence, location or other customer contextual information, for example location based services such as geo-tagging pictures;
• Business, services focused upon the business segment, for example business messaging;
• Social, services that create a community of users that share, for example mobile communities;
• Financial, services including mobile payments and banking, this was introduced because of several specific project needs;
• Entertainment, services that present content to customers, e.g. internet TV;
• Voice 2.0, services generally focused upon embedding voice/communications into everyday activities or using VoIP for cheap calling, for example voice to text; and
• Telco 2.0, services generally focused upon innovation within the service provider business model.

The categories can be combined, so for example you can search for applications that are both context based and business; or social and entertainment and voice 2.0.

Defining the ratings:

• Viable, objective criteria (funded, listed, profitable) and opinion (gut-feel on company and position in category) on the company's viability;
• Cool, objective criteria (clear market segment) and opinion (gut-feel on application's potential) on the application's value to customers; and
• Telco Value, objective criteria on value proposition to an operator.

The ratings provide a simple method to prioritize potential lists of application developers.

As an example, say you want to find a list of the Voice 2.0 application providers, just select the Voice 2.0 category and a rather long list emerges:
Spinvox, Utterz, Angel.com, Funkycall, Call Genie, Gearon (Fidg't), Backflip software, BlueNote Networks, Fring, Goog411, ifbyphone, Jaduka, Parus Interactive, Ringcentral, Rminder, Sitòfono, Snapvine, Evoice, Iotum, Phonetag (nee Simulscribe), Razz, Ribbit, Robocal, Sightspeed, Talkr, Tokiva, Vbuzzer, Youmail, Blabberize, Enablr, Evoca, Gabcast, Gaboogie (Lypp ), Springdoo, Trixbox, Truphone, V4s (Orb), Vapps, Cellity, Cubic Telecom / MAXroam, JAHJAH, Jaxtr, Saynow, Thinkingvoice, Voicequilt, Voicethread, Vopium, Voxbone, WaxMail, Yoomba, Challenger mobile, EQO, Gizmo5, Hullo, MobileMax, Morodo / MO-Call, Pheeder, PhoneGnome, TalkPlay, Tpad, TringMe, Truphone, Velophone, Vephone, Vyke, WiFiMobile, Yodio, Allfreecalls, Barablu, Blobber, Blogtalkradio, Ether, Gizmo, Mobivox, Resellular, Talkety, Talkster, Voipdiscount / Voipcheap, Yackpack, Zozoc, Callthefuture, Juvino, Talktrust (Numbr), Wizzl, Yeigo, and Phonefromhere.

Or say you want a list of mobile payment / banking application providers, just select the Financial category and review the list to give:
3Bill, Mfoundry, PayMate.In, Clairmail, Firethorn, Frontstream Payments, Obopay, C-Sam, gWallet, Monetise, More Magic Solutions, Paypal Mobile, Splashdata, Textpayme, Upaid, Valista, Zong, Ixaris, Mi-Pay, Payment One, Sermepa, Fe-Mobile, Paypoint, Payter, Icache, Paymate, and Kuscash.

As I mentioned at the start of this entry the web / voice / telco 2.0 list is a work in progress, if you see any gaps or errors please let me know, thanks.

The VPF has become a must-attend conference for anyone focused on service innovation in telecoms, with over 200 attendees this year, its certainly bucking the trend we're seeing in conferences closing.  This conference brings together a diverse mix of the telecom value chain: the IP Exchange and data center providers (Terremark, Telx, CRGWest); innovative applications that have a communications bias (Fonolo, Vidtel); traditional mobile, fixed and broadband operators (Rogers, Orange, Telecom Italia, Verizon, Swisscom); service layer suppliers (Oracle, Telcordia); enterprise communication service providers and integrators (Backflip, ifbyphone); and good mix of the Voice 2.0 leading lights (jahjah, Jaxtr, Tom Howe).

Keynote Session was from Gary Kim.  Bottom-line was the major transformation facing Operators is changing business models.  Simply witness the focus on bundling, advertising, exposing capabilities to applications (Telco API), etc.  

Telecoms in Uncertain Times Session.  Mike Lee (CSO Rogers) captured the essence of the discussion with his three points.  The move from commoditized linear TV (broadcast) to on-demand, the culture change to open and real-time; and the critical importance of regulation to foster innovation through market forces.  Mike's point of the cable operator's focus away from commoditized broadcast highlights a perplexion a feel with mobile operators who focus on broadcast TV.

There was also an interesting discussion on why the US is relatively low on the broadband league tables.  In my opinion it's simply due to inadequate US regulation on LLU (Local Loop Unbundling) pricing that stifled new entrant broadband ISPs in the US, which have been a driving force of innovation in markets such as the UK and France.  However, on the flip-side of that issue is it has enabled Verizon to roll-out FiOS, so for about $100 I get triple play (hundreds of channels including on-demand HDTV, broadband (20/5 Mbps) and good old fixed line voice (which I still use as its good quality and reliable). If I compare this bundle to UK prices, its a fair deal.  That last point on good old fixed line voice was also raised by Gary Kim, he stated that he's changed his mind on voice, it is not a commodity, because mobile voice, Skype voice and PSTN voice are different, and the use cases are starkly different.

Carrier Hotels Session (Internet exchanges, interconnect (meetme rooms) and data centers).  These guys are witnessing the confluence of the internet going video, the flattening of the internet (as content providers connect directly to networks) and the explosion of SaaS (Software as a Service).  It's interesting to note the background of some of the exchanges, one with a property management background explained that they get $4-5 per sqft when they rent to people; and $30-50 per sq ft when they rent to computers.  The focus of this industry is concrete, AC, power and interconnect.  These exchanges provide a possible point for operators to interconnect their service delivery capabilities.

My session on Telco 2.0 and Web 2.0: making Money Together? brought together Telcom Italia, Oracle, Swisscom and Orange.  Francesco Fraccalvieri focused upon describing NexTIM, their website for exposing new services for their '360 degree innovators,' their early adopters.  Ty Wang, Oracle reviewed their experiences across both operators and application developers, highlighting the importance and challenges of exposing customer profile information and charging.  Stefan Kuentz, Swisscom described both their consumer and business experiences in exposing capabilities.  Asha Vellaikal, Orange described their broad range of activities across Orange's Widget, picture sharing and OpenID APIs, which are now coordinated through the Orange Partner site.  

The discussion demonstrated the proactive approach operators are taking to foster service innovation, but highlighted the dichotomy of operators taking an approach focused on protecting customer sensitivities and experimentation; while application developers are focused upon speed to cash and the freedom to innovate.  This brought up the role of application aggregators such as uLocate, which can play an important role in managing this dichotomy.  The issue on how the diverse operator initiatives can be aligned to present a common front to application developers was left unanswered.  However, I'll take this issue up on a later weblog entry.

Voice Mashup Session: provided some specific real-world applications from ifbyphone, Jaduka, Jaxtr and Backflip on how communications can be embedded into business processes and everyday activities.  For example, improving the accuracy of lead generation for new car sales.  Many of these required customization to the specific enterprises requirements.  This raise the important role local SIs (System integrator) and how carriers need to expose capabilities that SIs/VARs can use for the SMB segment.  Here BT's relationship with RingCentral provides a small but useful proof-point.

Overall the VPF was a pleasant surprise, it presents a cost effective event to meet the main players across the ecosystem of communication service innovation.

Survival is the mother of innovation.  As customer behavior, rather than technology and competition, significantly impacts a service provider's business, threatening the core revenues; the Telco API (Application Program Interface) is one method for operators to foster innovation on their networks.  The Telco API enables operators to expose capabilities from their networks such as location, presence, charging, authentication, etc.  Based upon twelve studies [Reference 1] performed with operators around the world, the Telco API has the potential to raise ARPU (Average Revenue Per User) by 36% across operator branded, co-branded and third party services.

Just exposing the Telco API is not good enough; operators must implement an application developer community (innovation community).  Making it easy for applications to get on the operator's network, easy to be discovered by early adopter customers, and all within an easy to use community tool that enables continuous application development to get the 'recipe right' for the local market.  Based upon extensive market surveys on forty developer communities six corner-stones of community success are identified [Reference 2]:

• Known the Audience: identify and build a strong relationship with the innovators;
• Tools and Education: there's never enough sample code;
• Communications and Marketing: Sell your best geeks, others will follow;
• Metrics linked to business performance;
• Business Model baked into the API; and
• Integration into the operators' core processes - the innovation community is owned by the CEO.

After building the brand and the network, the application developer community (innovation community) is the next most important leg of an operator's business.

Full text of the "Opening Up the Soft Service Provider: The Telco API" paper.

Technology Appraisals, a consultancy based in the UK, has recently completed a comprehensive global study on "Low Cost & Mobile VoIP."  The study profiles 30 new mobile players in detail and gives summary tables, illustrations and comparisons. It provides a clear picture of who is in this business, where they come from, where are they operating, who is backing them, and what is on offer.

I maintain a list of about 700+ Web/Telco 2.0 application companies, which includes the low cost and mobile VoIP players, and this report showed I'd missed several, so it's definitely comprehensive.  The providers evaluated include Barablu, cellity, Challenger Mobile, Cubic / MAXroam, EQO, fring, Gizmo, iSkoot, JAJAH, Jangl, jaxtr, mig33, MiNO, MobileMax, MOBIVOX, Morodo / MO-Call, Nimbuzz, PhoneGnome, Raketu, Rebtel, Skype, TalkPlus, Talkster, Tpad, TringMe, Truphone, Velofone, Vyke, WiFiMobile, and Yeigo.

About two years ago I did a report on a "Market Assessment of VoIP Bypass Roaming and Operator impact / Proposition: Regulations, Tariffs, Deployment Options / Feasibility, Market Feedback, Operator Business Case, and Operator Impact Analysis / Proposition."  As mobile broadband is now taking off we're entering a phase where the opportunities for "low cost and mobile VoIP" are increasing.  

As roaming rates increase for those outside the EU.  For example, Informa Telecoms and Media claims that in general roaming charges have risen by around 163% since the EU capped rates at 0.49 euros a minute for making calls and 0.24 euros for receiving them within the EU.  The attractiveness of these services increases.  An analogy is frequently drawn between these companies and Skype, in that it did not significantly impact the landline market, because of the inconvenience of being at the PC and have a headset connected; and to the recent failures of Jangl and TalkPlus compound this view.  As always the obvious takes longer to happen than we think, mobile access to the internet "was going to happen in 2000," and 8 years later its just taking off.  With start-ups they only have about 2 years to wait for the market, after which time the investors pull the plug.  So such failures are part of the innovation process, as investors place bets on when the market will take off.

However, given the smarts of a mobile phone and laptop, the applications can become 'hidden' from the user experience, i.e. I just select a contact in my address book and call, then the application makes the decisions behind the scenes on how the call is made.  All I see are greatly reduced roaming rates.  We're already witnessing niches adopting these applications, particularly families that are spread across several countries, small and medium sized companies with operations in several countries, and of course students.  As the usability issues become transparent to the core use case of "select contact and press green button," it will be interesting to see if these niches are able to drive into a broader segment of business customers that can impact operators into action.

The title is a bit of an oxymoron, how can a 'start-up' also be the largest inter-operator mobile community in the World?  I'm being a little loose in the definition of 'start-up' as airG is really a profitable, established business.  However, they still have the entrepreneurial zeal of a fresh-face start-up, and being secreted in Vancouver has enabled them to achieve something quite remarkable with little fanfare.  

While Bay Area mobile community start-ups struggle with triple digit churn, struggle to break passed the 1M customer mark, and raise tens of millions in VC cash due to the perceived value of the passing 'eyeballs'.  airG's mobile community has more than 20 million unique users worldwide and is interconnected to more than 100 mobile operators and media companies globally including Sprint Nextel, AT&T, Rogers, TELUS, Virgin Mobile, Orange, Boost Mobile, Vodafone and MTV Asia.  And most importantly is making a profit.  Yes! a Mobile 2.0 community that's making a profit rather than burning investor cash in the hope that advertisers do not wake up to the fact that they're being used by the rest of the value chain, i.e. some social networks are seeing click-through rates of 2-4 per 10,000 impressions; that's not an advertising campaign, that's an accident!
 
airG was founded in 2000 by Frederick Ghahramani, Vincent Yen and Bryce Pasechnik, originally called AirGames, they focused upon WAP games.  They quickly discovered that game-play on WAP isn't much fun.  However, they had a lobby and chat function, then soon discovered that people didn't logon to AirGames to play WAP games, rather to chat.  Hence the name change and focus on community services.

airG highlights an important point that I touched upon when I reviewed Miniweb, just as Miniweb is not putting the web on a TV, its creating interactive TV.  airG is not putting a web-based community on the phone, its enabling a mobile community.  The user experience is different.  In North America and Western Europe, broadband internet access has a high penetration, most people access their web services (e.g. communities) through a PC, and some treat the mobile as an 'always-on' connection to their communities when they're not in front on the PC.  This clouds the perception of most in the industry as the vast majority of people in the world do not access the internet through a PC, they access it through a mobile phone.  For example, there is over 20 times the number of mobile customers to broadband customers in India, here community is accessed through the mobile.  airG has demonstrated the use case is significantly different, even in countries with high broadband internet penetration.

A critical issue with mobile communities is interoperability across network 'islands'.  We'll be discussing in the panel session "Telco 2.0 and Web 2.0: Making Money Together?" at the The Voice Peering Forum (June 23-24th, San Francisco).  airG has shown the power of enabling inter-operator mobile communities, and built a profitable business.  Its good to see a Mobile 2.0 business being built on sound commercial principles, rather than the usual Bay Area process of "burn the VC cash giving stuff away for free to get as many eye-balls to your site/application as possible, create a monetization story, find a buyer, and exit on an inflated multiple before the business model needs to be really proven out."

As requested by reader feedback, I'm providing some foresight on up-coming conferences I'm attending, rather than just reviewing conferences I've attended.  For June I'll be running panel sessions at Sigma Systems's first user conference and at the Voice Peering Forum.

Sigma Systems's first user conference (June 4th-6th, Barton Creek Resort, registration is free), will explore the next generation of consumer and business oriented services, including insight and discussion around emerging trends and technology developments in the following areas:  targeted advertising, evolution of commercial VoIP & data services, global deployments in mobile broadband services, evolution to on-demand services, converged applications over video networks, data and multimedia services and IT back-office transformation.  In the OSS Consolidation article article I included Sigma Systems in the Service Fulfillment Landscape.

At the user conference I'm running the panel session "Where's the Mobile Industry Going?" with John Namovic, Managing Partner at Deloitte; and Wedge Greene, Industry Guru.  The session's objective is to help the audience understand how mobile is going broadband from those working on the 'bleeding edge' of the mobile industry. Providing a comprehensive global overview of the mobile operator's evolution to broadband; including network evolution, new services and applications, emerging business models (MNO vs. MVNO), and review of important lessons learned.  In particular we'll be reviewing mobile broadband services, evolution to LTE (Long Term Evolution), xVNO economics (Virtual Network Operator (where x = mobile, fixed, converged and possibly even cable)), and FMC (Fixed Mobile Convergence) successes and failures.

The Voice Peering Forum (June 23-24th, San Francisco), a biannual conference, brings together over one hundred unique organizations from all segments of the information technology and telecommunications industry to network and discuss the latest in peering, routing and interconnection of networks and the applications they support.  A good overview of the event is provided in this video.  I'm running a panel session on the first day entitled, "Telco 2.0 and Web 2.0: Making Money Together?"  This session will examine how the Web 2.0 paradigm is impacting telcos and how they are adapting to co-opt this paradigm to maintain service relevance in the IP-centric world.

Some of the questions we'll be discussing in the panel are:  What is meant by Telco / Web 2.0?  What is the state of current service provider Telco 2.0 / Web 2.0 activities?  What capabilities can telcos expose that Web 2.0 companies need?  What are Web 2.0 companies doing today to bypass the telcos for various service enablers?  Where is the money to be made by the telcos and saved by the third party entities?  How are operator's going to make these capabilities inter-operable across their network 'islands?'  Peering 2.0!

On the panel are Mike Lee, CSO Rogers; Francesco Fraccalvieri, Head of Innovation Telecom Italia; Stefan Kuentz, Swisscom; Asha Vellaikal, Orange; and T. Ty Wang, Senior Director, Oracle.  The objective in bringing together such a senior and diverse range of panel members is to generate a diversity of insights from people at the bleeding edge of service innovation, but link it back to the brutal simplicity that for such innovation to be successful it's got to work between operators.

I hope both panel sessions will provide some unique insights and through bringing together such senior practitioners in the industry provide an opportunity to share best practices.

Just summarizing my panel session speech on day 3 of SofNet, "A Pragmatic Approach to Developing IMS-Services."  I addressed two questions I'm often asked.

"Is IMS dead?"  Both Sprint and Verizon are deploying their flavors of IMS for the simple reason they decided voice over EVDO (the CDMA version of 3G) will be supported by VoIP, so they needed a standard IP session control layer, to which IMS provides a solution.  I discussed this previously in the "The Divergence of CDMA and UMTS Operators on IMS" weblog entry.  By 'flavor,' I mean they are using some of the specifications within IMS as a guide, its not a 'soup-to-nuts' implementation of the current IMS specifications.  Now NTT and SKT have taken an aggressive approach to deploying IMS, with a number of services including PTT (Push To Talk) and virtual PBX, but they traditionally adopt technologies early to give their national suppliers an international competitive edge with early reference customers and accelerating their national suppliers' position on the learning-curve.

For UMTS operators voice is supported as a circuit over the RAN (Radio Access Network), so there is no need for an IP session control layer, yet.  Hence most UMTS operators have not deployed IMS.  On the fixed side, most operators have implemented softswitch solutions, and in some cases there are scalability issues, there they are evaluating whether IMS provides a more scalable solution, but the key word is evaluating.  So IMS has not failed, rather its core capability of IP session control is seeing pragmatic deployment, where it makes business sense.  Now, standards bodies as always tend to go beyond their initial scope, so the standards engineers can maintain the frequent flyer status, and IMS has moved into service management aspects.

This leads to the second question I'm often asked, "Are IMS and SDP in competition?"  Immediately we have the problem of definition, what is an SDP?  Paraphrasing what Humpty Dumpty said to Alice, "It means whatever I chose it to mean."  In practice there are three main elements, BOSS (Business and Operational Support Systems), Content Delivery and the Telco API (checkout this entry for more info "The Telco API: Potential to raise ARPU by up to 36%").  Here we have lots of deployment examples such as Sprint's business mobility framework, AT&T's U-Verse, Airtel's managed SDP, Vodafone Live! etc.  So the SDP is happening, and is more successful than IMS.  Its focus is service management, not IP session control.  So at present they are not competing, and if the focus of IMS remains IP session control then they will not compete.

But back to the topic of the panel, IMS-Services.  If someone starts talking about IMS or SDP-Services, they have an agenda, they're trying to sell or promote a network technology, and making a fundamental error in looking at the problem from the wrong-end.  Services are supported by capabilities, and those capabilities are implemented with network technologies.  Services come become technology, as technology enables implementation.  Of course user experience comes first, and then services fulfill the experience, but that's covered in the "A Critical Gap that Means most Service Platform (IMS/SDP) Business Cases Keep Failing" entry.

Overall the conference was worth attending, though there was a significant gap around specific enabled services.  To claim the conference is focused on Software and Networks will require much greater participation from the other members of the value chain, including media, web 2.0 companies, and internet application developers.

Summarizing day two of SofNet.

Panel session, "How Can 21CN Help Make Customers Successful?"  was a who's who on UK telecom executives with John Cunliffe, Ericsson; John Frieslaar, Huawei; Geoff Hall, Nortel; John-Paul Hemingway, Ciena; Phil Dance, BT; David Soldani, NSN; Andy Stevenson, Fujitsu; and Phil Tilley, ALU.  With so many suppliers in such a public forum, we were not going to hear anything interesting.  A good question was "What are the top 3 enterprise services enabled by 21CN."  The answer was a general description of network IT Services and cloud-computing; which are available without 21CN.  This unfortunately became a theme for day 2 of the event, lots of discussions on architectures, potentials and capabilities, but a dearth of discussion on what the innovators (web2.0 companies) want and what are the specific services.

KeyNotes

• Helmut Leopold, Telekom Austria, discussed their SDP experiences. Good review on the challenges facing a small operator, especially on processes which are "90% of the headache" in any network transformation or new service launch.  As discussed in yesterday's weblog entry operational efficiency is the best understood part of the SDP business case: Helmut mentioned new product launch effort reduction of 70%, and TTL (Time To Launch) reduced from 9 to 5 months. An important point he raised was the SDP enabled greater transparency to understanding profit management, however, a critical issue is the BOSS (Business and Operational Support Systems) organization tends to mask such data to maintain control, hence he recommended the need for "aggressive centralization."
• Sally David, BT.  Discussed next generation wholesale business models.  Covered a number of examples of wholesale business models such as outsourcing voice (to Virgin media), managed access (mobile backhaul), QoS (Quality of Service), and security.  Good focus on the capabilities operators can offer to corporate customers and service providers.  

Panel Session: Leveraging SOA to Achieve Flowthrough for IP-Services

• Brian Buggy, Amdocs.  SOA is just a tool, need to define the model that needs to be common across all services whether mobile, cable, broadband or internet.  Upon receipt of an order it's then decomposed, designed, implemented and tested.  Critical step in the decomposition process is the mapping of customer facing services to resource facing services.  Highlighted the gap that exists in the TMF SID (Tele Management Forum Shared Information/Data) on the level of decomposition to enable re-use of resource components across services, else operators end up rebuilding silos within a SOA framework.
• Francesco Caruso, Telcordia.  Described how the core capabilities of SOA: semantic (common language), transport (common orchestration) and legacy wrapper can be applied across the product lifecycle (CRM, order management, charging/billing, provisioning/activation and service assurance).  This reminded me of the the approach taken by AT&T U-verse, which is a great case study on using SOA within a mixed (NG and legacy) environment.
• Biru Chattopadhayay, Tech Mahindra.  SOA is a little like SDP in definition, it depends upon the user.  Challenge that there is no agreement on what comprises an SOA-compliant implementation, so SOA is not generating harmonization given the variety of implementations, platforms claim SOA compliance, when in practice significant integration is still required.  SOA is not a magic bullet, still requires good design and central management.
  
• Bob Titus, Netcracker.  Today results of SOA implementations on cost saving, flexibility, improved TTL have not met those seen in other industries.  Bob highlighted the model-driven architecture gap, as per Brian Buggy's presentation.
• My take-away:  What should by now be common system across most operators remain bespoke.  I'd argue the problem is not technology, as businesses in other industries have achieved significant commonality in their systems thanks to SOA.  Rather the operator's BOSS organization guarding silos of information to maintain their organization.

Panel Session: The Reality of Convergence: Operator Experiences

• Thibaut Roussel, Orange.  Summarized Orange NeXT (New Experience of Telecom) strategy and localization issues across its OpCos (Operating Companies).  Unik (Orange's FMC service, c.f. BT Fusion): 500k customers in Feb '08, 25% of customers use at home and in the office (SME is a target segment), main selling point for customers is unlimited calling  that has resulted in an additional 67 call minutes per month.  Business Everywhere (remote intranet access): 910k users (600k in France) as of Feb '08, 24% annual growth, targeting MNC and plans to expand to SMB and SoHo segments.  
• Paulo Tavazzani, Fastweb is an all-IP triple-play network based in Italy.  Deployed an integrated CPE (Customer Premise Equipment) for converged voice, video, and data for all devices, including mobile, in the home.  No plans for IMS, soft-switch is good enough, will only implement IMS when business case justifies.  Fastweb are the only convergent MVNO in Italy, hence focus on converged services to differentiate from other MVNOs and try to keep calls on their network as much as possible to manage costs.
• Take-away: Good examples of service innovation that focuses upon the importance of providing significant customer value to stimulate adoption, even though the technologies are far from mature.

Overall Summary  

• The telecom industry is unfortunately still too 'fat and happy.'  For example Verizon announced first quarter results yesterday where net income rose 10% to $1.64 billion from $1.5 billion, and sales rose 5.5 percent to $23.8 billion.  Isn't the US in a recession?
  
• Most of the discussion at the conference is on capabilities and potentials; hence the SofNet ideals remain trapped between the CTO (who sees the strategic threat) and the CMO (who says, "Show me the money!").
• Recommend each operator identify for their specific situation 5 or 6 services they can easily enable and just do it to work through organizational issues in opening the network, because its still another 2 or 3 years before they'll have openness cracked and the strategic threat will have materialized into their financial results by then.
  

SofNet brings together three of the main drivers in the telcom industry, NGN (Next Generation Network), Web 2.0 and the telecom service layer (also known as the SDP, Service Delivery Platform).  Now when it comes to the definition of SDP, I'm usually reminded of this quote from "Through the Looking Glass:"
`I don't know what you mean by "glory",' Alice said.
Humpty Dumpty smiled contemptuously. `Of course you don't -- till I tell you. I meant "there's a nice knock-down argument for you!"'
`But "glory" doesn't mean "a nice knock-down argument",' Alice objected.
`When I use a word,' Humpty Dumpty said, in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.'

So let's see what we learnt on the definition of SDP on Day One.

The morning session I attended was entitled "Industrial Revolution 2.0: Are Service Delivery Platforms the New Production Line?"  Summarizing the presentations and discussion:

• Angelo Morelli, Accenture.  Highlighted the importance in how services are created as Web2.0 principles of lightweight programming models, mash-ups and continuous beta gain main-stream adoption.  Positioned SDP as managing the complexity of aggregating the business models between network operators, service providers, VAS (Value Added Service) aggregators and Web 2.0 companies.  Also positioned the unified user control panel (an element of the SDP) to manage the complexity of transferring content and services between devices.  The unified control panel is one of those technically feasible capabilities, but it's practicality dubious, e.g. iTunes goes onto the iPod easily thanks to Apple, for those geeks that also want to have their MP3s on their Sony PS3 there's a number of free ways from using a USB to setting up a media server on the PC.  Here the SDP is defined as providing business and content adaptation between players in the value chain.
• Giorgio Ramengi, H3G Italia.  H3G Italia has 8M customers, 39% UMTS market share in Italy, and 800k (10% penetration) Mobile TV customers.  H3G has used an SDP over several years for its m-sites that enable 3rd party services on their portal.  They used the SDP for the launch of the MobileTV, which took only 6 months from license grant to launch.  Using an SDP enables trial within 2 months, free-to-air launch in 3 months, and full PayTV launch in 5-6 months.  They currently achieve 10% of mobile TV revenue from advertising.  H3G provides a realistic and focused SDP application note.
  
• Jonas Wilhelmson, Ericsson (Drutt), explained the emerging Multimedia Marketplace composed of the following actors: Media, Customers, GAMeY (Google, Amazon, Microsoft, eBay and Yahoo!), Internet Services, Advertisers and Operators.  The role of SDP is to hide complexity in this marketplace, speed time to market, and lower costs.  Quoted data from H3G Scandinavia that 70% of customers access the operator's portal and 15% ARPU comes from VAS.
• James Steadman, Oracle:  Gave the Oracle pitch on the SDP being composed of OMA OSE, J2EE application server, and SOA for integration.  Gave an insight into the CXDN (Communication Experience Design Notation) they've developed with BT, and will open source later this year.  CXDN re-uses SOA tools from the enterprise, to make it easy to create applications agnostic to network and easily integrated into an enterprise's business processes.  The CXDN has significant potential for the industry, and the addressable market is where telco's can provide significant immediate value through the Telco API.
• Richard Mishra, Amdocs.  Highlighted the important of SDP's (Service Management Layer) awareness of the resource layer (network capabilities, e.g. QoS over a RAN or DSL link).
  
• I asked a question, "If the SDP saves money and enables new services, what are the figures?"  Broad consensus on opex savings of around 50%, which is in line mt projects, perhaps even on the conservative side.  No commitment to ARPU uplift potential, on that I have a weblog entry The Telco API: Potential to raise ARPU by up to 36%
  

Afternoon Key Note

• Matt Bross, BT.  Gave the usual world-class inspirational pitch.  Highlighting the shift in power to the user, increase in complexity and importance of green issues.  Gave a great example on the success of BT TradeSpaces in dramatically improving BT's relevance to the SMB (Small Medium Business) segment.  I often use TradeSpaces as a case study on how operators have a role in communities beyond simply enabling access to Facebook.
• Bhaskar Gorti, Oracle, provided some much needed figures on the reality of an operator's business.  Quoting observed SDP savings of: development cost and time reduced by 50%, reduced IT support cost of 30%, RFT (Right First Time) improvement of 30%, TTL (Time To Launch) improvement from 30 days to 1 day, and lowered provisioning costs by 30%.  He made and clearest statement of the show, that the SDP is about improved productivity (operational performance).

Overall, I still feel like the "Through the Looking Glass" quote is relevant in the definition of the SDP.  However, there is broad consensus and specific numbers on the process improvements provided by the SDP, what is lacking is the same specificity on the services.

"But shouldn't our suppliers be building the developer programs?" I hear some operators asking. However, infrastructure suppliers make money by selling boxes, software licenses, maintenance and support; those suppliers do not understand the end customers as well as the operator. If they do, then the operator will likely not be independent for long. There is a new category of 'Application Aggregators' that bring a menu of applications, e.g. uLocate and Useful Networks aggregate location based applications; and are dependent upon mutual service success with the operator, not selling boxes or software licenses. The bottom-line is all operators will need to combine the application eco-systems of infrastructure and handset suppliers, application aggregators and their developer communities. Only those operators in a monopoly or have resigned themselves to be a utility bit-pipe provider need not worry about such issues.

In researching application developer communities across a number of industries, reviewing with the creators and community members the successes and failures, here are some topics to consider if an operator decides to build a developer community:
 
Audience:

• Know your geeks (application developers). For many operators there are local SIs (System Integrator) and VARs (Value Add Reseller) already solving the customers' problems, this is a critical group to bring on board. This generally addresses the SMB (Small Medium Business) segment, but there are also local developers applicable to other customer segments, they're not all based in Silicon Valley or LA. And localization will become critical for an operator's long-term success against GMAY (Google, Microsoft, AOL and Yahoo!).
  
• Know your early adopters. These are generally high spending customers that will trade some of their time for exclusive access to the latest applications and have their opinions matter.  This is of great value to geeks as they lack customer access that operators can provide.

Tools and Education

• The program needs to use the latest protocols, environments and community tools. Check out Saleforce.com's Appexchange; and Orange's Widget, picture sharing and OpenID APIs. To win, an operator must educate (marketing); to educate an operator must speak (blog); to speak an operator must do/show (code examples and success case studies). The more code examples the greater the addressable pool of geeks, because less able but perhaps more innovative geeks can then "cut and paste" capabilities together.
• Do not require registration or login to educate, only have registration if the geek wants to make money. Beta programs (without a clear path to cash), NDAs and legal documents will kill any community no matter how large the operator.

Communications and Marketing

• Community communication by the operator needs to be made by Geeks, e.g. bloggers, writers; IRC (Internet Relay Chat) / wiki / forum addicts; regular conference presenters that draw a crowd; and have a track-record in writing code samples and helping others geeks.
  
• Have a "Geek Advisory Board" with expertise in the platforms, customer verticals and known to the geek community.
  
• Sell your best geeks, others will follow. Communicate success stories from the community's launch. Contextual application search to help customers find preferred/certified applications that are relevant to a customer's particular circumstance is vital.

Metrics

• Program must be aligned with the operator's overall business goals. Metrics include things such as number of new geeks, number of downloads, number of active developers, number of transactions, revenue generated from APIs.

Biz Model

• The business model must be baked into the API. Ultimately, the Telco API is just a big business development deal. If the Telco API helps geeks make money, then so does the operator.

Integration

• The application developer community should not be owned by the CTO. After building the brand and the network, the application developer community is the next most important leg of an operator's business. It must be owned by the CEO, and integrated into Marketing's processes, so the innovations get out to the customer and are effectively monetized by the operator.

The above topics may appear obvious in building an application developer community, but the challenge is getting them simultaneously implemented.  Have a look at the many developer communities being launched against these 6 topics. An operator's application developer community is not a lab's project, nor something that can be released as a Beta; it's a core business assets, on a par with brand and the network, and must be led from the top.

HomeCamera enables people to securely see what's going on at home without being an expert in geeky stuff like DDNS (Dynamic Domain Name System), NAT (Network Address Translation) and port forwarding, which are generally required for the home surveillance solutions on the market today.  HomeCamera aims to be an easy-to-use home surveillance system, with any webcam, any PC, and any Internet connection; targeting the average PC user.  The service is live and currently free because its in beta.  Once launched it will remain free with ad-support, there will also be subscription models that add capabilities and remove the advertising.  When I talk to operators about this simple proposition the common refrain is, "We thought about doing just that, we just never had the time."  HomeCamera is a spin-out from M1 (Singaporean mobile operator).

Google averages between 100k-200k relevant search terms per week on home security and monitoring, so there's definite customer demand.  The estimated number of global broadband homes with webcams in '06 was 60m according to Logitech.  IDC estimates 21m webcams will be sold in 2008 alone; average annual worldwide growth rate of 9%.  More importantly to the HomeCamera proposition there were roughly 600k network cameras sold to homes in 2006.  A network camera is a standalone unit that is used for surveillance not web chat.  For example, D-Link has added HomeCamera support into its 2120 WiFi network camera.

The use cases include monitoring one's home, kids, the elderly, pets, and domestic help.  I also think HomeCamera provides a great example of how third party applications can use the Telco API.  Take this use case as a simple example: Jim recently hired a nanny to look after his two young sons.  When he's on the road he can check-in from his mobile phone, just to make sure everything is OK.  He also shares access with his parents so they can check in from their TV.  The operator could expose capabilities such as Single Sign On (from Jim's mobile phone or his parent's STB (Set Top Box) they can access the camera directly without the hassle of entering usernames and passwords), service provisioning (Jim can set up the service for his parents, all they need to do it press the widget button on their remote), IPTV and mobile video streaming capabilities (to ensure quality delivery of video to both his mobile and parent's TV without HomeCamera dealing with the hassle of video clients and QoS (Quality of Service)).

As discussed in the article on the Telco API, the operator could use this service either own-branded, co-branded or as a third party application.  You could imagine a scenario where it's an option on the operator's Family Plan.  The more challenging part is the business model, but as discussed in the Telco API article there are a number of options which generally will be dependent upon the customer and how the operator chooses to charge for use of its network capabilities.  My recommendation is the model must be simple, common across many applications, and at this point in the commercialization of the Telco API its more important to get out there and experiment commercially (continuous beta) rather than spend time crafting complex models and agreements.

What is a 'service delivery architecture'?  It really depends upon with whom you are talking.  Are they are a vendor trying to sell IMS (IP Multimedia Subsystem), or a Java games download platform; or are they an operator responsible for value-added communication services, IPTV, or content services.  Each will likely give quite different answers.  Service delivery architectures have a long history; their roots can be traces to the FN (Feature Node) that emerged in the intelligent network (IN) concept defined by the ITU-T back in the 1980s.  In the FN a SCE (Service Creation Environment) enabled operators to create new communication services without the need to change the software in the exchanges.

This evolved into the IN SDP (Service Delivery Platform), an architecture that enables re-use of service components.  Most operators today have IN implemented in their networks, though most of the SDP implementations tend to be bundled into a specific service implementation, for example caller ring back tone.  The IN SDP has not achieved the ubiquity of deployment as a horizontal layer within the telecommunication software stack, rather a component of a vertical application.  The move from vertical (stove-pipe) to horizontal: faster and cheaper time to market for new services and enabling service innovation independent of switch vendor did not significantly happen.

As networks have evolved from circuit-centric to packet-centric, the SDP has started to extended its reach beyond communication services, to include content services, streaming services, and even broadcast services.  With this move the use of SOA (Service Oriented Architecture) as an integration framework has emerged, given the successful implementations of SOA for BOSS (Business and Operational Support Systems) systems.

So we arrive at today, where the SDP is has come full circle and is positioned again as a platform for the creation of new communication services, but this time in the IP domain encompassing IMS.  Since 1999 IMS (IP Multimedia Subsystem) has been standardized by 3GPP, it enables service control for IP based multimedia communications, across any IP based access.  So the SDP is now positioning across all services and all access, an all-encompassing service delivery architecture, with a total market size of roughly $2B in 2007, source OSS Observer.

A commonly used service delivery platform definition is an IT-based environment, enabling service creation in an environment that does not rely on a specific network element enabler. This comes from the need to cut costs in the service creation process; in saturated markets service providers want to differentiate through their service offerings.  And the need to enable third-party companies to provision services through the service provider environment.  Typically, most SDPs include a service creation environment, a service orchestration environment, a service execution environment and third-party management.

Another way to look at the SDP is to relate it to boxes/functions we already see in an operators network:

• Content Delivery Platform, e.g. a platform that enables content such as ring-tones or movies to be successfully presented and delivered to customers.
• Communications Gateway, e.g. a Parlay server that exposes call control capabilities.
• Telco API, e.g. The exposure of network capabilities across communications and content to third parties.
• BOSS, e.g. a service creation process aligning to 'Common Capabilities.'  A Common Capability is used by many different services e.g. IVR; an 'authentication' common capability that bundles the capabilities of an AAA server with some of the features of an ID management system; and accounting functions, e.g. an internal directory server.

Taking this view it becomes a little clearer why there are just so many suppliers that fall under the SDP label, a subset is listed here: Accenture, Acision, Alcatel-Lucent, AePONA/Appium, Airwide, Amdocs/Qpass, BEA/oracle, Broadsoft, CoreMedia, Comverse, Convergin, End2End/Mach, Ericsson/Drutt, Genband, HP, IBM, IMImobile, jNETx, Metaswitch, Microsoft, Motorola/Leapstone, Motricity, mPortal, NSN, NEC, NetCentrex, Nortel, OpenCloud, OpenWave, Oracle/BEA, Pactolous, Personeta, Qualcomm/Elata, Red Hat/Mobicents, Redknee, Telcordia, Telenity, Sun, Sybase/Mobile365, Ubiquity/Avaya, Verisign/mQube, Volantis.  The SDP Landscape is definitely complex, confusing and consolidating as I write.

But coming back to why an operator should consider a SDP.  The drivers for the SDP are clear: to extend the life of traditional services; lower costs associated with the development and introduction of new services; extend services across networks and devices; provide an operating environment and development tools for third-party software developers; and improve the profitability of niche services.  However, the challenges to implementation are equally as clear: managing end-to-end application performance; modular, standards-based service delivery platforms are still relatively immature; integration; service provider organizational challenges; lack of a compelling business case; lack of standards creates confusion and trepidation; and marketing challenges.

As part of the SDP (Service Delivery Platform) workshop a run I go into depth on this topic and review a number of case studies.  In general my recommendations for operators are:

• The part of SDP that deals with operations (BOSS) has a clear business case and operators are adopting the same tools as enterprises based on SOA;
• The part of the SDP focused on content services is maturing and becoming a managed service;
• The part of SDP focused upon communication services is still in an experimental stage, with some initial success focused upon enterprise services;
• The part of the SDP focused upon third parties, the Telco API is a current hot topic within the industry with a few examples of initial success such as Sprint's Business Mobility Framework.

How the parts get integrated into an all-encompassing SDP is a question I'll leave for another weblog entry.

Overall Summary / Opinion

An important first step in meeting the competitive disadvantage VZW faces compared to the GSM operators.  A device centric ODIS (Open Device Interface Specification) defines what a device must do to interface to the VZ RAN (between the device radio hardware and the access network), and the support structure to help partners (device manufacturers, MVNOs, M2M service providers or other service providers) through the process.  Commercial models range from retail through to wholesale.  The retail model is a little perplexing; difficult to see what beyond niche business focused applications could work.  Why would Nintendo build a VZW specific DS given the small addressable market?  However, for enterprise M2M with its higher margins there could be a case for a limited run of devices.  Wholesale is an important step beyond what VZW does today in potentially removing or softening the application test requirements.  However, in between the retail and wholesale models, the "custom" model, there could be a rich seam of commercial models and opportunities for monetize assets such as billing, customer support and distribution.   

The issues of exposing capabilities such as location, presence, messaging, content, FiOS, etc. were not covered in this conference.  They are in the plan, John Stratton is leading that across all Verizon, I saw him walking about at lunch.  This will become part of the open development process.

Summary of Sessions

Opening by Tony Lewis, VP Open Development.  An extrovert, unusual for VZ :)

Opening Remarks, Ivan Seidenberg CEO.  VZW messaging of the most reliable network.  LTE trial end of this year focused on speed and global compatibility - finally I'll be able to roam with Verizon.

Open Development Overview, Tony Lewis, VP Open Development.  Focus of the initiative is on new, non-traditional M2M devices.  All the device must do is meet VZW's minimum technical standard (see later) and the customer will have online support (billing, device ping).  The plan is to have a network only service option available in the second half of this year, likely by the end of the year.  Breaking out of the brew model, any application on the device, spec will only cover interface to the RAN, middleware, OS and applications are up to the Partner.  No equipment contracts or early termination fees.  Supported by a partnership management office that is focused upon helping partners they their devices through the process and working on the commercial arrangements.

Commercial Models, Mike Lanman CMO.  Three models, retail, wholesale and custom. 

• Retail model is where the partner (device supplier) makes money on the device and Verizon bills for the service the customer selects.  Device provider is responsible for marketing and distribution.  Customer service and billing will be all online.  Voice and data package options are likely to be similar to existing retail packages, though 'unlimited' 5GB package not likely, more likely a top package of 2GB with overage charges.  Will include have nationwide plans, data bundles, data only packages, and pay as you go.  Pricing is still in development and is likely to done initially on a case-by-case basis until VZW finds its feet.  Can leverage VZW's roaming relationships.
• Opinion: In essence a customer buys a device that is tied to VZW, selects a VZW package, and received a service less than buying direct from VZW.  Retail model is likely to be used for niche applications, where device manufacturer is prepared to build for a VZW only market, likely enterprise M2M, I can not see Nintendo building a VZW specific version of its DS for a potential market of 2 million.  Also customers will need education as they're paying VZW for a service but not getting the VZW experience.
• Wholesale is more interesting as the requirements on application testing that exist today are lessened, maybe even removed.  Also enables innovative pricing models of bundling data connectivity into the fixed upfront price for the device, or annual fees, or advertising supported, or absorbed into some other customer charge.

 
Activation and Self Service, Ajay Waghray, CIO.  Partner provides ESNs (Electronic Serial Number) of certified devices to VZW.  As VZW has certified the device they know the capabilities and how to activate, from simply turning the device on for the first time to possibly keyboard actions by the user.

Device Specification and Certification, Tony Melone, CTO & team (Ro Garavaglia + David McCarley). 

Spec covering CDMA2000, EVDO and in time LTE.  Voice only, data only, voice and data specifications.

ODIS (Open Device Interface Specification) Voice spec covers 3GPP2 emergency services, CDG90, 3GPP2 MEID, VZW OTA, and some VZW specific requirements.  Data spec covers 3GPP2 MEID, CDG 148, CDG 143, RFC 2486, VZW OTA and some specific VZW requirements.  Specs will be updated on a 6 monthly cycle, Q1 and Q3.

Network platforms (location, messaging, voicemail, content, etc.) - to be defined.  VZW will expose location outside the brew model, but no schedule or interface spec exists today - though we'll likely see something before the end of the year.

3 phase certification process (will have both VZW cert centre - not a profit centre) and 3rd part certification.

• Pre-submission - paperwork, NDAs, etc.
• Certification - 4 weeks (target) covering RF parameter testing (1 week), signaling conformance and features (2 weeks), ODI certification (1 week).  All radio interfaces will be turned on.  Certification will be good for 36 months.
• Post-certification - vendor interop (CDG57), field testing (CDG64)

 
Opinion: Likely takes a 9-18 month process down to 3 months.

Also in attendance Lowel and John Stratton who I saw walking around at lunch.  So full executive support at this event.  VZW consider this initiative core to their future success, equal to their focus on building their network and building their brand.


Findings over lunch conversations.  The ODI will be integrated with a similar initiative from the fixed side (FiOS) and across their application developer program.  Billing models are not yet defined, very much open to discussion with partners.  There is an opportunity for a device vendor to create an open platform (device and OS) and let other providers put their services on top deliver their branded phones, e.g. Skype Phone, Global Crossing Phone, BT Phone, etc.  Where depending upon the deal they cut with VZW they could target segments, such as international roamers.