At the end of November I'll be attending Informa's SDP Asia conference in Singapore.  I'll be running a post-conference workshop on the 28th November, and a couple of sessions through the conference (26-27 November).  Outlines of the sessions are shown below, and the conference brochure can be downloaded here.  The purpose of this article is to briefly review what I hope to achieve in those sessions.  

For the workshop on the 28th Nov entitled "The Business Case for Service Innovation (New Revenues): The SDP, Telco API and Web/Telco 2.0" the focus is a frank review of what is happening with SDP (Service Delivery Platform), what's working and what is not, the business case for its deployment, and the results over the past year from my work with developers to understand their needs (this is a critical issue for the industry).  I'll be reviewing the activities of Telenor's Content Provider Access, O2 Litmus, Telus, Cox, Sprint's Business Mobility Framework, Orange Partner, Telecom Italia's NexTIM, BT, Telstra, Maxis, Bharat Sanchar Nigam, Swisscom, and many more.  Examining their successes and failures, particularly around services, business model, processes and architecture. As an independent worker in the telecom industry I can focus upon the facts, not 'spin' for shareholders, or to make a sale, or maintain the company line; simply "I can say it as it is."

For the session on the 26th Nov entitled "How To Combine IMS and SDP To Effectively Deploy New Products & Services" the focus is to cut through the misinformation and negativity that surrounds IMS (IP Multimedia Subsystem), so its core purpose is understood, why SDP functionality is required, and the business justification for its deployment.  My recent article on IMS/SDP North America provides a summary of some of the findings I'll be presenting.

On the 27th November I'll be chairing the day, and running the final panel session "Stimulating Service Innovation Through The Application Developer Community."  In that session I'm fortunate to have on the panel Thomas Clayton, Varun Arora, and Kenny Mathers.  As I mentioned earlier, fulfilling application developer needs is critical to an operator's success.  Tom, Varun and Kenny bring a vast wealth of experience on this topic, and I strongly encourage operators to attend this session.

Over the day of the 27th Nov, we'll have operator presentations from Alex Lim (BT), Vincenzo Amorino (Telecom Italia) and Achmad Darmawan (PT Starone Mitra Telekomunikasi), covering their SDP experiences.  Other presentations are going to bring world-class thought leadership, practical implementation advice and lots of case studies.  My objective for the day is to ensure attendees get as much frank advice as possible to aid in current or planned SDP deployments.

SDP Asia provides a great opportunity to meet with operators creating service innovations throughout the APAC region.  I always find it a refreshing and stimulating conference given the market's diversity with quite unique challenges compared to Europe and the Americas.  Last year's SDP Asia conference is reviewed in this article.  Contact me if you're interested in attending and I'll forward the Speaker Colleague & Client Discount registration form so you can save 25%.


The Business Case for Service Innovation (New Revenues): The SDP, Telco API and Web/Telco 2.0 (28th November)
The SDP (Service Delivery Platform) is now a core strategic asset within an operator's network.  Not only is the SDP saving millions of dollars by rationalizing the delivery of multiple services and winning profitable new revenues through simplifying how new services are enabled and launched.  The SDP has become core to an operator's service innovation strategy; that is how it will win new revenues, attract new customers and retain existing customers.

The Telco API (Application Program Interface) is one method for operators to foster innovation on their networks.  The Telco API (Application Programming Interface) enables operators to expose capabilities from their networks such as location, presence, charging, authentication, etc.  Based upon extensive studies performed with operators around the world, the Telco API has the potential to raise ARPU by up to 36%.  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 each operator's local market.  All this is enabled through the SDP.

The workshop's objectives are to enable the attendees to understand:

• The SDP landscape;  
• Where and why SDP deployments are working, examining the reality behind the hype;
• The variety of SDP business cases;
• The failures in other operator's ADCs (Application Developer Community), and what are the keys to success based upon extensive application developer discussions;
• What application developers need from a Telco API;
• How the SDP enables an operator's Web / Voice / Telco 2.0 strategy; and
• What an operator needs to do given their specific local market conditions.

How To Combine IMS and SDP To Effectively Deploy New Products & Services (26th November)
IMS (IP Multimedia Subsystem) has had a tough time in the press since it passed over the 'peak of inflated expectations' and entered the 'through of disillusionment' on the classic hype curve. However, IMS is being deployed, with Verizon, Sprint and AT&T aggressively rolling-out and the cable operators following close behind.

• What are their rationales for deploying IMS?
• How are such operators integrating IMS with their existing service platforms and SDP plans?
• What are the services?
• What is the business case?

Stimulating Service Innovation Through The Application Developer Community (27th November)
Operators around the world are adopting the Web 2.0 paradigm to harness internet service innovations onto their networks, e.g. Verizon's Open Developer Initiative, BT's 21C SDK, O2 Litmus, and Vodafone's Betavine, commonly referred to as Telco 2.0. The SDP is the underlying technology enabler to these initiatives. This session will discuss with some leading '2.0' developers what they need from an operator's application developer community to enable mutual success.

• 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 application developers in working together?
• What are good and bad application developer communities?

Panelists
Thomas Clayton, President & CEO of Bubble Motion
Varun Arora, CEO of Pechora
Kenny Mathers, Head of Nokia Forum

The purpose of this article is to provide a summary of my findings from Informa's IMS/SDP (IP Multimedia Subsystem) North America conference that ran from the 5-7 November in Dallas TX; I gave a preview of the event in this article.  I've also put a few slides together to give a flavor of the conference at the end of this entry.  Overall the conference has the key players in IMS/SDP for North America in attendance; has the latest insights and initiatives being presented; provides a very frank and honest status check on the industry; and I think we're starting to see some practical customer focused steps forward such as the Rich Communication Suite initiative described by Feza Buyukdura of AT&T.

