A service delivery platform (SDP) is a set of components that provides a service(s) delivery architecture (such as service creation, session control and protocols) for a type of service delivered to consumer, whether it be a customer or other system. Although it is commonly used in the context of telecommunications, it can apply to any system that provides a service (e.g. VOIP Telephone, Internet Protocol TV, Internet Service, or SaaS).[1] Although the TM Forum (TMF) is working on defining specifications in this area, there is no standard definition of SDP in industry and different players define its components, breadth, and depth in slightly different ways.
SDPs often require integration of IT capabilities and the creation of services that cross technology and network boundaries. SDPs available today tend to be optimized for the delivery of a service in a given technological or network domain (e.g. in telecommunications this includes: web, IMS, IPTV, Mobile TV, etc.). They typically provide environments for service control, creation, and orchestration and execution. Again in telecommunications, this can include abstractions for media control, presence/location, integration, and other low-level communications capabilities. SDPs are applicable to both consumer and business applications.
In the context of telecommunications only, 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 video games (MPGs). In the context of SaaS, similar business objectives are achieved but in a context specific to the particular business domain.
The emergence of Application Stores, to create, host, and deliver applications for devices such as Apple's iPhone and Google Android smartphones, has focused on SDPs as a means for Communication Service Providers (CSPs) to generate revenue from data.[2] Using the SDP to expose their network assets to both the internal and external development communities, including web 2.0 developers, CSPs can manage the lifecycles of thousands of applications and their developers.[3][4]
Telecommunications companies including Telcordia Technologies, 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 private branch exchange (PBX) systems and desktop phones has prompted a shift in industry focus from proprietary systems to open, standard technologies.
This change to open environments has drawn software-focused telecommunication companies like Teligent Telecom[5] and allowed systems integrators such as Tieto, Accenture, IBM, TCS, HP, Alcatel-Lucent, Tech Mahindra, Infosys, Wipro, and CGI to offer integration services. In addition, new consortia of telecommunications software product companies offer pre-integrated software products to create SDPs based on elements, such as value-added services, convergent billing and content/partner relationship management.
Since SDPs are capable of crossing technology boundaries, a wide range of blended applications become possible, for example:
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
Airline customers receive a text message from an automated system regarding a flight cancellation, and can then opt to use a voice or interactive self-service interface to reschedule
The service delivery platform market is expected to grow at a CAGR of 10% over the forecast period 2019-2024.[6]
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 Java EE 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. 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, Aricent, 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.
In industry today multiple definitions of Service Delivery Platform (SDP) are 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 TM 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. Underpinning these service aspects though has been a fundamental concept that the user's attributes and the services they receive require a common repository and a common data model, such as those provided by an LDAP/X.500 directory or HSS database. Early SDP implementations of this nature started in the mid / late 1990s for ISP converged services. Larger and more complex SDPs have been implemented over the last 5 years in MSO-type environments and for mobile operators.
Context
SDPs are commonly considered for telco-type environments as a core system which interconnects the customer's access and network infrastructure with the OSS systems and BSS systems. SDPs in this context are usually associated with a particular service regime such as mobile telephones or for converged services.
SDPs are also considered in the context of very large transformation, convergence and integration programs which require a considerable budget. The difficulty in such projects is that there may be hundreds of thousands of design and implementation decisions to be made - once the architecture is agreed upon. Naturally, this issue alone dictates the need for software development and operational engineering skills. Probably the best way of reducing these design and integration issues is to simulate the SDP on a small-scale system before the major project actually starts. This allows the architecture to be verified that it meets the operational, service delivery and business requirements.
SDPs should also be considered not just as a core function within an operator but as a number of interconnected, distributed service nodes (e.g.) for redundancy reasons and for different service profiles to different business and market sectors. Many operators provide commercial scale/grade products such as bundled voice, web hosting, VPNs, mail, conference and messaging facilities to government and corporate clients. The evolution of such bundled services could be from fragmented management systems to a "Virtual Private Service Environment" where the operator runs a dedicated SDP for each of its customers who require their services on demand and under their control.
SDPs can also be used to manage independent wireless-enabled precincts such as shopping malls, airports, retirement villages, outcare centres.
Elements
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 to completely abstracted, metadata-driven telecom application modelling 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 Java EE and SIP service creation environments accelerated the adoption of service delivery platforms. Java-based applications developers, traditionally focused on IT applications, develop real-time communications applications using Java EE 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
This section is empty. You can help by adding to it. (July 2014)
Service Execution Environments (SEE) are used to execute the communication services developed in SCE. Execution environments are typically designed to mimic the hardware the particular service is expected to run on. SEE may be bundled with SCE as an IDE
Media Control
This section is empty. You can help by adding to it. (July 2014)
Presence and location
One aspect 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 and Italtel.
Integration
The use of standards for exposure for interfaces across SDPs and within the SDP should minimize the need for integration in three main areas: (1) southbound to underlying network core components (2) between support applications such as CRM, billing, and service activation (3) third party applications and services. The implementation of service-oriented architecture (SOA) may use standard interfaces and web services.
Software vendors 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 technologies such as HTTP, XML, SOAP and REST. 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.
Implementing SDPs
Considerable changes in IT and Network architecture are required when implementing real-world, real-time, converged services, operational SDPs. 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 abstract diagrams what the real-world operational data model is and how many servers, databases or directories might be used or integrated to form converged services SDP and self-care functions. Operators can be faced with annual multimillion-dollar electricity bills for their systems. It follows that multi-server/multi-database SDPs are not earth-friendly or cost-effective, if the same functions can be integrated and use much less power.
Identity and Information Management: In order to specify or design a SDP we must determine what the customer and device service dimensions are. If the SDP design needs to accommodate, say, 1m users as well as manage their devices and each identified 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 containing 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 mean 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: An operational issue emerges 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 system and DNS, 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:[citation needed]
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 real-time 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 an SDP with 500 million information items - and for these items to be accessed many thousands of times a second by many different SDP functions.
What is the event / presence management architecture used in the SDP design that handles the velocity of the online business events. The situation might be that the population of a city arriving home at night might generate billions of online status events. How will these be processed by the SDP?
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:
identity management (of all the information in the SDP representing the operator's 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.).
In some situations, 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 include its presence and event management functions.
In support of SDP development and the evolution to real-time, agile services-delivery, next-generation systems should[citation needed] be considered.
The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).
The Intelligent Network (IN) is the standard network architecture specified in the ITU-T Q.1200 series recommendations. It is intended for fixed as well as mobile telecom networks. It allows operators to differentiate themselves by providing value-added services in addition to the standard telecom services such as PSTN, ISDN on fixed networks, and GSM services on mobile phones or other mobile devices.
Middleware in the context of distributed applications is software that provides services beyond those provided by the operating system to enable the various components of a distributed system to communicate and manage data. Middleware supports and simplifies complex distributed applications. It includes web servers, application servers, messaging and similar tools that support application development and delivery. Middleware is especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture.
Voice over Internet Protocol (VoIP), also called IP telephony, is a method and group of technologies for voice calls, the delivery of voice communication sessions over Internet Protocol (IP) networks, such as the Internet.
BEA Systems, Inc. was a company that specialized in enterprise infrastructure software products, which was wholly acquired by Oracle Corporation on April 29, 2008.
In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.
HCL Sametime Premium is a client–server application and middleware platform that provides real-time, unified communications and collaboration for enterprises. Those capabilities include presence information, enterprise instant messaging, web conferencing, community collaboration, and telephony capabilities and integration. Currently it is developed and sold by HCL Software, a division of Indian company HCL Technologies, until 2019 by the Lotus Software division of IBM.
A content delivery network, or content distribution network (CDN), is a geographically distributed network of proxy servers and their data centers. The goal is to provide high availability and performance by distributing the service spatially relative to end users. CDNs came into existence in the late 1990s as a means for alleviating the performance bottlenecks of the Internet as the Internet was starting to become a mission-critical medium for people and enterprises. Since then, CDNs have grown to serve a large portion of the Internet content today, including web objects, downloadable objects, applications, live streaming media, on-demand streaming media, and social media sites.
The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is a standardised architectural framework for delivering IP multimedia services. Historically, mobile phones have provided voice call services over a circuit-switched-style network, rather than strictly over an IP packet-switched network. Alternative methods of delivering voice (VoIP) or other multimedia services have become available on smartphones, but they have not become standardized across the industry. IMS is an architectural framework that provides such standardization.
Call Control eXtensible Markup Language (CCXML) is an XML standard designed to provide asynchronous event-based telephony support to VoiceXML. Its current status is a W3C recommendation, adopted May 10, 2011. Whereas VoiceXML is designed to provide a Voice User Interface to a voice browser, CCXML is designed to inform the voice browser how to handle the telephony control of the voice channel. The two XML applications are wholly separate and are not required by each other to be implemented - however, they have been designed with interoperability in mind
The next-generation network (NGN) is a body of key architectural changes in telecommunication core and access networks. The general idea behind the NGN is that one network transports all information and services by encapsulating these into IP packets, similar to those used on the Internet. NGNs are commonly built around the Internet Protocol, and therefore the term all IP is also sometimes used to describe the transformation of formerly telephone-centric networks toward NGN.
SipXecs is a free software enterprise communications system.
Oracle Fusion Middleware consists of several software products from Oracle Corporation. FMW spans multiple services, including Java EE and developer tools, integration services, business intelligence, collaboration, and content management. FMW depends on open standards such as BPEL, SOAP, XML and JMS.
HPE OpenCall is a range of network and telephony products offered by the "Communications & Media Solutions" branch of technology company HPE. It is most commonly described as a suite of software and hardware applications which allow implementation of common telecom operator services such as voicemail, sms, prepaid, billing, hlr, etc. It implements industry standard telecom protocols and standards such as SS7, ISUP, TCAP, SIP, MRCP, RTSP, and VoiceXML.
Unified communications (UC) is a business and marketing concept describing the integration of enterprise communication services such as instant messaging (chat), presence information, voice, mobility features, audio, web & video conferencing, fixed-mobile convergence (FMC), desktop sharing, data sharing, call control and speech recognition with non-real-time communication services such as unified messaging. UC is not necessarily a single product, but a set of products that provides a consistent unified user interface and user experience across multiple devices and media types.
Java Composite Application Platform Suite (Java CAPS) is a standards-based enterprise service bus software suite from Oracle Corporation. The suite has several components that help to integrate existing applications and deliver new business services in a service-oriented architecture environment. It is a Java EE compliant platform and provides application-to-application integration, business-to-business integration, business process management along with integrated human workflow, an Enterprise Information Portal, extract transform and load (ETL), business activity monitoring and composite application development.
Argela is a multinational corporation based in Turkey that develops communication technologies mainly for the telecom, public safety, and defense sectors. Founded in 2004, it was acquired by Türk Telekom in 2007. It is headquartered in Istanbul. Argela has branches in Sunnyvale and Ankara.
The JBoss Enterprise SOA Platform is free software/open-source Java EE-based service-oriented architecture (SOA) software. The JBoss Enterprise SOA Platform is part of the JBoss Enterprise Middleware portfolio of software. The JBoss Enterprise SOA Platform enables enterprises to integrate services, handle business events, and automate business processes, linking IT resources, data, services and applications. Because it is Java-based, the JBoss application server operates cross-platform: usable on any operating system that supports Java. The JBoss SOA Platform was developed by JBoss, now a division of Red Hat.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
