As SDPs evolve, they will often require integration of telecom and IT capabilities and the creation of services beyond technology and network boundaries. SDPs available today are optimized for the delivery of a service in a given technological or network domain (examples of such SDPs include web, IMS, IPTV, Mobile TV, etc.). They will 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. SDPs are applied to both consumer and business applications.
The business objective of implementing the SDP is 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).
Telecommunications companies like Nokia Siemens Networks, 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. This strong focus on open environments has also given systems integrators such as Accenture, IBM, Alcatel-Lucent, Tech Mahindra and CGI the opportunity to offer turnkey pre-packaged, integration services and there are also, technology silo-ed focused, turn-key SDP solutions. In addition, new consortia of telecommunications 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.
As SDPs evolve beyond technology silos, several blended applications will be possible:
Up until the first few years of 2000, the markets for commercial and business telecommunication technologies were still saturated with proprietary hardware and software. Open standards started to become popular as IP technologies were introduced and 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, MjSip and its derived port by HSC) and products based on the relatively new SIP 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.hi
In industry today there are multiple definitions of Service Delivery Platform (SDP) being used with no established consensus as to a common meaning. Because of this, and the need for service providers to understand how to better manage SDPs, the TeleManagement Forum (TMF) has started standardizing the concept of Service Delivery Framework (SDF) and SDF management. The 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.
What is needed to deliver a blend of personalized services from multiple SDPs to end users is a means to inter-work those SDPs through common service enablers and network resources.
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.
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 and Italtel.
Software vendors who provide end-to-end solution for the IT SDP, Business Support Systems, Operating Support Systems, and SOA middleware suites include HP, wwite, IBM, Oracle and Sun microsystems. Network equipment vendors also provide SDPs such as IMS, IPTV, Mobile TV, etc. and offer the evolution of these SDPs.
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 , 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. SOA can also be used to standardize operational processes and re-use them across SDPs.
Identity and Information Management: In order to specify or design a SDP we must determine what the customer and device service dimension is. If the SDP design needs to accommodate say 1m users as well as manage their devices and each identitified item requires 5 to 10 information objects, the core SDP is probably dealing 20m objects in real time. As the management of these objects dictate the core identity management processes of the platform, critical attention should be applied to the way in which they are implemented. Experience has shown that a single user on a converged services SDP may require 100 objects of information with some objects such as preferences containg 100 attributes. Capacity requirements for 10m users would indicate the platform needs to support 1 billion objects and up to 50 billion attributes.
Group Identity and Entitlement: Traditionally we have dealt with Identity Management as a single user or device logging on with a name and password and have assumed that an Identity Server holding names and passwords solves the issue. Practically though in the MSO world, we have account holders, secondary account holders (the children of the family), guests, gifts, content, devices, preferences which must all link together in order to receive a managed service. The services the grouped identity receives might be authorized via name and passwords, but should only be enabled through entitlements that relate to product provisioning. SDP architectures need to accommodate group identity management and product/service entitlement functions.
Presence and Events: Presence is the status management of all online assets. But what does this mean to system architectures? Traditionally we have applied a "transactional" paradigm where for example a user logs on and creates a transaction onto a network switch, a web server or database application. Presence services means we are managing status events at rates much, much higher than our traditional transactional systems. The question is: how are millions if not billions of events managed in fragmented systems, multiple database architectures or in fact frameworks? SDP architectures should also have a coherent, highly integrated event management system as a core function.
Converged Identities: 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 telephone 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".
SDP technologies and tool kits should address three fundamental issues:
These three major system requirements actually dictate the 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. If these fundamental requirements are omitted from the SDP design it leaves the operator with many business, service management and operational problems to address, such as:
There are situations where MSOs 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 easily.
A quick test of an 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 including its presence and event management functions. In support of SDP development and the evolution to real time, agile services delivery, next generation systems should be considered.