Search The Moriana Group Website
Moriana on SDP 2.0
Service Delivery Platforms – definition and evolution
By Kris Kimbler - View Profile
The term Service Delivery Platform (SDP) refers to a system architecture or environment that enables the efficient creation, deployment, execution, orchestration and management of one or more classes of services. As such, the SDP is the key component of the telecom Service Layer.
The Service Delivery Platform has emerged as a consequence of telecom network evolution. In today’s converging telecom world, substituting numerous network-specific ‘stove-pipes’ with a common, horizontal, service architecture seems right and natural. This allows for efficient service delivery across multiple types of networks, as well as for the creation of Web and IT applications that make use of operators’ network capabilities.
Initially, (circa 2000), the term Service Delivery Platform was coined to describe a common service architecture specifically designed to deliver mobile content and messaging services. Later, (from 2003 to 2006) the SDP evolved to support voice, multimedia, location, presence and charging services. This second generation SDP fully embraced standard IT technologies and offered a secure and managed 3rd party access to network services through emerging Telecom Web Services standards.
Today’s the third generation Service Delivery Platform, often referred to as Service Delivery Platform 2.0, is built around the Service Oriented Architecture (SOA) which enables efficient service integration, orchestration and lifecycle management. In addition, SDP 2.0 facilitates service migration from legacy networks to all-IP networks and the standard IMS architecture.
Figure 1: SDP 2.0 in the evolving telecom infrastructure
Key SDP characteristics – what makes a ‘real’ SDP
To date, there is no fully agreed consensus on what service platform characteristics constitute an SDP. Some vendors use the term SDP for their service and content delivery solutions, but these are effectively ‘stove pipes’ rather then ‘real’ SDPs. Other SDP offerings include a whole portfolio of products and components, such as charging and rating engines, SOA middleware, CRM systems or identity management servers that overlap with the OSS/BSS functionality.
In Moriana’s view an SDP should possess five key characteristics:
• Standard technology – A ‘real’ SDP solution should be based on open IT and telecom standards for: middleware, protocols, APIs, service enablers, service execution models, service creation tools (SDKs), as well as data repositories (databases). It should also use COTS hardware components running standard operating systems.
• Horizontal architecture – An SDP should have a horizontal architecture possibly spanning different networks (wireless, wireline, broadband, IMS, etc.). The SDP architecture consists of clearly defined functional layers for service execution, integration and exposure. It should also provide secure access to network capabilities through a set of abstracted service enablers rather than through native protocols.
• SOA-based integration – An SDP should follow the principles of Service Oriented Architecture (SOA) for internal and external (OSS/BSS) system integration as well as service management and orchestration. This requirement applies mainly to comprehensive SDP solutions. Today however, an operator is unlikely to deploy an SDP or any other service platform, if it is not SOA compliant.
• Common environment – Services running on an SDP share the same environment. This consists of common elements, such as standardized service enablers, a service execution environment, a service and user profile repository, service orchestration and management mechanisms, as well as common OSS/BSS interfaces for charging and provisioning.
• Open service creation – An SDP solution must be open, and enable the creation of new services and applications that use standard application development tools (e.g. Eclipse or MS Visual Studio) as well as a common set of service components and APIs. The services can run directly on the SDP service execution environment or remotely using exposed open APIs and Web Services.
These key SDP characteristics allow us to differentiate between and a ‘real’ SDP and a ‘stovepipe’ solution. In other words, a service platform that uses vendor-specific software and hardware components; has network-specific, ‘vertical’ architecture; applies proprietary protocols and interfaces; requires special tools for service creation; or requires service and user data to be stored in an embedded database, falls into the ‘stove pipe’ category and should not be called an SDP.
SDP 2.0 – Third Generation SDP Architecture
The third generation Service Delivery Platform has evolved naturally from the second generation SDP. It has a layered architecture and the key elements and functions are still there. The SOA-based Service Orchestration and Management Layer is the main innovation. In Moriana’s view, SDP 2.0 architecture consists of the following layers:
• Service Exposure Layer
• Service Orchestration and Management Layer
• Telecom Services and Service Enablers Layer
• Service Creation and Execution Layer
• Telecom Network Abstraction Layer
However, it should be noted that in Moriana’s model of SDP 2.0 architecture, shown in Figure 2, content delivery is no longer differentiated as a separate component. This is a change from Moriana’s previous SDP 1.0 reference model, where a clear difference between ‘soft’ content delivery and ‘core’ voice service delivery was made. Since then, the SDP concept has been applied in many other service areas, such as IPTV or mobile commerce, where each class of services requires specific SDP components and functions. Therefore, separating content delivery as a distinct SDP component is no longer justified.
Figure 2: SDP 2.0 – Third Generation SDP Architecture Moriana Model
SDP Standards and Technologies
There is no standardized SDP architecture, and probably will never be! However, the model of second-generation SDP architecture proposed in the Moriana SDP 1.0 Operator Guide (2004) has been widely adopted across the industry, and is easily recognizable in many SDP architectures designed by operators, vendors, and system integrators.
Several industry organizations and standard bodies, such as OMA, TMF, 3GPP, IETF, the Parlay Group, JCP, SIP Forum, and others have contributed to the evolution of SDP. None of them, however, was aimed at standardizing the whole SDP architecture, but rather they focused on specific elements, such as service enablers, protocols, execution models, policy management, etc.
SDP standardization space is fragmented; no one industry organization has resided over SDPs to specify a reference model or architecture that can be easily translated into systems and technology dependant implementations.
SDP development has always been driven by a commitment to standard IT technologies such as Java, Java EE (J2EE), .NET and Web Services. A key objective has been to enable an average application developer with limited telecom knowledge to create innovative services, using standard development tools and service enablers.
The critical need to successfully integrate SDP into OSS/BSS and the growing importance of 3rd parties, has driven the adoption of SOA and related concepts such as Enterprise Service Bus (ESP) and Web Service Orchestration based on the BPEL (Business Process Execution Language) standard. Wrapping SDP around SOA seems to be the optimum solution today.
The most important standards that have had an impact on the SDP space include: SIP (Session Initiation Protocol), SIP Servlets, and IP Multimedia Subsystem (IMS), OSA/Parlay APIs, JAIN SLEE (Service Logic Execution Environment), Parlay X, OMA PEEM (Policy Evaluation, Enforcement and Management), and OMA Telecom Web Services.
Out of all these standards, only SIP is likely to gain global recognition and be adopted by a critical mass of vendors and network operators. Parlay X (now embraced by OMA) is also becoming a de-facto standard for Telecom Web Services for 3rd party access to service capabilities.
Service Delivery Framework – the next step in SDP evolution
The growing number and complexity of services deployed on SDPs, as well as new specialized SDPs has lead to the concept of the Service Delivery Framework (SDF). The SDF should enable operators to implement homogenous, cost efficient service life-cycle management for different classes of services. This should be achieved by drawing on common industry enablers such as standardized OSS/BSS integration using Service Oriented Architecture (SOA) and COTS IT technologies such as Web Services. Note that elements of the SDF are already included in the third generation of SDP architectures.
An SDF Reference Model is currently being defined by the TeleManagement Forum (www.tmforum.org). The key objective is to define a generic management framework regardless of the network or technologies used by services. The SDF Reference Model assumes quite realistically, that a service managed by an SDF does not need necessarily to reside on an SDP. It can come, for instance, from an IPTV platform or even a legacy IN platform. The only requirement is that the service is SOA compliant and exposes management capabilities defined by the SDF Reference Model.
The Role of Convergent SDP 2.0 in Migration to IMS
IMS - IP Multimedia Subsystem
The IMS or IP Multimedia Subsystem is 3GPP standard service architecture for all-IP networks. The hype around IMS in 2005 had a negative impact on the adoption of SDP across the industry. Many decision makers bought into the hype and started to believe that a quick IMS deployment would solve existing service delivery problems better than any SDP solution could. However, this did not happen in the way that was predicted.
While most operators agree that the in the long-term, migration to all-IP is imperative, many of them question the value of the IMS for their business, at least in the short-term perspective. The IMS is being adopted in a cautionary, step-by-step process that will take many years to complete.
SDP 2.0 vs. IMS – competing or complementary architectures
The IMS was initially projected as a competing concept to SDP. A closer look however shows that the concepts are complementary rather than competing. This opinion is shared by the majority of respondents to the Moriana SDP market survey.
From the SDP perspective, IMS simply provides a set of service enablers that can be utilized to create a range of next generation multimedia and voice applications. The SDP complements the IMS with a set of other key service enablers, such as mobile location, SMS, MMS, etc. that are not yet in the scope of IMS. The SDP also provides service management and orchestration functions, 3rd party service exposure, and SOA-based integration capabilities that are not in the scope of the IMS either.
By enabling multi-network integration, the third-generation convergent SDP can play a vital role in migrating services from the legacy circuit-switched networks to packet-switched networks and IMS. The initial commercial rollouts of IMS have demonstrated that migrating existing services and users is one of the key issues that operators have to contend with.