Not What You Meant? There are 21 definitions for SDP.

Service Delivery Platform

About 8 pages (2,439 words)

Questions on this topic? Just ask!

The term Service Delivery Platform (SDP) refers to a recently embraced architectural style applied to telecommunications infrastructure problems. It is intended to enable rapid development and deployment of new converged multimedia services, from basic POTS phone services to complex audio/video conferencing for multiplayer games (MPGs). SDPs typically provide a service control environment, a service creation environment, a service orchestration and execution environment, and abstractions for media control, presence/location, integration, and other low-level communications capabilities. Often, they will feature a unified directory of customers which provide a metadata architecture for all existing customer databases, including business, consumer, broadband or mobile. SDPs are applied to both consumer and business applications, with the latter set often focused on the integration of telecom and IT capabilities. Although telecommunications companies like Nortel, Avaya, Ericsson and Alcatel-Lucent have provided communications integration interfaces and infrastructure since the early to mid 1990s, the cost-saving success of IP-based VoIP systems as replacements for proprietary PBX systems and desktop phones has prompted a revolutionary shift in industry focus from proprietary systems to open, standard technologies. As much as this change has been a tremendous selling point for new systems from traditional vendors, it has also opened the door of the telecom closet to traditional IT vendors like CGI, IBM, HP, Oracle, Redhat and BEA Systems who are developing or have developed SDPs of their own. This strong focus on open environments has also given systems integrators such as Accenture and CGI the opportunity to offer turnkey pre-packaged, integrated SDP solutions. In addition new consortia of telecommunications new software product companies are also emerging. By offering pre-integrated software products consortia offer an alternative means for operators to create SDPs based on key product elements - such as convergent billing and content/partner relationship management. Some example applications of an SDP:

Users can see incoming phone calls (Wireline or Wireless), IM buddies (PC) or the locations of friends (GPS Enabled Device) on their television screen
Users can order VoD (Video On Demand) services from their mobile phones or watch streaming video that they have ordered as a video package for both home and mobile phone
An airline customer receives a text message from an automated system regarding a flight cancellation, then opts to use a voice self-service interface to reschedule

1 History
2 Elements of an SDP
3 Relationship to SOA
4 The Reality of Implementing SDPs
5 See also
6 External links

History

The late 1990s saw a period of unprecedented change in enterprise applications as the grip of client-server architectures gradually relaxed and allowed the entrance of n-tiered architectures. This represented the advent of the application server, a flexible compromise between the absolutes of the dumb terminal and the logic-heavy client PC. Although entrants into the application server ring were many and varied, they shared common advantages: database vendor abstraction, open standard (mostly object-oriented) programming models, high availability and scalability characteristics, and presentation frameworks, among others. These transformations were triggered by business forces including the rampaging tidal wave that was the Internet boom, but none of it would have been possible without the proliferation of standards such as the TCP/IP protocol, the Java programming language, and the J2EE web application server architecture. It is against this backdrop of transformation that telecom's era of rapid change was set in motion. Up until the first few years of 2000, the markets for commercial and business telecommunication technologies were still saturated with proprietary hardware and software. Vendors such as Lucent Technologies, Nortel, and AT&T jousted for position in the consumer and enterprise telecom markets, continuing to build giant business PBX systems that would speak only to their own digital telephones via proprietary protocols, and to sell huge central office switching equipment that offered traditional robustness, but very awkward customization capabilities. This all changed with the rapid expansion of Voice-over-IP (VoIP) for transmission of voice data over packet networks and the Session Initiation Protocol (SIP) for standardized media control, especially regarding enterprise voice communication. In this new standards-supported environment, convergence of the voice and data worlds has become less a moniker for disastrous telecom/IT integration attempts and more a true avenue for the production of new and better consumer and business services. The last few years have seen the introduction or proliferation of various SIP programming libraries (reSIProcate, Flextronics) and products based on the relatively new SIP Application Server standard, and the IP Multimedia Subsystem standard defined by the 3GPP has gained a huge following. The Service Delivery Platform, whose power comes in large part from the quality and acceptance of these supporting standards, is rapidly gaining acceptance as a widely applicable architectural pattern.

Elements of an SDP

Service Creation Environment

