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'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.
 

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.

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

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

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.

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.

I would like to thank Jeroen Visser from BT for his suggestion of this article to explain SOA, SDP and IMS; and then explain how they fit together.

Service Oriented Architecture Defined

SOA (Service Oriented Architecture) has emerged as a successful integration framework for BOSS (Business and Operational Support Systems) within operators.  We are now witnesses that success driving SOA into the services layer of operators.  But what is SOA?

SOA is just an evolution of distributed computing and modular programming.  It's an IT (Information Technology) architecture (note, it does not specify the technology for its implementation) enabling the creation and execution of business processes, packaged as services, throughout their lifecycle.  The promise of SOA is that the marginal cost of creating the nth application is near zero, as all of the software required exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application.  From a telco perspective it's a flexible architecture that enables service innovation, mass customization and leverages an IT standard, avoiding yet another expensive 'telco-special.'

SOA defines the IT infrastructure to allow different applications to exchange data to form business processes, e.g. a "new employee set-up process" that could require services from multiple IT platforms, ordering of equipment (e.g. phone, mobile and PC), etc. SOA separates these functions into distinct units "services," which can be distributed over a network and can be combined and reused to create new business applications, e.g. "temporary employee set-up process." These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Services are unassociated units of functionality, which have no calls to each other embedded in them.  This causes some confusion from a telco perspective as services are what customers pay for, so the term SOA services is often used to differentiate from end-customer services. SOA services typically implement functions such as filling out an online application for an account, viewing an online bank statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement.

Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics of these services, but also the data that drives them. Generally web services are used to implement the SOA.  A web service refers to clients and servers that communicate using XML messages that follow the SOAP standard. In such systems, there is often machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL), and Universal Description, Discovery and Integration (UDDI) is used to discover those services.  In SOA's implementation XML has been used extensively to create data which is wrapped in a description container. The services themselves are typically described by WSDL, and communications protocols by SOAP, with UDDI being used to discover those services.

However, SOA is not tied to a specific technology.  It can be implemented using a wide range of technologies, including SOAP, REST, RPC, DCOM, CORBA, Web Services or WCF. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having fore-knowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.  

Of course nothing stays the same.  Advanced SOA or SOA 2.0 is the "the next-generation version of SOA" combining service-oriented architecture and Event Driven Architecture (EDA).  An event is simple a change of state, e.g. new employee contract signed, which then triggers an business process.  Building applications and systems around an event-driven architecture allows these applications and systems to be constructed in a manner that facilitates responsiveness, because event-driven systems are, by design, able to cope with unpredictable and asynchronous environments.  EDA is complementary to SOA as its just adding the triggers to start processes and enable processes to adapt to changing circumstance, i.e. exist in the real world.

And finally on the practical application of these concepts, some of the issues are:

• Complexity - SOA is very flexible, perhaps too flexible, SOA service definitions do result in capabilities being misinterpreted.
• Security - security at the service level is not appropriate; it must be managed at the network level.
• Interoperability - as it's an architecture the implementation allows lots of opportunities for many incompatibilities between vendor implementations.  So when a vendor claims SOA compliance, the response is 'So what!'  SOA compliance does not guarantee interoperability of services between operators, or even interoperability between SOA-based functions within an operator.
• Processing power - its important to implement what is necessary, do not build a 'Grand Architecture,' build lean.
• Hype - the standards are still evolving, and will continue to do so.  Hence build lean as next year or within 18 months the implementation will need to evolve to remain competitive.

Service Delivery Platform Defined

What is a 'service delivery platform'?  It really depends upon with whom you are talking.  Are they a vendor trying to sell IMS (IP Multimedia Subsystem); or a Java games download platform; or an operator responsible for value-added communication services, IPTV, or content service?  Each will likely give quite different answers.  Service delivery platforms 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 (International Telecommunications Union) 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, that good old chestnut of 'remove the service silos to save money.'  The benefits of taking a horizontal (layered) approach versus a vertical (stove-pipe) are: faster and cheaper time to market, and enabling service innovation independent of switch vendor.  Most operators 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 or prepay billing.  The IN SDP has not achieved the ubiquity of deployment as a re-usable layer within the telecommunication software stack; rather it is a component of a vertical application.  The barrier remains 'incrementalism', that is, it is cheaper to deploy service X as a vertical than incur the additional costs of deploying an SDP.

As networks have evolved from circuit-centric to packet-centric, the SDP has extended its reach beyond communication services, to include content services, streaming services, and even broadcast services.  So the SDP is now positioning across all services and access, an "all-encompassing service delivery architecture".  But the challenge of 'incrementalism' remains.  In addition, there is no one standards body leading the creation of reference SDP architectures or implementation norms.  Currently, we're seeing initiatives for vendor-specific frameworks, or common application-network interfaces within an operator group.