Mark Kaish of Cox Communications presented on "The Business Case for IMS in the Cable World: What is Their Vision?"
He provided an update on Cox's IMS experiences from an IMS / Packet Cable 2.0 trial, in which 8 applications where tested.  The most significant challenge as they move from trial to initial deployment is BOSS (Business and Operational Support Systems) integration.
The business case has proven difficult.  In the end they took a 'cost neutral' approach.  A critical yardstick is the total cost per subscriber (including integration and BOSS) for IMS.  If this figure can be shown to be close to the revenue generated they can push through action based upon the potential of IMS.  Mark indicated a ballpark cost figure of about $4 per subscriber, which requires a 'light-weight IMS.'
Other interesting observations, which have also been reported other operators, were:

• "IMS Compliant" means nothing, each vendor is an island;
• Integration remains a challenge between network elements, BOSS and with clients;
• Internally developed applications took the longest, a simple SDK (Software Development Kit) for developers is essential to stimulate service innovation;
• Mark echoed Andre Moskal's (Telus) comments on the need to 'believe' in IMS as the business case is just not there; and
• The importance of Tru2way in opening up the STB to open innovation.

Feza Buyukdura of AT&T presented on the "Rich Communication Suite"
RCS is a broad-based industry initiative that soups-up the address book with presence to drive advanced communication services such as video calling, video share, IM (Instant messaging), file share, etc.  Think of it like taking a best of breed IM client onto the address book, and enabling it to work across operators.  This breaks through the networking effect which currently limits mobile video-telephony as discussed in the "Internet's Gone Video" article, is a critical step in the industry.  RCS is a bridge between now and OMA Converged IP Messaging (CPM) that utilizes the existing IMS standards and guidelines (no new standards) and focuses on inter-carrier interoperability (the critical piece).  The service uses capabilities provided by IMS, and is sort-of being positioned as a driver for IMS, but the actual implementation within an operator does not mandated a 'full' IMS implementation.  I recommend people keep an eye on this as it has potential - as long as it focuses upon the service and not trying to push IMS - to dramatically change the everyday communications experience.

David Moro of Telefonica presented on WIMS 2.0: Mixing Web 2.0 and IMS to get the Best of Two Different Worlds
WIMS 2.0 (Web 2.0 and IMS) is an initiative promoted by Telefónica seeking convergence between Web 2.0 and the telecom new generation services based on IMS (IP Multimedia Subsystem), to create innovative, appealing and user-centric services and applications. The WIMS website contains much more information.   Where as RCS is focused on an operator provided application that can run on IMS; WIMS focused upon opening up IMS capabilities to the web.  I think it provides an important technical experiment to demonstrate service innovation to help break the dam to open innovation.  However, I think the main problem facing the industry is around the operational and commercial changes required within an operator to step out of the way and let application developers and customers create value.

Lucia Gradinariu of the TMForum presented Service Delivery Frameworks and their Role in the Rapid Assembly and Commercialization of New Services
Providing an overview of the SDF, an integrative layer across the SDPs an operator has in their network, e.g. IPTV, IN, Messaging, content.  Enabling mashed-up or combinatorial services to be managed, e.g. provisioned, fault reporting, etc.

I also gave a brief presentation as an introduction to one of the panel sessions reviewing the fundamental change operators must react to, that is customers now expect to be engaged in a dialog with their service providers, and for services to improve in weeks not 6-12 months.  Simply customers' experiences with web-based service providers has reached a point where operators must react.  The success of Apple's App Store, with 200 million applications downloaded in just over 100 days since launch shows customers want applications.  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. I then reviewed a number of operator initiatives in fostering open innovation and set out an action plan.  The punch line is: "It's NOT the Technology: It's your PLAN!"

Other comments / insights:

• On Ribbit, one panellist commented, "BT has bought themselves $105m of cool."  But with non-standard APIs; the limitation of Flex; and a relatively small UK market (fixed centric operator): its unclear if there's enough of a market to stimulate developers to join the BT party once the hype dies down and people look to how they can make money.
• Several operators admitted to having IMS installed in their networks with no services running on top, or if they did have services running on IMS they've been closed down.
• Is IMS too old?  Given IMS was created when Web 2.0 was not mainstream, mobile broadband was not ubiquitous, HSPA+ was not about to deliver 20+ Mbit/s to customers, and inter-operator issues were secondary to the "walled-garden."  Does the architecture need to be reconsidered?  Is such fine grain policy control required?  Is openness and web 2.0 compatibility now essential (c.f. the WIMS 2.0 initiative)?
• General consensus on the lacking of an IMS business case.  Which, as I discussed in several articles in the weblog means the focus must change from the technology to the commercial plan; implement only what is necessary for open innovation plan, rather than the backwards thinking of "How do I build a business case for IMS?"

On the 30th October I gave a webinar entitled "Telco adoption of Web 2.0 principles and open innovation for rapid application development." The presentation is shown below:

The webinar was also recorded, and is available here.

The purpose of article is to act as a follow-on discussion forum, so please add comments, questions you were unable to ask in the webinar, or points you think should be raised.

In the presentation I identified a number of critical issues.

• Operators must:
• Implement processes to ensure ADC (Application Development Community) is used by the operator and not repeat the mistakes of the past; and
• Reverse developer skepticism by listening, implementing what they need, and show the ADC working.
• Application developers will not pay for capabilities exposed, e.g. location;
• Customer access is critical;
• REST and in some cases SOAP/XML are the preferred APIs;
• Full testbed is essential to the ADC; and
• Copy Apple's App Store, just copy better.

What's missing in the above list from an application developer's perspective?
Can operators meet these requirements?
What are the critical remaining gaps in enabling operators and application developers to work together?

In a previous article, "The Internet's gone Video: What does that mean to operators?" I gave a preview of the presentation I planned to give at the Dialogic One Event in the keynote session "Carrier Video Services Trends and Opportunities" on the 21st October in San Diego. The presentation, shown below, is split into four main sections covering:

• The history of carrier video services;
• The impact of the internet going video on the industry;
• How operators are responding with open innovation to address the gap between their performance and that of the internet with respect to video; and
• Some real-world developer case studies.

