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

White Paper

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

White Paper

Operator challenge
Many operators face declining profitability through constant competition in the voice market, the largest part of their revenue stream, so there is an on-going need to reduce OPEX. However, 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. 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, i.e. a portfolio of addedvalue services. And if new services are added at regular intervals, customers are far less likely to swap operators. 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. 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. It also entails choosing a service delivery platform that is exactly right for each organization. It is hard to overstate the importance of making the right SDP decision. 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. SDP is a term that means different things to different vendors and that makes comparisons and competitive evaluations particularly difficult. This is not an issue that can be avoided. Matching market expectations is clearly impossible in a first-generation infrastructure based on stand-alone, vertical services. Adding more service silos will only result in a service architecture that is even more complex. An alternative approach is to implement an all-embracing Mega service delivery platform that provides a pre-defined range of services and features. Nokia does not believe in the validity of this one-sizefits-all model. By definition it has to be over-engineered and therefore incorporate functionality that may not be required. The only way to match market expectations is to enable the service delivery functionality and make it an integral part of the network operators delivery process. Thus, a brand-new service delivery concept is clearly required. In fact, service delivery is such an important, wide-ranging issue that Nokia needed to go back to first principles in order to ensure that all the issues are addressed. It starts with targeted consultancy and a methodology that includes a set of workshops designed to allow the operators staff to engage at a topic level and bring their specialized skills to the table. 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. And it comes by taking a holistic, end-to-end view of the service environment.

Value chain
The value chain is a business concept: it is used to define the operators business requirements. The chain starts with the terminal, which may be a subscriber or an electronic consumer/agent. Access networks, both wireline and wireless, allow terminal entities to access the services provided within the service delivery environment, which encompasses four main domains. The Delivery Channel provides the transport mechanisms for the service. In most operators this domain is owned by the network part of the organization. Standards bodies normally define interfaces and functions in this domain. Service Logic functions include the process flow for the service. In the past ownership of the service would be the same as that of the delivery channel (traditional IN, peer-to-peer messaging) or it would be the responsibility of the network operators IT department (hosted content, media push). However, 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. Thus, facilities must be provided in order to allow these external service providers to seamlessly integrate with the operators customer care and billing environment. Value Chain Management provides the functionality needed to manage the relationships between the end-user, operator, content publisher and service providers. This functional area is normally owned by the operators IT department and typically includes the operators portal/home page,

White Paper

Service delivery framework

content management, content adaptation, and service discovery, along with service/user portfolio and personalization parameters. 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. The service delivery value chain still applies when services and content are hosted on mobile terminals. SDP should provide a complete ecosystem for the rapid deployment, provisioning, execution, management and billing of value added services. That statement came from the Moriana Group and it underlines the importance of addressing business requirements via an end-to-end architecture, i.e. one that covers the whole delivery chain. Focusing on one domain and then claiming that the result will be a service delivery platform cannot meet this allimportant objective. Meeting an operators business requirements entails a clear understanding of the individual roles and functions of each domain and how that functionality should be distributed and optimized. For example, a key functional requirement for the delivery channel is the ability to charge for the service regardless of the source. There are obvious differences between a legacy, hosted service such as SMS and a third-party service that is accessed via the Web. This means that the charging mechanism cannot easily be shared since the delivery channels are intrinsically different. 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. A framework can be a physical construction or a set of ideas, principles, agreements, rules that provide the basis or the outline for something that is more fully developed at a later stage. The service delivery framework that Nokia has created provides a conceptual representation of the whole service delivery environment (including both mobile and fixed networks). In a nutshell, it facilitates an outline agreement on the key business criteria before going on to create a tailored solution. 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. The framework also recognizes that connectivity between services is only one aspect of the problem. Equally important are: the management framework that surrounds the connectivity; the business processes such as self-care; the management of content and commercial relationships with other partners; and enabling robust security, authentication and billing. The framework must therefore be able to interface to and interact with external systems that provide this functionality.

SDP Scope
Value Chain Mgmt

Terminal

Access Network

Delivery Channel

Service Logic

Content

