You are on page 1of 12

White Paper

Service Delivery Platforms

White Paper Contents Executive summary Operator challenge Value chain Service delivery framework Reference Architecture Service integration Consultancy approach Summary 3 4 4 5 6 7 8 10 2 .

The SDF should be seen as a logical representation of the whole delivery environment. • An SDP aggregates different network capabilities and services as well as different sources of content and allows application developers to access them in a uniform and standardized way.” Convergence enables these and other extensions to the mobility model: it dissolves the barriers that currently separate today's networks. • New technologies like IMS provide a set of common tools that can be used by all IPbased services. However. In order to extend the mobility premium. namely: • An SDP provides a complete ecosystem for the rapid deployment.morianagroup. in the form of IMS. On the other hand. the need to facilitate the development and implementation of valueadded services. For convenience the term Service Delivery Platform (SDP) is used as a way of referring to the architecture that is required to deliver these services. it facilitates outline agreements on the key business criteria before going on to consider a tailored solution. Unfortunately. In particular the following new challenges need to be addressed: • Mobility continues to bring added value to the end user. there is no standard definition for the term. it extends and advances the SDP concept: more specifically. That process is considered from a business perspective and it is visualized as a value chain that starts with terminals and ends with content (figure 1).com).White Paper Executive summary The future of the wireless industry is predicated on the delivery and management of valueadded services.a hardware/ software platform that addresses all the technical and business issues. Service providers need to build a service machinery. or the components that constitute an SDP. Devices and networks are also moving in the open systems direction. management and billing of value added services. For example. The paper concludes with an outline of the Nokia's approach to service delivery integration and consultancy based on this flexible and future-proof architecture. Thus. including both mobile and fixed networks. with aggressive marketing campaigns positioning mobile multimedia content at the heart of today's lifestyle. i. • Security. that enables them to offer a trusted and reliable service. Nokia's approach to solving the SDP challenge is to employ a “Service Delivery Framework” which is visualized through a reference architecture (figure 2). This means that wireless devices used primarily on cellular networks can access services and applications hosted on other networks. This is a key requirement since it reduces service deployment costs and shortens development times. • Intelligent Terminals. in the new evolving SDP world these boundaries between IT and network environments are merging. The paper also focuses on the complete ecosystem and is not limited to any specific domains within the value chain. In the past the SDP concept has been primarily focused on the IT infrastructure required to deliver and manage the service environment. Yesterday's mobility model was “anywhere. In a nutshell. Wireline and wireless networks are adopting the same communications protocol (IP). execution. 3 . • An SDP supports the delivery of voice and data services and content in a way that is both network and device-independent. The market for these services is enormous. and the various components that map to a customer specific value chain proposition. provisioning. operators are looking for new opportunities to enhance their service offering and to differentiate in the market place. the only significant difference being the way the services are accessed. This paper recognizes the current limitations of SDP as a term as well as the importance of the concept. Thus. Nokia's SDP vision is based on the definitions proposed by the Moriana Group (www. • Convergence.e. This vagueness allows vendors to provide 'solutions' that address individual market segments while still promoting their solution as an SDP. thus generating the need for a new end-to-end architectural view spanning the complete service delivery environment. the functionality provided by different networks is becoming similar. it is a reference model that defines a customized instance and its implementation. It is too late to change the terminology. the term implies that there is a single system . IP Security and Quality of Service need to be a key part of the service delivery architecture. but we can employ a better set of definitions. Open IP architectures are disruptive since they dissolve the barriers that currently separate networks. phenomena such as VoIP are creating pressure on stakeholders to invest in new and competitive solutions that bring new services to the consumers. with the underlying network simply providing the interface and delivery machinery. anytime”: now it's “my services on my device using one network all the time.

vertical services. a portfolio of addedvalue services. a brand-new service delivery concept is clearly required. By definition it has to be over-engineered and therefore incorporate functionality that may not be required. It is hard to overstate the importance of making the right SDP decision. In the past ownership of the service would be the same as that of the delivery channel (traditional IN. However. Matching market expectations is clearly impossible in a first-generation infrastructure based on stand-alone. both wireline and wireless.e. service delivery is such an important. which encompasses four main domains. the need to have a comprehensive service portfolio and to be able to add new services at short intervals requires the inclusion of content from third parties. there is a finite limit to this process: savage reductions will impact on customer service and telephone services can no longer be differentiated on price. i. Thus. It starts with targeted consultancy and a methodology that includes a set of workshops designed to allow the operator’s staff to engage at a topic level and bring their specialized skills to the table. customers are far less likely to swap operators. An alternative approach is to implement an all-embracing “Mega” service delivery platform that provides a pre-defined range of services and features. The Delivery Channel provides the transport mechanisms for the service. 4 . Differentiation as well as significant improvements in ARPUs and margins can only be achieved by offering the market what the market clearly needs and for which it is prepared to pay.White Paper Operator challenge Many operators face declining profitability through constant competition in the voice market. In fact. the largest part of their revenue stream. The only way to match market expectations is to enable the service delivery functionality and make it an integral part of the network operator’s delivery process. And if new services are added at regular intervals. allow terminal entities to access the services provided within the service delivery environment. It also entails choosing a service delivery platform that is exactly right for each organization. which may be a subscriber or an electronic consumer/agent. And it comes by taking a holistic. Realising that service portfolio is therefore more than a business goal: it is the only way to prevent valuable network resources turning into utilities — mere transporters of communications bits. so there is an on-going need to reduce OPEX. facilities must be provided in order to allow these external service providers to seamlessly integrate with the operator’s customer care and billing environment. Investing in a new infrastructure — migrating the network core from circuit to packet switching is required in order to enable the efficient delivery of the new services. However. In most operators this domain is owned by the network part of the organization. end-to-end view of the service environment. Service Logic functions include the process flow for the service. Standards bodies normally define interfaces and functions in this domain. operator. media push). peer-to-peer messaging) or it would be the responsibility of the network operator’s IT department (hosted content. Value Chain Management provides the functionality needed to manage the relationships between the end-user. Adding more service silos will only result in a service architecture that is even more complex. Nokia does not believe in the validity of this one-sizefits-all model. Value chain The value chain is a business concept: it is used to define the operator’s business requirements. This is not an issue that can be avoided. Thus. This functional area is normally owned by the operator’s IT department and typically includes the operator’s portal/home page. Access networks. The chain starts with the terminal. wide-ranging issue that Nokia needed to go back to first principles in order to ensure that all the issues are addressed. SDP is a term that means different things to different vendors and that makes comparisons and competitive evaluations particularly difficult. content publisher and service providers. This results in an SDP that allows operators and content partners to interact seamlessly and thereby create an open yet secure environment where personalized services can be easily invoked and managed. The ability to create and implement services quickly — to offer the market a comprehensive portfolio and to introduce new services in line with market requirements is the key to success in our mobile world.

e. provisioning. principles. the management of content and commercial relationships with other partners. one that covers the whole delivery chain. The framework must therefore be able to interface to and interact with external systems that provide this functionality. i. A framework can be a physical construction or a set of ideas. execution. along with service/user portfolio and personalization parameters. Charging in the new value-added services environment is a complex topic and will only become more complicated with the evolution towards a fully convergent architecture. This means that the charging mechanism cannot easily be shared since the delivery channels are intrinsically different. That statement came from the Moriana Group and it underlines the importance of addressing business requirements via an end-to-end architecture. The service delivery framework that Nokia has created provides a conceptual representation of the whole service delivery environment (including both mobile and fixed networks). rules that provide the basis or the outline for something that is more fully developed at a later stage. : The service delivery value chain. authentication and billing. and service discovery. There are obvious differences between a legacy. The service delivery value chain still applies when services and content are hosted on mobile terminals. a key functional requirement for the delivery channel is the ability to charge for the service regardless of the source. 5 .White Paper Service delivery framework content management. For example. In a nutshell. Equally important are: the management framework that surrounds the connectivity. it facilitates an outline agreement on the key business criteria before going on to create a tailored solution. SDP should provide a complete ecosystem for the rapid deployment. Meeting an operator’s business requirements entails a clear understanding of the individual roles and functions of each domain and how that functionality should be distributed and optimized. management and billing of value added services. The framework also recognizes that connectivity between services is only one aspect of the problem. hosted service such as SMS and a third-party service that is accessed via the Web. agreements. content adaptation. The value of the Content Domain is recognized by the flexibility and diversity of the content and the ability to introduce and manage new items very quickly in line with business and social trends. SDP Scope Value Chain Mgmt Terminal Access Network Delivery Channel Service Logic Content Figure 1. Focusing on one domain and then claiming that the result will be a service delivery platform cannot meet this allimportant objective. the business processes such as self-care. and enabling robust security. Common framework themes include the need to: • Implement new services quickly and costefficiently • Reduce development and integration cost through the re-use of common functions between services • Reduce the amount of bespoke technical development required for each new service • Decrease the cost of managing valueadded services • Increase the quality of the services provided • Match investment to revenue generation.

Once established. Once this stage is reached the physical architecture can be designed and the solution implemented. These groups enable the necessary separation and encapsulation of the various system components within the proposed SDP. including those hosted by the operator and delivered by third parties. The Reference Architecture. Customer care and billing provides the functions that the host requires to manage the business. the Integration Framework and Capability Exposure layer is the glue that binds everything together. The common services domain was not identified in the value chain because the functionality provided by these services is transparent to the value chain. Thus. Thus. Mobile Alliance -OMA). Examples of common services include: • Offline/Online Charging • Identity Management • Subscriber Profile Management • Device Profile and Settings Management • Subscriber Status All services and all delivery channels. can benefit from sharing the common services. Operational management system provides the functionality that the host requires to manage the services. the real value of the common services is to 6 . This experience is provided by exposing “the underlying network components that are suitable for a particular class of application” in order to “amalgamate. However. thereby significantly reducing the operational and integration overheads. abstract and/or repackage the capabilities of the generic components. the framework is actually a reference model used to define a customized instance and its implementation. it is easier to reach agreement on identifying the key components and functions required to implement a Service Delivery Platform. Therefore the resulting platform is a holistic solution ensuring a consistent subscriber experience and seamless content delivery. Primary SDF scope Figure 2.White Paper Reference Architecture The Reference Architecture defines the framework and establishes a common language and a common understanding between all parties involved during the consulting phase. Separation and encapsulation are required in order to support the key business drivers and business considerations. The Reference Architecure is segmented into nine areas that are derived from the value chain proposition. and present them as required for the interface” (Source: Open Operational Management System Content/Service Provider Customer Care and Billing Service Logic Value Chain Mgmt Integration and Capability Exposure Delivery Channel Common Services End-User / Terminal External Integration Points help optimize the overall architecture by providing reusable services for all functional areas. The implementations are different due to the specific and differing blend of business and technical challenges — challenges that were initially addressed by the logical architecture of the framework.

Each Ability needs to be able to operate independently and with the minimum of management intervention Service Logic Channes Glomming Interface Load Sharing and Failover Integration and Capability Exposure Interface Authorization And Access Control Dynamic Interfave Discovery The Ability to add and remove services dynamically using multiple possible hosts Value Chain Mgmt Delivery Channel The Ability to Change Delivery Channel configurations and add new channels Common Services The Ability to add and remove Common Service and physical configurations Figure 3. particularly between the service logic (which is not in the trusted domain) and other functions • Provide load sharing and failover facilities • Enable interface abstraction. automatic allocation of the delivery channel based upon the subscribers’ profile. e. The Integration Framework and Capability Exposure is the layer that binds everything together.White Paper Service integration The market expects operators to offer a comprehensive service portfolio and to add new services at regular intervals: services that can be self-provisioned via the Web. this layer has to be dynamic so its functionality must: • Allow the delivery channel infrastructure to be changed without affecting the services • Enable new common services to be added automatically • Allow value added services to be managed and changed dynamically • Provide security between the functional groups. However.g. Service integration impacts all four domains 7 .

The consulting phase is concerned with and addresses the question “how are we going to do this?” The physical layer is concerned with the description of the technologies.White Paper Consultancy approach Network operators have widely different requirements. business strategies and business challenges faced by the operator.“What with?” Figure 4. but they share the need for a pragmatic plan that will transform the current service delivery environment into one that matches their business strategy. They address the business and technical requirements of the particular subject area and they can be viewed as a standalone item or combined as part of the larger solution review and design. In addition. the market position and services strategy. These workshops are tailored to address the scope of the overall problem or opportunity being analysed as well as the operator’s specific market situation. the business requirement that will be used to measure the compliance of any system derived from the architecture. wideranging issue that a clear methodology is needed in order to ensure that all issues are addressed. but one that Nokia can deliver. It also identifies the key business cases that need to be addressed.“Why?” Conceptual layer . interfaces and products that will be used to construct a system founded on the logical architecture. Workshop topics currently include: • Provisioning • Charging • Architecture optimization • Service Provider interaction • Lowering OPEX • Systems integration. Nokia offers a set of workshops which allows the operator business owners and technical experts together with Nokia to bring their specialized skills to the SDP table. these workshops utilize a four layer model that allows the different topic areas to be segmented for architectural separation. In broad terms. In line with industry trends. It’s a tall order. presentation and detailed analysis. new design) • Business case analysis • Phasing of SDP implementation. The contextual layer is concerned with the definition of the business vision.“What?” Logical layer . So far so good.“How?” Physical layer . The consulting phase is concerned with and addresses the question of “what are we going to do? The logical layer is concerned with the description of the functional components that will be required to create a system that will satisfy the requirements identified and defined within the conceptual layer. SDP is such an important. but the SDP will also need to factor in the dynamics of today’s marketplace. Nokia Systems Integration consultancy services use a workshop approach in order to identify the business requirements and recommended architecture to enable a customized SDP design and a phased introduction plan. First steps include the consultancy approach based on the flexible. the partner strategy and the SDP budget. Each topic is supported by a strategy that aligns the individual component requirements with products from Nokia and Infrastructure view Management view Security view Functional view Contextual layer . The consulting phase is concerned with and addresses the question of “why are we doing this?” The conceptual layer is concerned with the definition of the problem domain that needs to be solved by the architectural solution. Nokia consultancy approach 8 . The key issue here is the unique combination of a topdown plan with bottom-up engagement. future-proof reference architecture that was outlined earlier. That plan will reflect the current network and IT environment. The consulting phase is concerned with and addresses the question “what are we going to do this with?” The following generic subjects are addressed: • Business positioning/requirements • Service evolution and Service expansion scenarios • SDP Architecture (gap analysis.

It provides a reference framework to map functions and services within the architecture and enables integration points and areas for functional reuse to be easily identified. 9 . Use Case Models Nokia Products SDP Architecture Model 3 Party Products rd Customer Products 2 1 3 SDF Component Model Generic Solution Design Model (e.g IMS) Customer Specific Solution Design Model (e.g IMS for Cust X) 4 Figure 5. It is a tool that is used to establish a common understanding between all parties about why and how the individual components of an SDP should be structured.White Paper third parties. Nokia SDP design model. The reference architecture should therefore be seen as a tool. In turn. decompose and co-ordinate the task of modelling the key systems. subsystems and core components and to identify the message flows between all elements of the proposed solution. it is not a rigid structure. everything is aligned within the reference architecture. And this unique concept also makes it possible to systematically identify. It can be used to define brand-new SDPs and to model and subsequently enhance SDPs.

It starts. This is done in order to establish an outline agreement on the key business criteria.e. i. The service delivery framework provides a logical representation of the whole service delivery environment. Thus. as this paper has shown. The reference architecture is then used to define a physical framework and establishes a common language and a common understanding between all parties involved during the consulting phase. The SDP decision can not be made from product perspective only. This makes it easier to establish a clear understanding of the individual roles and functions of each domain and how that functionality should be distributed and optimized. There is also a clear and compelling need to ensure that the SDP meets all business and technical goals. a concept that is used to position the key SDP domains within that end-to-end architecture. In turn. it is easier to reach agreement on identifying the key components and functions required to implement a service delivery platform. third party definition of SDP — one that reflects the fact that service delivery is an end-to-end process. both now and in the future. Once established. We therefore developed a well-defined evaluation and definition process. the framework is actually a reference model used to define a customized instance and its implementation. Products are introduced at the end of the process and functionality can now be assessed on the basis of the business goals that were defined and agreed at an earlier stage. The starting point has to be the business objectives: the SDP must map to the operator’s strategy.White Paper Summary This white paper used a broad. this indicates the need for an end-to-end architecture/service environment. it must not determine that strategy. with the value chain. 10 . it must be based on standards and open APIs.

and the customer assumes full responsibility when using it. This document and the product it describes are considered protected by copyright according to the applicable laws. The document has been prepared to be used by professional and properly trained personnel. . Nokia's liability for any errors in the document is limited to the documentary correction of errors. All rights reserved. The methods and procedures mentioned in this document cannot be considered binding unless so defined in the agreement made between Nokia and the customer. explain issues which may not be covered by the document. Copyright © Nokia 2005. Nokia has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. and they are mentioned for identification purposes only.White Paper The information in this document is subject to change without notice and describes only the service concept in the introduction of this documentation. Other product names mentioned in this document may be trademarks of their respective companies. that might arise from the use of this document or the information in it. Nokia welcomes customer comments as part of the process of continuous development and improvement of the documentation. if necessary. This document is intended for the use of Nokia's customers only for the purposes of the agreement under which the document is submitted. Nokia will. Nokia WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES. INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES). NOKIA logo is a registered trademark of Nokia Corporation. and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia.

Nokia code: 11261.Copyright © 2005 Nokia.Box 300 FIN-00045 Nokia Group.O. Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Other product and company names mentioned herein may be trademarks or trade names of their respective . Finland Tel. Contra /02/2005 Nokia Corporation Networks P. +358 7180 08000 Fax: +358 7180 24287 All rights reserved.