Often a telecom software developer's primary access point, the Service Creation Environment (SCE, also Application Creation Environment or Integrated Development Environment) is used by the developer to create software, scripts, and resources representing the services to be exposed. These can range in complexity from basic Eclipse plug-ins (as with Ubiquity's UDS, or Ubiquity Development Studio) to completely abstracted, metadata-driven telecom application modeling applications (like Avaya's discontinued CRM Central product). The purpose of the SCE is to facilitate the rapid creation of new communication services. Ignoring factors like marketing for the moment, the easier it is for developers to create services for a given platform, the greater will be the number of available services, and thus the acceptance of the platform by the broader telecom market. Therefore, a telecom infrastructure provider can gain significant advantage with an SDP that provides for rapid service creation. The leveraging of converged J2EE and SIP service creation environments has accelerated the adoption of specific Service Delivery Platform solutions. Java-based applications developers, traditionally focused on IT applications, are now rapidly developing real-time communications applications using J2EE and network connecting protocols like SIP and Parlay X web services. Software vendors are combining these technologies (e.g. Oracle Jdeveloper and Oracle Communication and Mobility Server with basic Eclipse plug-in) to reach out to a broader developer base.

Execution Environment

Media Control

Presence/Location

One aspects of an SDP is that it must be centered on the new "point of presence". This is the point of user access to their converged services where their preferences and entitlements are evaluated in real time. Preference and entitlement processing ensures that the user's services in their device/location contexts are delivered correctly. As entitlements are related to the product and service management regimes of the operator, the core architecture of an SDP should define managed products, services, users, preference and entitlement processes. The implementation of standards remains a critical factor in Presence applications. The implementation of standards such as SIP and SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions) is becoming more prevalent. SIMPLE Presence provides a standard portable and secure interface to manipulate presence information between a SIMPLE client (watcher) and a presence server (presence agent). See JSR 164 for SIMPLE Presence. Providers of SIMPLE Presence servers include Oracle.

Integration

A standards-based SDP solution should minimize the need for integration in three main areas: (1) southbound to underlying network core components (2) between support application such as CRM, billing, and service activation (3) third party applications and services. The implementation of SOA in a complete end-to-end solution strive to minimize integration needs via standards-based interfaces and web services. Software vendors who provide end-to-end solution for SDP, Business Support Systems, Operating Support Systems, and SOA middleware suites include HP, IBM, Oracle and Sun microsystems.

Relationship to SOA

Much has been made in recent years of the Service-oriented architecture (SOA) concept. Discussions that once centered on Enterprise Application Integration (EAI) technologies and concepts have shifted into the SOA domain, favoring ideas like service composition over simple message adaptation and extract, transform, and load techniques. SOAs can be used as an application integration technology within an SDP but are best served when used in the lower performance functions such as connections between the transactional OSS and BSS applications and the SDP. SOAs need careful consideration if they are to meet the real time demands placed on the SDP by the converged event type services. An analogue concept to SDP found in the realm of SOA is that of Web Service Ecosystem (also known as Web Service Marketplace) and the SaaS platform. A Web Service Ecosystem is a hosted environment in which participants expose their services using common Web technology such as HTTP, XML, SOAP or AJAX. This hosted environment provides a number of service delivery components covering aspects such as authentication, identity management, usage metering and analytics, content adaptation, data format conversion, charging and payment. This enables service providers to focus on their core functionality and to outsource the service delivery to third parties. Services deployed over Web Service Ecosystems may be business-critical, but they typically do not have the real-time and high-performance requirements associated to telecommunications services for which SDPs are traditionally conceived. They usually support common business functions such as quoting, order management, marketing campaign management or customer care.

The Reality of Implementing SDPs

Considerable changes in IT architecting are required when implementing real world, real time, converged services, operational SDPs. Why is this necessary? Many SDPs are designed as abstract frameworks with diagrams that use labels such as "Service Abstraction Layer", etc. Within real systems such "layers" do not actually exist. In addition it is difficult to realise from these abstract diagrams what the real world operational data model is and how many databases or directories might be used or infact how such databases are integrated to form converged services self care functions.

There is also an operational issue emerging with 3G IMS and SIP and converged services. SIP can apply IP addresses (IPv4 or v6), SIP URIs (email addresses) and SIP TEL URIs (telephone numbers) in its message To, From, Via and Contact fields. Such identifiers can point to a telphone device, a fridge door, a content farm, a single piece of content, a user or even a group of users. This flexibility means that a SIP call can be made from just about anything to any other thing providing it is entitled to do so. As SIP can apply a mixture of these Internet and Telephone system identifiers in the call process, it follows that the SDP must tightly couple its SIP processing with the DHCP/DNS system, the HSS mobile database, the User authorization system, the presence event system, the user's address book, telephone call feature processing and the operator's service/product management with its entitlement system - all in real time. It follows that such functionality would be very difficult to apply across many interconnected functions and fragmented databases using "SOAs". Many of the technologies and tool kits provided today still leave two fundamental issues to the operator or implementor. These issues are:

What are the goods and services being offered and managed in a real time fashion by the operator and by the customer self care systems - and this includes the management of presence based services (the world of the event driven internet) and how realtime user entitlements are processed.
What is the converged services information model used in the SDP design that represents the online business of the operator that has subscribers, devices, phone calls, preferences, entitlements, address books etc to deal with. In many cases MSOs with just 10 million customers require a SDP with 500 million information items - and for these items to be accessed many thousands of times a second by many different SDP functions.

These two major system requirements actually dictate architecture of a real world operational SDP regardless of the "abstract labels" one applies to its logical models, SOAs, message bus protocols and server interconnects. In many cases these fundamental issues are omitted from the SDP design leaving the operator with many business, service management and operational problems to address, such as:

identity management (of all the information in the SDP representing the operators online assets),
the SDP's service agility (that is the product and services being offered are hard coded into the SDP so that new services cause code upgrades) and;
hard wired self care facilities (no flexibility or consideration of the SDPs users such as language, age, sighted, preferences, etc).

Many MSOs world wide are demanding real time agile service management and self care systems. Many are evaluating situations where they have millions of lines of hard coded product and service management flows in their systems and are unable to move to the newer converged service dimensions. A quick test of a SDP design is to evaluate its information model and see if that is based on the user environments of converged services, and see how that model is used and managed by all the systems that need to.

In support of SDP development and the evolution to real time, agile services delivery, next generation systems must be considered.