Figure 1. : The service delivery value chain.

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. Once established, it is easier to reach agreement on identifying the key components and functions required to implement a Service Delivery Platform. Thus, the framework is actually a reference model used to define a customized instance and its implementation. 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. Once this stage is reached the physical architecture can be designed and the solution implemented. The Reference Architecure is segmented into nine areas that are derived from the value chain proposition. These groups enable the necessary separation and encapsulation of the various system components within the proposed SDP. Separation and encapsulation are required in order to support the key business drivers and business considerations. Therefore the resulting platform is a holistic solution ensuring a consistent subscriber experience and seamless content delivery. This experience is provided by exposing the underlying network components that are suitable for a particular class of application in order to amalgamate, abstract and/or repackage the capabilities of the generic components, 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, thereby significantly reducing the operational and integration overheads. 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, including those hosted by the operator and delivered by third parties, can benefit from sharing the common services.

Primary SDF scope

Figure 2. The Reference Architecture. Mobile Alliance -OMA). Thus, the Integration Framework and Capability Exposure layer is the glue that binds everything together. Customer care and billing provides the functions that the host requires to manage the business. Operational management system provides the functionality that the host requires to manage the services. The common services domain was not identified in the value chain because the functionality provided by these services is transparent to the value chain. However, the real value of the common services is to

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. The Integration Framework and Capability Exposure is the layer that binds everything together. However, 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, particularly between the service logic (which is not in the trusted domain) and other functions Provide load sharing and failover facilities Enable interface abstraction, e.g. automatic allocation of the delivery channel based upon the subscribers profile.

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. Service integration impacts all four domains

White Paper

Consultancy approach
Network operators have widely different requirements, but they share the need for a pragmatic plan that will transform the current service delivery environment into one that matches their business strategy. That plan will reflect the current network and IT environment, the market position and services strategy, the partner strategy and the SDP budget. So far so good, but the SDP will also need to factor in the dynamics of todays marketplace. Its a tall order, but one that Nokia can deliver. SDP is such an important, wideranging issue that a clear methodology is needed in order to ensure that all issues are addressed. First steps include the consultancy approach based on the flexible, future-proof reference architecture that was outlined earlier. 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. In line with industry trends, these workshops utilize a four layer model that allows the different topic areas to be segmented for architectural separation, presentation and detailed analysis. The contextual layer is concerned with the definition of the business vision, business strategies and business challenges faced by the operator. It also identifies the key business cases that need to be addressed. 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. In broad terms, the business requirement that will be used to measure the compliance of any system derived from the architecture. 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. 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, interfaces and products that will be used to construct a system founded on the logical architecture. 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; new design) Business case analysis Phasing of SDP implementation. In addition, 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. Workshop topics currently include: Provisioning Charging Architecture optimization Service Provider interaction Lowering OPEX Systems integration. These workshops are tailored to address the scope of the overall problem or opportunity being analysed as well as the operators specific market situation. 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. The key issue here is the unique combination of a topdown plan with bottom-up engagement. 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 - Why? Conceptual layer - What?

Logical layer - How? Physical layer - What with?

Figure 4. Nokia consultancy approach

White Paper

third parties. In turn, everything is aligned within the reference architecture. The reference architecture should therefore be seen as a tool; it is not a rigid structure. 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. 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. It can be used to define brand-new SDPs and to model and subsequently enhance SDPs. And this unique concept also makes it possible to systematically identify, 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.

Use Case Models

Nokia Products

SDP Architecture Model

3 Party Products
rd

Customer Products

SDF Component Model Generic Solution Design Model (e.g IMS) Customer Specific Solution Design Model (e.g IMS for Cust X)

Figure 5. Nokia SDP design model.

White Paper

Summary
This white paper used a broad, third party definition of SDP one that reflects the fact that service delivery is an end-to-end process. In turn, this indicates the need for an end-to-end architecture/service environment. There is also a clear and compelling need to ensure that the SDP meets all business and technical goals, both now and in the future, i.e. it must be based on standards and open APIs. The SDP decision can not be made from product perspective only. The starting point has to be the business objectives: the SDP must map to the operators strategy; it must not determine that strategy. We therefore developed a well-defined evaluation and definition process. It starts, as this paper has shown, with the value chain, a concept that is used to position the key SDP domains within that end-to-end architecture. 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. The service delivery framework provides a logical representation of the whole service delivery environment. This is done in order to establish an outline agreement on the key business criteria. 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. Once established, it is easier to reach agreement on identifying the key components and functions required to implement a service delivery platform. Thus, 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.

10

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

Copyright 2005 Nokia. All rights reserved. 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 owners. Nokia code: 11261, Contra /02/2005

Nokia Corporation Networks P.O.Box 300 FIN-00045 Nokia Group, Finland Tel. +358 7180 08000 Fax: +358 7180 24287 www.nokia.com