An SDP addresses the need for operators to increase revenue from convergent services while simultaneously reducing the cost and risk of creating such services. But what are the components of an SDP? Will an operator need one overall SDP or a series of connected SDPs operating within a service delivery framework?
For the past 18 months to two years, operators have faced a competitive threat from Internet players, such as Skype and Google, offering "over the top" services. At first this just meant VoIP, often very cheaply or even free, but now the threat extends into all areas of mobile services – from messaging, through to content and sharing services. In this environment, the big fear is that the operators are reduced to the famous "dumb pipes", selling commodity voice and access and competing on price alone. To counter this threat, operators have been told for a while that they need to evolve their business model towards what has come to be known as the "Telco 2.0" model.
Under the Telco 2.0 model, the thinking went, operators could leverage their network capabilities, such as mobility, messaging, location, presence, profile and call control, and combine these with internet-style services such as social networking, search, advertising, direct marketing and mapping, thereby enabling richer, more compelling and more personalised services than the Internet players can offer.
Furthermore, by exposing these capabilities in a secure, controlled and automated manner, operators could generate revenues from selling service enablers, as well as their own services, allowing them to fully exploit their network assets. The exposure of Telco network capabilities allows service "mash-ups" to be created by a broad community of application developers from the Internet world. These service mash-ups are often specialised, targeted services that appeal to the "long tail" of customers and will collectively generate more revenue at higher margins than the traditional narrow set of mass-market services. At the very least operators are now in control of "intelligent" pipes, rather than dumb ones, and at best would be right at the heart of new mobile service revenue creation.
To face up to this challenge, network equipment vendors, the established telecoms vendors, pushed the IMS. The IP Multimedia Subsystem was the vendor's way of moving the network to IP, introducing new elements to the network that enabled the creation of services across domains that previously operated in isolation. It would also help operators create services once, and be able to deliver them across multiple access networks to a single user ID, whether that user was on his mobile, a wirelessly connected laptop or a DSL connection to his home PC.
This was the thinking that drove the evolution of telecoms networks from voice-centric "legacy" technologies such as SS7 and IN towards data and multimedia-centric technologies based on IP, such SIP and IMS. Furthermore, networks were to evolve from a closed, vertically integrated, network element-oriented architecture towards a more open, horizontally layered, service-oriented architecture. The upper layer of this architecture, the Service Layer, is independent of the underlying network platforms, and enables converged services across fixed, mobile and next-generation networks.
And this is where the SDP started to become to be seen almost as a replacement to the IMS, even though in many regards they are part of the same journey. Inspired mainly by vendors from the IT space, the concept of the full SDP was to handle each service component as a piece of functionality whose information can be shared with other components to make new services. So for instance a piece of location information from the network would be exposed to a third party developer of location based systems through the SDP. Through its integration with the OSS/BSS functions of the network, that service would then be automatically exposed to the provisioning, fulfillment and billing processes. As a result, SDPs enable operators to create converged services that blend the best of telecom, web and IT resources. Examples are music, video and business services that personalize content delivery using: network resources that show a customer's active presence on the network or his or her physical location; web resources for access to vast stores of information, multimedia content and social communities; and IT resources such as billing, network management, and other business and operations support systems (BSS and OSS). The great advantages are speed, and efficiency, as a single, service aware platform, could create, manage and control a multitude of services, and third party partners.
As such, an SDP incorporates software technologies for governance, management and quality that help service providers take full advantage of the platform's service-oriented architecture (SOA). This approach creates a unified resource layer through which multiple services communicate with underlying wireless or wired networks, third-party applications and innovative combinations of web services.
"SDPs are germane to a service provider's ability to compete in the future," Brian Partridge, program manager at technology research and consulting firm Yankee Group, says. "New converged services can become very complex, and if you're going to create and maintain them by the hundreds, you'd better have an SOA-based SDP framework that allows you to weave together all the disparate threads from web, telecom and IT."
Telenity's cto Gurol Akman adds a fourth interface, that to business process management and business, and that is critical. Because for many operators, the move to one, all encompassing SDP, without the addition of revenue generating services now, is not viable. These operators are not faced with the same challenges as the Tier 1 operators, to whom the benefits of an SDP in terms of network convergence and consolidation can be huge.
But they are faced with the necessity of making money from innovative services quickly. For many, that is their whole brand identity – that of the "happening" service provider that is providing something a little bit different from the established players. To help them meet their needs, then, came the application specific SDP, in which sets of service components are tied in with the abstraction layer and network components. This posed a new threat, that the application specific SDP would not interface with other application specific SDPs, and would in time create something similar to the old network-element based service silos.
Even for the major players, of course, the introduction of services is the primary goal,
"To offer new convergent services quickly and cost-effectively, we must simplify our infrastructure," said Gianni Canal, manager, Services Layer and Messaging Innovation Lab, Telecom Italia, confirms.
The answer to this problem lies in one of two ways, or a combination of both – but essentially what we are talking about is providing a web services exposure layer over the pre-integrated SDP – either through partnerships with web services players, or by building in this exposure to the SDP. The first part is open standards and open source programmable components, and interfaces such as ParlayX to northbound third parties, JAIN SLEE and proprietary SLEEs for protocol support and conversion from southbound assets, and the exploitation of technology from the likes of BEA, Microsoft, Sun and Oracle in the service execution environment. In an ideal world, across legacy IN service components and newer Web2.0 created services, this would lead to reusable service components – in other words, the ability to use a service component not just within its own "home" domain (a messaging server, say) but to take its service information and re-use within another domain. If this work can be allied to work within the OSS/BSS community (principally at the TMF) to open up interfaces in a similarly standard way, then the concept of individual services, and combinations of service logic, being managed, provisioned and billed for comes closer. Services syndication requires efficient coordination among participants within the value-chain. Such coordination is supported by TMF's service delivery framework work, TR139 and the PSA specification.
The TMF says that the objectives of its SDF program are to define the business and technical requirements for a Service Delivery Framework, to achieve the following Business objectives:
Reduce cost and cycle time to translate business services ideas to market offerings (e.g. effective product lifecycle management throughout the entire ecosystem including operation support);
Increase opportunities and innovations for monetizing existing assets (e.g. repurposing content and applications); Adapt swiftly to market changes and customer preferences.
To achieve these aims, three major products will are being produced by the SDF programme. The first is an SDF Reference Model (now presented in TR139 Version 1.0) – which has been used to get industry agreement on the landscape of the SDF and against which detailed Requirements for SDF Management will be produced. The second is an SDF Business Agreement [Management Requirements] (TMF 519) – which captures detailed Requirements for the management of the SDF. It is expected that many of these Requirements will be met by detailed change-control requests being made upon existing TM Forum framework items (such as eTOM, SID, TAM etc). But in addition the Requirements will also identify the need for new Management specifications to be produced (eg Management of Content / Media services). This element of the programme is forming much of the work of Phase Two of the TMF's SDF team. The programme will also produce an Industry Group Positioning Document (TR 141) – which will show how the work being carried out by various other Industry Groups working in co-operation with TM Forum supports the SDF development activity. The layout for this positioning will be the SDF reference Model.
The benefits of the pre-integrated approach, then, is that operators can get to services much faster, and can approach the task of moving to an SOA based SDP in a per-domain way, without having to invest the large sums up front that would otherwise be necessary to effect a full network transformation project. The danger that individual SDPs may not interwork with other pre-integrated SDPs (not all pre-integrated SDPs will have all the necessary protocol support) can, some now think, be overcome either by using the open standards in the execution environment, or they will have to deploy a service brokering capability between platforms.
For the software providers too, the emphasis has switched from pure license sales, to shares of revenues from new and quickly deployed services components. Microsoft Communications' Michael O' Hara says that his revenue growth is now principally in services revenue growth, rather than core sales of its Connected Services Framework product. Partly, this is because Microsoft has had limited success with its CSF sales, but O' Hara claims that the growth of services revenues share was always the goal.
"We want customers to use our applications and services, how they then control those services within their overall architecture really is less of a concern to me," O' Hara says.
Whichever approach operators choose, there is little doubt that the priority remains the introduction of new services in a controlled and timely fashion. But the development from service silos integrated only with their own service control management systems on a per service basis, to the acceptance of componentised services, exposed through web services technology to third party services to create new value for consumers, has been remarkably quick, and continues to provide rich territory for a whole host of innovative companies.