There are a number of standards bodies working in the SDP space including Parlay, Open Mobile Alliance (OMA) Service Environment (OSE) and the TMF's SDF TeleManagement Forum's (TMF) Service Delivery Framework (SDF).  There are many other service layer initiatives including Product and Service Assembly Initiative (PSA) which are not covered in this article.  OSA Parlay is part of the 3GPP IMS, and exposes enablers such as presence and call control to applications.  The OSE is as architecture that provides a common structure and rule set for specifying enablers, e.g. presence, location, etc.  The TMF SDF definition provides the terminology and concepts needed to reference the various components involved, such as applications and enablers, network and service exposure, and orchestration. The TMF uses these in the definition of the processes and entities needed for managing the SDF components.

A service delivery platform (SDP) is an IT-based environment, enabling service creation in an environment 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, 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: service creation environment, service orchestration environment, service execution environment and third-party management.

I abstract this a little further and think of the SDP as having 3 main systems:

• Content Delivery Management: System that ingests, presents and delivers content to customers on their mobiles, STBs (Set Top Boxes), PCs or other devices.
• BOSS integration: Processes associated with service creation, delivery and life-cycling.
• Telco API: Exposing capabilities from the network to operator services, partner/co-branded applications and 3rd party applications.

I find the above definition helps in understanding where a supplier is coming from in their definition of and SDP.  Stepping back from the definitions and functions, as discussed in the article "An Industry At The Crossroads," the SDP will be the innovation engine in operators.  It will have multiple elements for multiple suppliers, what is critical is not the architecture (as this article shows, we have more than enough of those).  Rather we must focus on the business requirements of service innovation to drive a lean implementation that's going to evolve far faster than any previous operator platform.

IP Multimedia Subsystem Defined

I've talked about the IP Multimedia Subsystem (IMS) in several other articles such as SofNet Day 3, The Divergence of CDMA and UMTS Operators on IMS, SCIM: Its time for operators to sort out the services layer mess, Critical Gap in IMS/SDP business cases.  Simply IMS is an architecture for delivering internet protocol (IP) multimedia sessions (e.g. voice and video) across multiple access networks.  This is done by having a horizontal control layer that isolates the access network from the service layer. Services need not have their own control functions, as the control layer is a common horizontal layer.  Hence why I focus on the IP session control capabilities within IMS and the relevance to operators such as Verizon and Sprint in supporting voice over their EVDO network.

So How Do SOA, SDP and IMS Fit Together?

After that lengthy definition section, summing up how these acronyms fit together:  

• IMS is service control for IP multimedia sessions; it sits between the network (transport) and the SDP, think of it being within the control layer of the network.  An operator does not require IMS, but they need IP session control whether it be SIP/soft-switch based or IMS based.  
• SDP is service management across content-based and session-based services; think of it as the services layer of the network.  Most operators have SDP components in their network already, they're just not integrated into a coherent services layer.  
• SOA is an architecture the SDP can be based upon that leverages IT volumes.  But as discussed in the definition of SOA, being 'SOA compliant' is a bit like saying 'based on modular software programming techniques.'
  

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.

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.

The Application Network Interface (ANI) is an interface through which operators can expose capabilities from their networks to third parties such as single sign-on, location and presence.  At SDP Asia I gave a presentation on "Examining the importance of the SDP to an Operator's Web / Voice / Telco 2.0 strategy" where I covered a list of about 25 broad categories of capabilities.  I gave a summary of the conference on my blog, http://www.alanquayle.com/blog/2007/11/findings-from-sdp-asia-2007.html.

Operators are interested in the ANI because it allows third parties to innovate on their networks, enabling them to compete with the service innovation from companies such as Google, and create new revenue streams.  The capabilities are much broader than the usually commented upon items such as location, single sign-on, presence, call control and billing.

Just a few examples:

• An operator could expose an API (Application Programming Interface) that allows their content portal (mobile and/or IPTV) to be accessed by third party applications.  A third party application developer could then create a Facebook application that allows people to send or receive gifts of ring-tones, movies or wallpaper; much more useful than paying a $1 for a picture of a duck to appear on someone's profile. 
  
• A local system integrator (SI) provides enterprise mobilization services, e.g. field force automation.  An operator could expose a device management capability so that the local SI can manage the handsets for its customers.
  
• Many incumbent national operators have an impressive national fulfilment capability, in that an order received from the phone, internet or partner can result in a complex series of synchronized actions such as: configure networks, partner networks and services; synchronize the arrival of the product and a technician to install that equipment.  In fact, in today's triple play environment I've been impressed at the installers' ability to set-up and configure HDTV, DVDs and surround sound systems when installing triple play.  I'm sure this would be of interest to many internet retailers.

Estimates on the ANI's incremental revenue range from 10-55% of an operator's existing revenue.  The ANI could have a significant impact not only upon the operators' revenue in the years to come, but also on some of its future business models.

In reading the reviews of the telecom year, I see both iPhone and Android pop up as two of the most significant changes on the telecom industry.  I think it's important that we stop and think a moment.

• On the iPhone: I already have music on my phone, I can do email, I have a slick address book interface, I have a browser, and thanks to Spinvox I've had voice to text for several years, and there have been touch sensitive screens on the market for years.  So what's new or innovative about this phone?  Apart from the Apple logo and the marketing dollars spent making operators' customers around the world a little more aware of mobile data services, little is new or innovative.  Is the iPhone significant for most c