On the 30th October I'll be giving a free Telestrategies webinar entitled "Telco adoption of Web 2.0 principles and open innovation for rapid application development." The pitch for the webinar is:

"The battle is intensifying between telcos, consumer device manufacturers (e.g. iPhone and Sony PS3) and web-based services (e.g. Google) in the delivery of services to customers.  The Apple iPhone App Store has demonstrated the power of harnessing open innovation / web 2.0 ideas to increase customer value.
 
The majority of service innovations today are coming from the web and not the telcos.  However, telcos 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, main-street store presence, and a strong position in the industry's ecosystem. Necessity being the mother of invention, telcos are now adopting open innovation / web 2.0 ideas (e.g. Verizon's ODI, O2 Litmus, etc.)

Join us as we discuss how web-based services have changed customers' expectations and how telcos are now responding to those changes with open innovation.  The speaker will present the results of an extensive application developer survey on what telcos must do to harness open innovation.  Finally, an action plan is set forth on what must happen to enable application developers and telcos to create a win-win partnership to deliver increased customer value."

My objective is simply to share some of my learning over the past year in working with telcos and application developers on the topic of open innovation and open networks.  Some relevant weblog articles are "Open Innovation and Application Developer Needs," and "Application Developer Needs Part 2."  The webinar also provides an opportunity for real-time questioning, so I hope it will stimulate an insightful discussion.

To sign up for the free webinar you can click here or cut and paste this link into your browser, https://telestrategies.webex.com/telestrategies/onstage/g.php?t=a&d=753805235.  I hope you can make time on the 30th October to join the webinar.
 

As mentioned in the previous article "Open Innovation and Application Developer Needs," in helping operators understand ways they can harness open innovation 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.

I maintain a list of about 1000 web/voice/telco 2.0 application developers, described in the article "Web / Voice / Telco 2.0 Application Developer List."  This list enables targeting of different application categories, business models, enabler needs and geographic base.  In reviewing the results of the past two years I've interviewed over 210 developers, gathering feedback through phone and face-to-face interviews, as well as a range of quite detailed questions.  Again, I apologize to the people who spent hours completing the questionnaires, I promise it's for the greater good :)

In examining some of the issues developers have in common with current operator initiatives:

• No live test environment for end-to-end testing of applications;
• No developer sandbox;
• No/limited device independent platform;
• No/limited embrace of browser based services - this is a critical gap in the industry;
• Very limited access to key capabilities for providing interesting applications and services;
• A web of stakeholders within the operator which slows/halts the decision-making and/or approval process;
• Typically no single point of contact;
• Inadequate operational support;
• Little or no support for billing system integration;
• Lack of support for remote monitoring;
• Lack of flexibility / willingness to try new business models; and
• Rigid rules & guidelines for contributing an application.

The list goes on, I'm just picking a sample.  However, some of the problems can be solved quite easilly:

• Provide a live testing environment / access to test lab;
• Single point of contact for technical issues;
• Consistent operational support, e.g. network connectivity;
• Clear path of decision-making up the chain of command;
• Real project with full organizational commitment from operators - not a 'fashion accessory;'
• VPN access to on-site systems for remote monitoring;
• Delegate testing and approval to third party testing houses; and
• 'Approved developer' certification for the ability to fast-track approvals, operational requests, etc.

However, the surveys only capture a part of what an operator must do.  Above all an operator must:

