1). Service Delivery Platform Hightlights
1.1). SDP Principles thru SOA
1.2). SDP OV
1.3). SDP Vision and Objective
1.4). SDP Types
1.5). Operator's objective on SDP
2). Summary of SDP Functions
2.1). Scope for Service Creation and Execution Environment
2.2). Scope for Enablers and Enabler Framework
2.3). Scope for Network Layer
2.4). Scope for Business Management
2.5). Scope for O&M
3). SDP Deployment
1). SDP -Service Delievry Platform Highlights
1.1). SDP principles thru SOA:
§ Services are loosely coupled
§ Services enable the reuse of components and network assets
§ Services can be reused to build composite variations
§ Services are autonomous
§ Services have well-defined interfaces, using Web Services technology and networking technologies as appropriate—in most cases with various policy bindings
§ Services are highly interoperable: Interoperability is based on the formal definition of a Web Services profile independent of the underlying platform, programming language and vendor
§ Services are discoverable—the SDP includes service registry for auto-discovery
§ An SDP allows service providers to efficiently create, provision, and manage the myriad services running over converged networks and, importantly, easily create new, differentiated services through a Service Oriented Architecture (SOA).
1.2). SDP OV:
§ An SDP is a system that manages service delivery across a specific domain.
§ Typically that domain is entirely within one service provider’s environment and is controlled by rules established by that service provider.
§ A service provider could have several SDPs at the same time each one controlling specific groups of services.
§ Typically, the SDP makes direct use of telecom specific standards and best practices.
§ An SDF (Service Delivery Framework) on the other hand can be thought of as a service delivery mechanism that transcends multiple SDPs and/or service provider domains.
§ An SDF is not supposed to be telecom specific.
§ By its very nature, an SDF is supposed to abstract services in ways that hide telecom specific terminology and language.
§ Service Delivery Platform (SDP) provides the necessary components (hardware & software) that allow the creation, delivery and management of new digital services through a horizontal service network in a telecommunication environment.
§ An SDP combines standard interfaces to backend billing and support systems with business process rules and open APIs to help providers attract and retain subscribers by enabling the rapid creation of personalized, blended services, providing new revenue streams.
§ Further, with the shift towards convergence, constantly changing market forces of supply & demand, and the increasing need to offer flexibility and security as key differentiators; service providers and operators are realizing the need to align service delivery models with these developments.
§ Service providers and operators are beginning to revamp delivery models to maximize their potential revenue from existing and new convergent offerings.
§ Telecom companies are also realizing that it is imperative to build a platform that enables faster creation, and delivery and management of future services by third-party application developers or by the service providers themselves.
§ To ease the complexity associated with integrating the service into existing business support system (BSS) and operational support system (
1.3). SDP Vision and Objective:
The vision of Service Delivery Platform is to design, develop, evaluate, prototype an architecture and framework that
§ supports an easy and quick service creation and execution environment, seamless delivery of services across operators domains, networks and terminals
§ provides service enablers and investigate seamless services delivery aspects
§ assists easy and seamless access services and applications
§ facilitates end-to-end communication based on an open architecture supporting fast service and content control
§ A service can be described as a unit of work done by one or more SDP enablers to achieve desired end results for a service consumer/partner.
§ A service-oriented application is constructed through a collaboration of autonomous specialist SDP enablers.
§ SOA-based architectural style creates to achieve loose coupling among interacting enablers.
§ SOA adoption within the SDP allows service-oriented applications to be easily constructed through a collaboration of autonomous specialist enablers that are discovered through Universal Description, Discovery and Integration (UDDI) registries and accessed using Simple Object Access Protocol (SOAP).
The objectives of the Service Delivery Platform are
§ Rapid service deployment for fastest time-to-revenue.
§ enabling new business models and redefining the role of telecommunication operators from access to service providers and blurring the roles
§ taking benefit of existing variety of services, networks and devices and make services more intelligent and easier to use (assist users and developers)
§ Service differentiation for better customer acquisition and retention.
§ supporting inter domain aspects like service provisioning and inter working for example
§ providing services timely: accelerate creation and delivery of services in terms of fast service creation and reduce “time-to-market” for new services
§ opening platform capabilities to 3rd parties and support multi-vendor and multi technology middleware platforms
§ providing a unified and seamless way to deliver services over heterogeneous execution platforms, network and terminals
§ enriching the service landscape, through an overlay structure offering a personalized user experience anytime and anyplace
§ creating a trusted and open platform that can simplify the use of services and devices through personalization and customization (open-up to new business models and value chains)
§ promoting the uptake of innovative IT software technologies in a telecommunications grade service platform environment
§ Lower cost of service deployment.
1.4). SDP Types:
§ An open SOA-based architecture that allows embedding multiple service optimized SDPs, including IMS, IPTV, commercial Web SDPs, as well as current telecommunication SDPs, such as MMS and IN, into a single SDP.
For different services in different domains may comprise multiple SDPs, as like
§ IMS multimedia SDP – may include IMS application servers, SCIM functionality, Diameter and Web Services, via IMS control elements, such as the S-CSCF, RACF, and enablers such as the HSS for user data, and location and presence servers, etc.
§ IPTV broadband SDP – may include application platforms optimized for TV-focused services, such as channel bundling, through Web Services (XML/SOAP) interfaces, and video streaming servers using video-specific delivery protocols (IGMP, RTSP) for channel delivery and VOD services
§ Mobile Service / Content SDP – may include an application platform optimized for mobile multi-media content purchasing and delivery, using Web Services technologies and protocols, relying on
§ Web Services SDP - may include standard IT industry application servers (third party JavaEE, Web 2.0) using Web Services technologies and protocols, such as XML and SOAP, and control elements such as DNS, DHCP, etc. for e.g. Internet Services.
§ Legacy service SDP - may include capabilities such as MMS/SMS with their controllers, WAP gateways, or IN services, equipped with IN protocols, controlled through Service Signaling Points (SSPs) and Service Control Points (SCPs), etc
§ Mobile TV SDP, etc.,
SDP is targeted to leverage four key industry domains:
§ telephony (carrier-grade reliability, real time),
§ web (rapid, low cost service creation),
§ broadcast (content), and
§ IT (speed, simplicity, cost)
1.5). Operator’s objectives on SDP:
Clearly operators must evolve to achieve revenue growth and revenue channel diversification. They must clearly identify the assets that differentiate them from competing service providers and build SDPs which can maintain their full ownership of the key following attributes of their unique position:
§ Subscriber identity – they can actually validate the name/address of the subscriber.
§ Online and on the ground presence - many operators have high street retail outlets or partners that can touch/be touched by subscribers.
§ Intimate relationship with subscribers - that provides them with information about subscribers’ home address, family members, friends, payment mechanisms, spending power, etc.
§ Subscriber trust – subscribers trust operators and look to them for verification and validation.
§ Subscriber location information - live positioning from the network, home address, work address, frequent holiday/travel destinations etc.
§ Device status – online/offline/busy.
§ Knowledge of device capabilities - subscribers either purchase from operator or are required to specify same.
§ Billing and charging relationship - which can be exposed to collaborating providers.
§ Access to live and historical usage data - that can be transformed into critical user profile information.
§ Single sign on, data access and identity federation - the handset is the subscriber’s key to access all services, no further authentication is required as the handset is a personal device that is not commonly shared or highly susceptible to external interference. (e.g., calendar information, contact information, group lists)
§ Trusted access to user devices - to provide automated provisioning and service set up tasks.
§ Allows to achieve rapid service execution time
§ Adoption of standardized open enablers reduces vendor dependency and will drive down service rollout and ongoing maintenance/operating costs
§ Continue to defend their single biggest asset – the relationship with the customer and become the one-stop-shop for services: To achieve this, the operator must continue to win subscriber trust by delivering tailored services to them that they can easily use, when they need them.
There are different SDPs promoted and presented in the markets. The functions needed in SDP will depend on the service & application introduced into different domain or multiple domains (IPTV, Content, NGN/IMS, Mobile Service, etc.) and created & supported for business of the service provider. These possible needed functions are categorized & listed into the following five scopes.
2.1). Scope for Service Creation and Execution Environment:
§ Provide Service Creation Environment tools for service creation.
§
§ Service publishing
§ Service composition
§ Mock-up service composition
§ 3rd party service discovery
§ Service repository browser
§ Service testing
§ Support for service creation and deployment (Carrier grade application execution platforms)
§ Include the multitier Service Creation Environment and the Application Servers of the various SDPs.
§ Software Development Kit (SDK): provides simplified APIs for the creation of new services and service directory.
§ Provide an integrated development environment (IDE) and Framework for code development.
§ Services built on the standard-based platform.
§ Provide “Application Framework” – including management functions (On-boarding and Admin Portal for setting SLAs, Reporting, etc.) and Application Network Access Interfaces (i.e., interfaces such as Parlay-X/Web Services, Parlay, etc.)
Ø Web Services interface for third party service creation
Ø Expose services and control access to them by 3rd parties
§ Development of service specific components for new services.
§ The service directory based on the service catalog manages the value-added services, and enables to discover, select, and reuse components in creating new services and extending existing ones.
§ Reuse existing capabilities related to system resources and services
§ Allow for simple or blended services to be created and deployed across one or multiple SDPs, with applications that combine different services, like Video Services, SIP Services, Internet Services and other services, such as
§ Create new services thru combining pre-existing services
§ Service lifecycle management: Deactivation - when demand reduces or the service becomes obsolete or out of season.
§
§ Service deployment
§ In TMF SDF, Service lifecycle Operation Support including creation, test, deployment, execution.
2.2). Scope for Enablers and Enabler Framework:
§ Many enablers will exist in the SDP within the operator environment, while other enablers will reside on the Internet e.g. Google or Yahoo Web services.
§ The choice of supplier enabler should be determined based on proven integration whether it be standards based or through referable pre-integration activities.
§ An enabler encapsulates one or more pieces of data or functionality that is purposely packaged to be easily integrated with other enablers or applications, for example, call control for click to call applications, unified user profile for single-sign-on & personalization, location of subscriber position to applications, and presence to indicate subscriber availability, etc.
§ Sets of enablers define and differentiate SDPs.
§ Common Enablers for the Delivery of Personalized and Blended Services across Multiple SDPs
§ The enablers may facilitate service creation, service execution, media mixing and call/session control, seamless integration to OSS/BSS functionality.
§ The common enablers across-SDP can enhance service personalization, such as Subscriber Data Management, Converged Payment, etc, and support a partner application ecosystem through exposure and abstraction capabilities for 3rd party integration and including support for automated business processes, such as Parlay / Parlay-X GW, Content Management, etc.
§ Enablers (Common Services): like Identity Management, Device Management, Online Charging Services, Presence and Location, etc.
§ Network Abstraction Interfaces: Parlay and Parlay-X based multimedia control capabilities for quadplay services
§ An enabler thru integral part of IMS infrastructures, service brokering for IMS applications, just as S-CSCF and SCIM would do
§ An enabler thru integral part of messaging application functions – SMSC, MMSC, IM, Streaming server, Mobile Positioning server, Presence server, XDM server, Conferencing server, etc.
§ Integration with enablers and other existing service elements: Ability to easily extend existing service enablers with new service capabilities as they show up
§ Personalization via Policy: based on unified user profile and specific subscriber requests and usage patterns. (Dynamic decisions based on policy or end-user selections due to context, preferences, etc.)
§ Profile Management: Information about subscribers, networks, and services are managed in profiles. And the federate data includes user subscription and service profile information, or policy, etc (Voice Mail, User Subscription Profile, Address book, Privacy, etc.)
§ User profile creation
§ User profile personalization
§ User profile providing
§ User profile rating
§ Also enables operators to analyze service usage activities of subscribers based on access history - to generate abstract usage patterns and supply valuable insights to value-added services
§ QoS/SLA management: across all parties in the service delivery according to efficient service models, and for targeted advertisement and user profiling
Ø Resources Control: Allocate required IP resources based on network knowledge and policies
Ø Traffic Flow management over network resources: A powerful session flow monitoring and control mechanism that include quantifying and satisfying service level agreements (SLAs) for the external customers.
§ Digital Rights Management: Automate the relationship with application and content partners, including revenue sharing
§ SOA components: include the Service Bus, Service Orchestration, Registry and SOA Governance for the business integration through WebServices and service interface adapters.
§ Service Orchestration thru Service Brokering: The service orchestration is for orchestrating and managing various workflow processes. It manages the interaction of services at execution time, allows for personalized execution sequences and enables operators to easily define and customize each workflow process according to business requirements.
§ Rapid implementation or adaptation of business processes by using Business Process Execution Language (BPEL) for service composition
§ Charging for usage - Provides real time convergent on-line and off-line charging for all services: Manage billing and credit information for the used services
§ Community/Blogger management for grouping users with network capabilities or services, like PS, IM, Game, etc.
§ User profile matching
§ Device management - Provides ease of use of new services for the consumers.
§ Device configuration
§ Choice of access network
§ Identity management - Provides common way of managing your digital identity for Single Sign On or Authentication/Authorization in the service network.
§ User authentication
§ 3rd party service provider authentication
§ SIP Servelt Containers: build SIP- specific services, whereby the application developer need not to understand the complete signaling details of the SIP protocol and can instead program at a higher level of abstraction. SIP servlet container integrates with a variety of J2EE application servers.
§ Messaging Enabler: provides a set of north-bound Java and web service APIs that an application can use to send and receive messages. Application developer can view messaging as an abstract service that can be implemented to connect to an arbitrary provider without having to understand or depend on what specific protocol is used by that provider’s messaging gateway.
§ Location-Based Enabler: Same as like Messaging Enabler to utiilize service provider’s location-based gateway.
§ Note: Different vendor’s SDP presents different enabler to make network capability to be transparently & easily used by application developers in many applications. And Parlay/Parlay-X Gateway is the major approach and standards.
2.3). Scope for Network Layer:
§ Network call/session controllers are the S-CSCF for IMS, a VOD server for IPTV, etc.
§ Session and resource management related components binding services with the network
·§ Session or Service Blending via service orchestration or brokering: for blending services with sequenced execution
§ Signalling and Media Control: plays the role of connecting to all types of legacy and next generation call/session control signaling networks, and converting to and from various bearer traffic formats as necessary to ensure that any combination of circuit or packet based applications and networks
§ Call and Session Control: enables the SDP to intervene at any point during a call/session as necessary to facilitate service delivery
§ Service session transfer
§ Change service session
§ Service invocation
§ Service monitoring
§ Service pause/restart
§ Application data sharing
§ Application Control Interface: supports a lot of different interfaces for applications
§ Dynamic Resource Management: to handle admission control and throttling via RACF, PCC or PDF, etc.
2.4). Scope for Business Management:
§ Graphical Business Process Creation Environment
§ Partner Self-management and Partner profile management
§ Service Catalogue - Provide a registry for all services according and its implementation in the operator network. It describes the features, content types, network locations, and access mechanisms of each service.
§ Retail Capabilities: a set of enablers to allow operators to automate marketing and promotion, capitalize on cross-selling opportunities, and sell services directly to individual subscribers on a one-to-one basis
§ Branding: brand and customize retail storefronts with their own look and feel, marketing messages, and promotional offers.
§ Multiple Branded Storefronts: allows the content to be priced, promoted, packaged, and distributed for different customer segments.
§ Stocking the content, Pricing or Issuing a refund: Allows subscriber to select one or more of the pricing options (try before buy, per use, etc.), offers flexible pricing rules information to support a variety of business models for different subscriber groups, support an electronic refunding process on a given purchase
§ Content Management & Delivery: includes 3rd party management, Content Shop and Content administration of SDF enabled applications and services.
§ Content Management: Management of the service and its underlying content and resources - may include promotion and packaging.
§ Content push messaging
§ Content adaptation
§ Content publishing
§ etc.
§ Content Marketing: Integrated Environment for Mobile-Content Discovery, Delivery, and Billing thru campaign.
2.5). Scope for O&M:
§ OSS/BSS and network/device management components
§ OSS/BSS Gateways: provide for the seamless integration of an SDP into the OSS/BSS environment of the communications service provider.
§ Service monitoring: monitors the individual services and their composition.
§ Provisioning - Allow service and user data provisioning.
§ Reporting: aggregates and analyzes stored data and includes historic, real-time, or status reports.
§ Hot provisioning of new network elements during live traffic
§ GUI for provisioning and management of network and other resources.
§ Automated partner and service provisioning
§ Subscription or Self-Subscription Management
§ Service advertisement
§ Service roaming
§ Service matching
§ User service discovery
Ø Top-down: from an
Ø Bottom-up: from an end-user terminal using self-subscription features offered through an application client
§ Integration straightforward thru initial deployment or support self-service models thru service discovery and selection (like IPTV EPG)
§ User Knowledge discovery
§ User knowledge providing
§ Activation on user accounts.
§ Multi-level authentication and authorization
§ Detailed white-black list management
§ CRM and Customer Service execution.
§ Real-time performance statistics
§ Alarm management
§ etc.
3). SDP Deployment
§ The implementation of SOA in a complete end-to-end solution strive to minimize integration needs via standards-based interfaces and web services.
§ Choose open & standard interfaces for SDP deployment for minimizing the integration efforts - Interfaces across SDPs and within the SDP should minimize the need for integration in three main areas:
Ø Southbound Interface to underlying network core components
Ø Northbound Interface for third party applications and services.
Ø Interface between support applications such as CRM, Billing, and Service activation in BSS/OSS
§ Deploy new service platforms for each domain (e.g., IPTV, and IMS, etc.) with SDP integration
§ Deploy IMS enablers to create a single user identity, presence, application state and device capabilities to share interaction among service platforms.
§ Integrate existing legacy platforms such as IN, PLMN and PSTN through industry standard interfaces
§ Service components bring SOA (Service Oriented Architecture) principles to a service delivery context by enabling orchestration, policy enforcement, etc.
§ Web Services offering a set of protocols enable interaction and synchronization between applications
§ Service orchestration enables workflows across applications to provide new services to customers
§ Complexity & Scope should be limited and controlled by phases due to the costs, schedule, management and maintenance concerns.