• Implement processes to ensure the ADC (Application Development Community) is used by the operator and not repeat the mistakes of the past;
• Reverse developer skepticism by listening, implementing what they need, and show the ADC working; e.g. application developers will not pay for capabilities exposed - do not charge them;
• Customer access is critical, it's taken for granted on the web;
• REST and SOAP/XML is the preferred API (don't talk about ParlayX); and
  
• Copy Apple's App Store - they've got the recipe more or less right, copying is OK, we're not at school; just 'copy better.'

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.

Earlier this month I gave a weblog preview of Informa's SDP (Service Delivery Platform) Asia conference in Singapore.  I'll also be attending Informa's IMS/SDP (IP Multimedia Subsystem) North America conference (5-7 November) in Dallas TX.  This weblog article provides a preview of the North American event.  Bringing the discussion on IMS and SDP together is an important step in recognizing that the services layer in the emerging telecommunications network must be integrated and not viewed as separate architecture silos by virtue of whatever standard body created that component.  As Sprint, Cox and Verizon are some of the most active operators in the world with respect to IMS and SDP, North America provides right venue for this integrated services layer discussion.

On Day 2 (6th Nov) I'll be chairing an interactive circuit entitled "SDP and IMS: What Type of Services Are Most Likely to Benefit Each Technology? Are SDP/IMS Alternative or Complimentary?"    In this session we have a great mix of operators and application developers, see session description below.  One of the panelists, Sean O'Sullivan, has aided me on several occasions in helping operators understand application developers' needs.  In the introduction to the session I'll review some of the critical trends, such as the 'internet going video,' operators' inability to match this trend in their own video services, and the impact open access has on the 'operator : application developer' relationship.  We'll then focus upon 'Where's the Money?'  Using real-world service examples to answer the questions covered in the session description, as well as building a rich list of go-to-market services.

On Day 3 (7th Nov) I'll be chairing the day and running the panel sessions; "How is the SDP Bridging Today's Platforms with IMS Applications?" and "Resolving the 'Catch 22 Situation' of IMS Network Rollout and Device Availability: Which Needs to Come First to Enable IMS to Prosper? How Can We Address the Handset Bottleneck?"  To kick off the day we'll have two operator presentations from Shoeb Ahmed of Banglalink, Bangladesh; and Jon Sung of SK Telecom, describing their experiences in using IMS/SDP to drive new service revenues.  

The panel discussion on "How is the SDP Bridging Today's Platforms with IMS Applications?" See session description below, will focus on the real-world implementation experiences of both operators and suppliers is evolving from what's in the network today.  This is a critical point; most operators are not Greenfield, legacy platforms and services can not be ignored.  In some cases the legacy OSS platforms provide an easy OPEX (operational expenditure) reduction business case.  However, for legacy service platforms its much more complex.  This session aims to understand how best to manage the service layer evolution based on real-world operational experience.

The wrap-up panel session on "Resolving the 'Catch 22 Situation' of IMS Network Rollout and Device Availability: Which Needs to Come First to Enable IMS to Prosper? How Can We Address the Handset Bottleneck?" has handset representatives from Samsung and Motorola.  Even though this is the last session, its by far the most critical for IMS deployment success.  When 3G was launched operators sat there frustrated on underused assets as 3G handset availability severely limited customers access to the new network.  How are handset vendors avoiding a repeat of this situation for Sprint and Verizon given their IMS plans?

Overall, this conference provides an important forum for anyone focused upon the North American market with respect to IMS and SDP as it's a 'who's who' in this space, with Verizon, AT&T, Sprint, Alltel, Cox, T-Mobile, Orange, Telus, Telefonica, Banglalink, SK Telecom and BT all in attendance.


INTERACTIVE CIRCUIT: A 60 minute discussion on the role of IMS and SDP to enable innovation in service creation and delivery. Contributors will also look at innovative ways to build a product strategy and at how IMS and SDP can help.  All delegates and speakers are encouraged to speak up.
Introduction: Alan Quayle, Founder, Alan Quayle Business & Service Development, USA
SDP and IMS: What Type of Services Are Most Likely to Benefit Each Technology? Are SDP/IMS Alternative or Complimentary?

• What types of services are more likely to benefit from SDP and what services are more likely to benefit from IMS?
• What can carriers do with IMS/SDP that they cannot do without?
• What type of implementations have we seen in the US?
• Should IMS and SDP simply co-exist or should they be integrated?
• What Technology Strategy Should Be Built Around our Product Strategy?
• How can we use the whole IMS architecture to develop a whole portfolio of services?
• Do carriers use IMS to its full capabilities?
• Some North American carriers are outsourcing services that are outside their domain. Shall we let innovation happen outside?

Panelists
Chris Joul, Principal Engineer, T-Mobile, USA
Simon Persoff, Director Regulatory Affairs, Orange Home, UK
Vikram Karmarkar, VP of Techhnology Strategy and Alliances, Ecrio, USA
Sean O'Sullivan, CTO, Dial2Do, Ireland
Sebastian Kramer, CEO, Quative-Kudelski Group, Germany
Lucia Gradinariu, Senior Advisor, Industry Programs, CA and TeleManagement Forum, USA

PANEL DISCUSSION How is the SDP Bridging Today's Platforms with IMS Applications?

• Is the Integration with the SDP the way to prevent IMS from becoming another technology silo?
• How can we extend the service platform for the development of cutting edge services?
• Can we achieve cost reduction through improved performance in IMS and service delivery infrastructure?
• Can operators fully leverage the value of the IMS architecture without using the SDP?

Moderator: Alan Quayle, Founder, Alan Quayle Business & Service Development, USA
Panelists
Jon Sung, Principal Architect, SK TelecomAmericas, USA
Andre Moskal, Wireless Networks Technology Strategy, TELUS, Canada
Vikram Karmarkar, VP of Techhnology Strategy and Alliances, Ecrio, USA
Steve Lasko, General Manager Americas, jNetX, USA
Sean O'Sullivan, CTO, Dial2Do, Ireland

PANEL DISCUSSION Resolving the 'Catch 22 Situation' of IMS Network Rollout and Device Availability: Which Needs to Come First to Enable IMS to Prosper? How Can We Address the Handset Bottleneck?

• What are the carries' requirements of an IMS enabled handset? Must have features and technical imperatives
• How can we integrate the IMS features into the handset?
• Why the delay? What needs to happen to expedite handset development and client availability?
• Addressing the need to have a critical mass of devices enabling choice for the consumer
• IMS /SDP and the open handset: Where do the examples of best practice come from?

Moderator: Alan Quayle, Founder, Alan Quayle Business & Service Development, USA
Panelists
Sam Ramdenbourg, Director of Product Planning and Technology Strategy, Samsung, USA
Kevin McDunn, Director, Strategy & Business Development, Motorola, USA

The Key Revolution (TKR) has brought together the innovations of cloud computing and 'chip and pin' security technology to create a unique answer to the problem of secure remote working and collaboration with Mobiu. The service backs up data to a secure encrypted online MobiVault; enables collaboration and file sharing in MobiRooms; and uses a SIM (chip used in mobile phones) equipped USB drive for secure two factor authentication and to provide portable applications, e.g. secure anonymous web browsing.  Mobiu is based on technology created and patented by Vodafone, with a platform hosted by NTT and powered by Sun Microsystems.

Mobiu uses the secure 'chip and pin' (Personal Identification Number) technology, which banks use to reduce online banking fraud in the UK by 67 percent during the first half of 2007.  Single factor authentication of 'username and password' has been proven time and again as inadequate; its not how many bits are devoted to encryption, it's the human link in the security chain that is weakest. 

A study by digital communications agency @www, reveals that 61% of web users use the same password for all their online accounts.  According to RSA, the need for end-users to memorize passwords results in less secure management, with 25% of respondents storing a password spreadsheet or document on the PC, 22% said they record passwords on a PDA or other handheld device and 15% keeping a paper password record in an office/workspace.  People need easy to remember passwords and those passwords often prove easy to guess or are easily found, hence the need for another factor in the authentication process.

Chip and PIN provides two-factor authentication, that is a simple easy to remember PIN and a Chip module (SIM equipped USB), only when you physically have the Chip and you enter the correct PIN can access be granted, which enables Mobiu to provide secure access to your data.  Secure and encrypted online storage and back-up with MobiVault provides virtually unlimited storage, and can only be read by the Mobiu owner of that data and those Mobiu customers authorized by the owner of that data.  Should the Mobiu be lost, data is easily recovered from the MobiVault and the Mobiu can be immediately deactivated.

The Secure Remote Working Landscape breaks down into three broad technology segments shown in this diagram.

• Browser based.  Secure remote access services that use the web browser on any PC, generally taking advantage of the SSL VPN (Secure Socket Layer Virtual Private Network) capability provided by the browser.  The main weaknesses are it requires the browser have the latest secure updates, no malware (malicious software) present, and it generally only uses single factor authentication.
• Client based.  Secure remote access applications installed on the laptop.  The main weaknesses are it requires the user to carry around a laptop, but more importantly the data is stored on the laptop, so when the laptop is stolen the company's data is at risk, and it generally relies upon single factor authentication.
• Secure USB drive based.  These are USBs with software and/or hardware modifications to enable them to securely store data, however, most rely upon single factor authentication, rather than the more secure 'chip and PIN' technology, and do not offer the supported remote working and collaboration service package provided by Mobiu.

In the US there have been approximately 217 million records stolen in the past three years through laptop theft, 2005-2008, according to Paul Stevens, Director of Policy and Advocacy with Privacy Rights Clearinghouse (a private advocacy group).  At a typical cost of $182 per record, that's nearly $40B over three years!  FBI & CSI's annual Computer Crime and Security Survey of 2006 stated that 47% of computer security professionals surveyed reported a laptop theft over the past twelve months.

It's not a matter of if; it's a matter of when one of your company's laptop will be stolen.  So Mobiu gives companies the option to either avoid carrying laptops yet still work remotely, or if they do carry laptops store company data with a secure two factor authentication USB.

In the telecom industry Managed Network Services (MNS, aka Outsourced Network Operations) is likely to be a $10B business in '08, with a CAGR (Compound Annual Growth Rate) of between 13-17%.  Europe accounts for 45% of the market.  The leading supplier in the market, Ericsson, rips-out other supplier's equipment and installs its own in the networks it manages (e.g. H3G Sweden).  So for any supplier in the telecoms industry, if you can not deliver your product as a managed service, you may not be delivering it for much longer.  The MNS market breaks down roughly as follows: Ericsson - 32%, ALU - 30%, NSN - 15%, Motorola - 8%, the rest (Nortel, Huawei, ZTE) - 15%.

An Operator's drivers for MNS are:

• Direct operational cost savings. Cost savings of up to 20% are possible thanks to the scale of the managed service provider (MSP) in aggregating resources over multiple customers.  Simply, introducing an MSP provides an opportunity to break down the fiefdoms that lead to underused resources within the operator.  The 'Gridlock Economy' by Michael Heller is worth a read on the topic of underused resources.
• Better use of capital and resources. More predictable and balanced operational and capital expenditure, and the substitution of fixed by variable costs to improve cash flow.
  
• Faster time to market. The ability to focus resources on strategic rather than operational issues; and access to resources and technical competencies in the MSP can improve the operator's ability to deploy new technologies and bring new services to market.
• Business transformation. By focusing management on the core activities of services innovation, marketing and customer service; outsourcing network operations can enable operators to be more market focused and customer oriented.

MNS breaks down into network outsourcing and service outsourcing.  Network outsourcing is buy far the larger business, roughly $8B, compared to service hosting at roughly $2B.  Network outsourcing tasks include network planning, vendor management, network operations, network maintenance, network optimization, network build and deployment, site acquisition and management.  Service hosting tasks include product/service definition, service delivery platform development, service delivery platform operation, content acquisition and management, application and content development, application operation.

Examples of Outsourced Network Operations include:

• 3 UK: MSP Ericsson, $3B over 7 year contract, >1000 people, network deployment and operations.  Done to enable H3G to achieve profitability and focus on breaking the 5 million customer barrier.
• Bharti Airtel: Ericsson, Nokia Siemens Networks (NSN), $2.5B, >600 people, managed capacity/services for deployment and operations.  Manage rapid grow on a $ per Erlang model.  Removes expense and delays of RFP/Q process
• Brazil Telecom: NSN, $100m over 3 years, operations and maintenance of fixed and mobile core.  Done to enable supplier to manage NGN migration.

In this previous weblog article I reviewed a typical mobile operator's financials, and how that impacts its priorities.  OPEX (Operational Expenditure) dominates its costs, at roughly 80%, and people costs costs are roughly one third of the technical operations cost - MNS addresses this cost.  People issues dominate the MSP process and economics, re-assignment to the MSP enables many 'fiefdoms' to be removed releasing value; however, the conversion process is expensive, with typically a 20% loss in productivity during the process.  In addition, the relationship between the operator and the MSP is complex and at times fraught, it's essential to have a simple set of measurable targets between the Operator and MSP.

For any supplier in the telecom industry it will soon be a matter of survival to determine how they deliver their product as a managed service or find a way to fit into one of the MSPs' solutions. 

At the end of November I'll be attending Informa's SDP Asia conference in Singapore.  I'll be running a post-conference workshop on the 28th November, and a couple of sessions through the conference (26-27 November).  Outlines of the sessions are shown below, and the conference brochure can be downloaded here.  The purpose of this article is to briefly review what I hope to achieve in those sessions.  

For the workshop on the 28th Nov entitled "The Business Case for Service Innovation (New Revenues): The SDP, Telco API and Web/Telco 2.0" the focus is a frank review of what is happening with SDP (Service Delivery Platform), what's working and what is not, the business case for its deployment, and the results over the past year from my work with developers to understand their needs (this is a critical issue for the industry).  As an independent worker in the telecom industry I can focus upon the facts, not 'spin' for shareholders, or to make a sale, or maintain the company line; simply "I can say it as it is."

For the session on the 26th Nov entitled "How To Combine IMS and SDP To Effectively Deploy New Products & Services" the focus is to cut through the misinformation and negativity that surrounds IMS (IP Multimedia Subsystem), so its core purpose is understood, why SDP functionality is required, and the business justification for its deployment.

On the 27th November I'll be chairing the day, and running the final panel session "Stimulating Service Innovation Through The Application Developer Community."  In that session I'm fortunate to have on the panel Thomas Clayton, Varun Arora, and Kenny Mathers.  As I mentioned earlier, fulfilling application developer needs is critical to an operator's success.  Tom, Varun and Kenny bring a vast wealth of experience on this topic, and I strongly encourage operators to attend this session.

Over the day of the 27th Nov, we'll have operator presentations from Alex Lim (BT), Vincenzo Amorino (Telecom Italia) and Achmad Darmawan (PT Starone Mitra Telekomunikasi), covering their SDP experiences.  Other presentations are going to bring world-class thought leadership, practical implementation advice and lots of case studies.  My objective for the day is to ensure attendees get as much frank advice as possible to aid in current or planned SDP deployments.

SDP Asia provides a great opportunity to meet with operators creating service innovations throughout the APAC region.  I always find it a refreshing and stimulating conference given the market's diversity with quite unique challenges compared to Europe and the Americas.  Last year's SDP Asia conference is reviewed in this article.  Contact me if you're interested in attending and I'll forward the Speaker Colleague & Client Discount registration form so you can save 15%.


The Business Case for Service Innovation (New Revenues): The SDP, Telco API and Web/Telco 2.0 (28th November)
The SDP (Service Delivery Platform) is now a core strategic asset within an operator's network.  Not only is the SDP saving millions of dollars by rationalizing the delivery of multiple services and winning profitable new revenues through simplifying how new services are enabled and launched.  The SDP has become core to an operator's service innovation strategy; that is how it will win new revenues, attract new customers and retain existing customers.

The Telco API (Application Program Interface) is one method for operators to foster innovation on their networks.  The Telco API (Application Programming Interface) enables operators to expose capabilities from their networks such as location, presence, charging, authentication, etc.  Based upon extensive studies performed with operators around the world, the Telco API has the potential to raise ARPU by up to 36%.  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 each operator's local market.  All this is enabled through the SDP.

The workshop's objectives are to enable the attendees to understand:

• The SDP landscape;  
• Where and why SDP deployments are working, examining the reality behind the hype;
• The variety of SDP business cases;
• The failures in other operator's ADCs (Application Developer Community), and what are the keys to success based upon extensive application developer discussions;
• What application developers need from a Telco API;
• How the SDP enables an operator's Web / Voice / Telco 2.0 strategy; and
• What an operator needs to do given their specific local market conditions.

How To Combine IMS and SDP To Effectively Deploy New Products & Services (26th November)
IMS (IP Multimedia Subsystem) has had a tough time in the press since it passed over the 'peak of inflated expectations' and entered the 'through of disillusionment' on the classic hype curve. However, IMS is being deployed, with Verizon, Sprint and AT&T aggressively rolling-out and the cable operators following close behind.

• What are their rationales for deploying IMS?
• How are such operators integrating IMS with their existing service platforms and SDP plans?
• What are the services?
• What is the business case?

Stimulating Service Innovation Through The Application Developer Community (27th November)
Operators around the world are adopting the Web 2.0 paradigm to harness internet service innovations onto their networks, e.g. Verizon's Open Developer Initiative, BT's 21C SDK, O2 Litmus, and Vodafone's Betavine, commonly referred to as Telco 2.0. The SDP is the underlying technology enabler to these initiatives. This session will discuss with some leading '2.0' developers what they need from an operator's application developer community to enable mutual success.

• 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 application developers in working together?
• What are good and bad application developer communities?

Panelists
Thomas Clayton, President & CEO of Bubble Motion
Varun Arora, CEO of Pechora
Kenny Mathers, Head of Nokia Forum

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.

Following in the series of market landscapes such as On Device Portal, Fixed Mobile Convergence, Service Management, and a very high level one on Service Delivery Platform (SDP).  I'm presenting a richer SDP landscape, however, it is challenging to compare SDPs because of the vast scope of functionality and the numerous definitions that exist.  

A definition I generally use is: a service delivery platform (SDP) is an IT-based environment enabling service creation that does not rely on a specific network element enabler. This need comes from two major trends: the need to cut costs in the service creation process; 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.  These definitions work well with architects, but for rest of us in the industry, it's still a little too abstract.

In the old SDP landscape I divided the suppliers according to their backgrounds, Network Equipment Providers, System Integrators or IT Vendors.  This is useful in understanding where a supplier is coming from in their SDP proposition, but it does not help in understanding what's out their and who's suppling what.  So to that end, I have a new SDP landscape.  This breaks down the landscape across the main suppliers and what types of delivery platform they supply.  There are many more than in this list, my objective here is to show a representative sample.  Now the delivery platforms break down into two main segments content delivery (CDP) and service delivery (SDP), think of CDP as a subset of SDP.

The types of CDP are:

• Managed Mobile Content: a CDP run and possibly hosted by the supplier on behalf operator which suppliers ring tones, wall papers, music, videos, games etc. to customers' mobile phones.
  
• Mobile Content: a CDP that is supplied to the operator who installs and runs the platform which suppliers ring tones, wall papers, music, videos, games etc. to customers' mobile phones.
  
• IPTV: a CDP for the STB (Set Top Box) over a broadband network.

The types of SDP are:

• Messaging: SDP focused upon premium messaging services.
• SIP application server: SDP focused on voice applications
• Business: SDP focused on business services and integrating into business processes.
• Real-Time charging: SDP component that enables real-time charging for services.
• 3rd Party Communications and Messaging: The OSA OSE, Parlay, JAIN SLEE, platforms.
  
• Service Creation /Management: SDP component focused on the operation processes for creating and managing services
• Unified SDP: An SDP created specifically to unify all the previous categories including CDP into a consistent framework.  Critical features include being standards based, unified policy management, and extensive pre-integration.

Hopefully this SDP landscape sets out why you see so many suppliers claiming to have SDPs, they're generally focused on specific service silos or capabilities.  And that in fact there are very few SDP suppliers out there which really do unify service delivery across an operator's portfolio.

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.

The GSMA reported in August there are now 4 million new HSPA (High Speed Packet Access) subscribers a month.  The total number of HSPA users has passed the 50 million mark globally from 11 million a year ago.  Mobile Broadband is definitely taking off, as discussed in this previous weblog article. 

When I was in the UK in July, I was chatting with a UK Operator's sales person as I installed a pay-as-you-go mobile broadband card in my laptop in their store.  I was asking about the types of customers using the service, how long they'd been sold-out of the ZTE modems, and what returns they see.  An interesting comment was the only returns are when the 3G service does not work at the customer's home, it shows there's a strong fixed to mobile substitution taking place for broadband.

But will mobile broadband provide the same experience as DSL broadband?  Taking a typical 3G roll-out architecture of 3 E1s from a cellsite, which given the recent upgrades in HSDPA to 14.4 Mbit/s means the capacity problem isn't over the air, its on the backhaul, as I've discussed in this previous weblog article.  Given the ATM cell tax, and other framing overheads, the maximum capacity available for the customers' broadband data is about 4.6 Mbit/s.  

Now looking at the figure from a simple MB (megabyte) per month perspective, that gives 1.5 TB (terabytes) available over the month.  Given an urban macro-cell covers between 1200 to 2000 connected customers, assuming 1500 customers means an average 1GB limit.  Which at first glance would appear to provide adequate capacity even if 100% of the customer base were using mobile broadband. 

However, the term I used in the title was customer experience.  The key experience is the many customers watching YouTube or BBC iplayer.  The video you see in the BBC iplayer today is encoded using the On2 VP6 codec at a bitrate of 500Kbps, though they've recently announced encoding using H.264 at 800 kbit/s.  YouTube is a little more sedate 300 kbit/s.

So this means that one cell-site can only support 9 simultaneous On2 VP6 BBC iplayer streams, or 5 simultaneous H.264 streams, or 15 streams of the more sedate YouTube streams.  And that's ignoring all the other browsing traffic (which increasingly includes annoying streaming video adverts rather than easy to ignore banner adverts) and P2P (peer to peer) traffic.  Remember when Tiscali launched in the UK and struggled through inadequate backhaul, even today Tiscali still struggles with customer service.

A critical issue is what are the chances of within a cell-site 10 customers (0.66% penetration) watching a streaming video at the same time during that critical 6PM-11PM period?  Unfortunately the statistics coming from the DSL ISPs (Internet Service Providers) appear to show that chance as significant today.
  
Some ISPs use GE (Gigabit Ethernet) from their DSLAMs into their metro/core networks today.  Compare this to the 3E1s in the example above, which is 0.45% of the capacity of a GE.  To maintain the same experience mobile operators are going to require lots of capacity deep in their network fast, and become more sophisticated than the DSL ISPs in managing the traffic over their 'longer access networks.'  Especially in managing the highly visible streaming video traffic which customers will likely use as a yard-stick to compare ISPs performance in the near future.

Femtocell can be thought of as the "son of FMC," rather than using a Bluetooth or WiFi air interface and a specialized phone; it re-uses the GSM or CDMA air interface and potentially your existing mobile phone.  But given FMC's (Fixed Mobile Convergence) poor market acceptance; why should femtocell be any different?  Reviewing femtocell against the FMC service models discussed in this previous weblog article on FMC, it can be thought of as a hybrid of the dual mode and substitution models.  In that, a short-range wireless system is used in the office/home, however, that interface is the same as the wide area network (GSM/CDMA).  It enables all communications to be managed by one converged operator and hence does not require the enterprise to maintain existing PBX equipment.

Examining some of the FMC failures we've seen in the market.  Both Deutsche Telekom (DT) and Korea Telecom withdrew their FMC services, blaming poor service take-up.  A critical issue was the price paid for the service was not significantly lower than the savings incurred by the customer.  This was then compounded by the usability issues around calls being made at home or in the office and not being charged at the cheaper FMC rates; as well as the teething battery life issues.  There was a period in 2006 when it appeared every DT employee was looking for a power socket to recharge their T-One phone.

When T-One was launched a T-One customer paid about €70 per month to get the full range of services, after having paid connection charges of €185. The absolute minimum spent, forgoing the DSL connection, came to about €55. But even this was expensive compared to E-Plus' flat rate charge of €25 per month with unlimited calls to national fixed and E-Plus numbers (calls to other operators cost 25 cents) - and hence Fixed Mobile Conversion won out!

BT Fusion Plus's old pricing was 12.50GBP per month plus call charges, so for calls to a UK landline, standard pricing was 80p for one hour, with BT Fusion Plus that dropped to 10p for one hour.  Definitely cheaper, but to recoup the 12.50 per month fixed fee, required about 18 hours of calls (over 1000 minutes).  It didn't take customers long to work out that wasn't entirely a good deal.  Today BT bundles the Fusion cost into the minutes plans.

However, a notable exception to these failures is Orange Unik.  France Telecom benefited from a large retail base of broadband customers, and was able to exploit the success of its home gateway, Livebox, which supported Unik (avoiding multiple boxes).  When launched the Unik service offered unlimited, flat-rate calling to all national PSTN numbers for €10 per month, or unlimited calling to all national PSTN numbers and Orange mobile numbers for €22 per month.  Which is a significant value given the penetration of Orange customers for fixed, mobile and broadband is significant in France.  It was also a fraction of the cost of Deutsche Telekom's T-One service.  This enabled Unik to achieve a penetration of 500k customers in Feb '08, see this weblog article from SofNet.  Though this remains a small percentage of FT's total 25.3M customer base; and even in this success-case, the business case is slight as it relies heavily upon the inclusion of savings in retention and acquisition costs.

The critical lessons are: keep the service as transparent as possible with respect to user experience; keep the saving as simple to understand and as significant as possible for the customer.  

So now let's examine some of the hurdles femtocell is climbing:

• Interference between with macrocell and with neighbouring femtocells (especially in flats/condos/apartments) in real-world deployments.
• Quality and range. If a femtocell operates at the same frequency as the macrocell, the range could be as low as 10-20m.  If on clear spectrum, the range can be as great as 150m.  But many operators are not in a position to offer clear spectrum.
• Network management.  A similar problem to DSL modems or VoIP terminal adapters, which has recently been addressed by the adoption of the TR-069 family of specifications.
• Handover.  Macro-to-femto handover is tough (Sprint's AIRAVE femtocell trial does not do such handover).  Femto-to-macro handover is easy, perhaps too easy; if there is a charging difference the FMC billing problems previously described may recur.
• Tolerance to broadband backhaul limitations.  Latency, synchronization, and limited uplink, especially in rural locations where customers may be inclined to adopt femto to improve their in-home mobile performance.  It likely requires the femtocell provider to also provide broadband to ensure end-to-end quality of service.
• Billing.  Critical issue for previous FMC services, as it resulted in many complaints and high churn
• Security.  Opportunities for fraud increase as the operator extends their mobile network into the public domain.
• Network integration and evolution.  Operators will likely use the Iub interface, other approaches are also possible but costs/performance/evolution complicates the decision (e.g. just voice support, or voice and data).

So femtocell will need to be integrated into the broadband modem provided by the converged operator, and its cost will likely need to be borne by the operator not the customer, else the customer will choose a cheaper service.  The proposition needs to be very simple, e.g. unlimited calling at home for all your phones and 80% off international calls for only 10 GBP per month.  The user experience must also be simple; when the customer is at home they just call like anywhere else, the calls are just cheaper; no checking for signal levels or listening for multiple tones when dialing.

Femtocell enables mobile broadband traffic to be off-loaded in the home and office, this is an important benefit for the operator not the customer.  Operational and commercial issues need to be resolved, as described above.  But once solved, and its operation is transparent to the customer, we will likely see femtocell bundled in all converged operator broadband modems.  The main challenge facing femocell technology is the timing of when the operational and commercial issues can be solved to meet the conditions necessary for market success not technology trial success.

This article follows on from a previous article that reviewed LTE (Long Term Evolution, also know as 4G).  Several people asked why I had not included a fuller discussion on the 4G core in that article.  It is because LTE is an access technology; my focus of the article was on the access where there is a lot of hype at the moment.  However, to support LTE a new core is required, as specified by the SAE (System Architecture Evolution). 

In the standards community the names have now become E-UTRAN (Enhanced UMTS Terrestrial Radio Access Network) for LTE, and EPS (Evolved Packet System) for SAE.  Think of the SAE as a pure IP core without RNCs (Radio Network Controller) or SGSNs (Serving GPRS Support Node).  So in principle an operator would need to run two core networks to support the existing 3G network and the new 4G network.  Given the slight benefits of LTE compared to HSPA+, as discussed in a previous article, this would appear to be a significant barrier for LTE adoption.

However, the NEPs (Network Equipment Providers) are providing a range of solutions that enable the existing 3G core to evolve towards the SAE vision such as:

• One Tunnel, moving the SGSN into the control plane;
• Direct Tunnel, moving the SGSN and RNC into the control plane; and
  
• Internet HSPA: control-plane SGSN and RNC is integrated into the NodeB.

The 3GPP core market is roughly $1B in size, and the top three suppliers in this market are: Ericsson (34%), NSN (33%), Huawei (15%).  Who unsurprisingly are the three players behind the three different solutions that evolve the core towards the SAE vision.  Given we're likely to see the number of mobile broadband customers worldwide explode to over 1B over the next 4 years, mobile core costs could potential to explode as well.  Hence the immediate focus on moving the RNC and SGSN out of the data path and into the control plane, to better manage broadband growth.

Specifically the motivations for this early transition are:

• Lower cost/bit - depending on the architecture it has the potential to reduce equipment costs by 80%;
• Preparation for 4G - in other words avoid a dual core situation which would delay operators buying LTE BSRs (Base Station Routers).  Note the base stations are where NEPs make their money, so they're keen to remove any barriers; and
• Ease of integration of non-3GPP access (i.e. network convergence, avoiding multiple cores and service platforms).

Hopefully this sets out why we'll likely see the '4G core' happen before the '4G access.'

LTE (Long Term Evolution, also known as 4G) is entering the hype-cycle, and being rapidly pushed up to the 'peak of inflated expectations', just like IMS (IP Multimedia Subsystem), PTT (Push To Talk), FMC (Fixed Mobile Convergence), and far too many other technologies to name here.  So to cut through the hype and hopefully present a pragmatic view on the technology I thought it timely to make a few points, as I find I'm often repeating myself on this topic (I hope its not old age.)

A few pointers on what the technology can do:

• LTE will not greatly improve spectral efficiency compared with HSPA+ (High Speed Packet Access).  Within a 5MHz slot you could achieve perhaps 80 Mbit/s with HSPA+ (using MIMO (Multiple In Multiple Out) technology), compared to 100 Mbit/s with LTE. A 20% increase is unlikely to have customers demanding LTE.  The only tangible difference will be a slightly lower round-trip delay for LTE perhaps down to 10-20ms compared to perhaps 30-35ms with HSPA+, though with a flat IP core (moving RNC (Radio Network Controller) and SGSN (Serving GPRS Support Node) out of the data path) that could drop to about 20ms for HSPA+.
• LTE enables a higher peak data rates by using more bandwidth, scaling from 1.25 MHz (useful for the CDMA operators, hence Verizon's decision to adopt LTE) to 20 MHz and beyond.  LTE uses OFDM (Orthogonal Frequency Division Multiplexing), the same technology used in DSL (Digital Subscriber Loop), that is lots of little carriers,