whitepaper service delivery

8/3/2019 Whitepaper Service Delivery

1/12

Service Delivery Platforms

White Paper


2/12

2

White Paper

Executive summary 3

Operator challenge 4

Value chain 4

Service delivery framework 5

Reference Architecture 6

Service integration 7

Consultancy approach 8

Summary 10

Contents


3/12

The future of the wireless industry is predicated

on the delivery and management of value-

added services. The market for these services

is enormous, with aggressive marketing cam-

paigns positioning mobile multimedia content

at the heart of today's lifestyle. For conven-

ience 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 constitutean 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 mobilitypremium, operators are looking for new

opportunities to enhance their service offer-

ing 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 IP-

based services. This is a key requirement

since it reduces service deployment costs

and shortens development times.

Security. Open IP architectures are disrup-

tive since they dissolve the barriers that

currently separate networks. Service

providers need to build a service machin-

ery, 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 value-

added 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 SDPchallenge 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.

3

White Paper

Executive summary


4/12

4

White Paper

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 operatorsthis 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 servicesat 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,

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 marketwhat the market clearly needs and for which

it is prepared to pay, i.e. a portfolio of added-

value 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 efficientdelivery 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-size-

fits-all model. By definition it has to beover-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 theissues 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.

Operator challenge


5/12

5

White Paper

Service deliveryframework

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 cost-

efficiently

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 value-

added 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

AccessNetwork

DeliveryChannel

Terminal ServiceLogic

ValueChainMgmt

Content

Figure 1. : The service delivery value chain.

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 all-

important 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. Thereare 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.


6/12

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 differingblend 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 encapsu-lation are required in order to support the

key business drivers and business considera-

tions. 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 compo-

nents 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

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

help optimize the overall architecture by

providing reusable services for all functional

areas, thereby significantly reducing theoperational 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.

6

White Paper

Figure 2. The Reference Architecture.

Reference Architecture

Content/Service Provider

End-User / Terminal

Service Logic Value ChainMgmt

DeliveryChannel CommonServices

Integration and Capability Exposure

Operationa

lManagement

System C

ustomerCareand

Billing

Primary SDF scope External Integration Points


7/12

7

White Paper

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.

Service integration

Common Services

The Ability to add andremove Common Serviceand physicalconfigurations

Value ChainMgmt

Delivery Channel

The Ability to ChangeDelivery Channelconfigurations andadd new channels

Service Logic

The Ability to add andremove servicesdynamically usingmultiple possible hosts

Integration and Capability Exposure

Dynam

icInterfave

Discovery

Channe

sGlomm

ing

Each Ability needs to be able to operateindependently and with the minimumof management intervention

Interface

Authorization

An

dAccess

Contro

l

Interface

Loa

d

Sharingan

dFa

ilover

Figure 3. Service integration impacts all four domains


8/12

8

White Paper

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, wide-

ranging 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 enablea 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 layeris 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 layeris 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.


addresses the question of what are we

going to do?

The logical layeris concerned with the

description of the functional componentsthat 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 layeris concerned with the

description of the technologies, interfaces

and products that will be used to construct

a system founded on the logical architecture.


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 top-

down 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

Consultancy approach


9/12

9

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 functionalreuse 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

3rd

Party Products Customer Products

SDPArchitecture

Model

SDFComponent

Model

Generic SolutionDesign Model

(e.g IMS)

Customer SpecificSolution

Design Model(e.g IMS for Cust X)

12 3

4

Figure 5. Nokia SDP design model.


10/12

10

White Paper

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 fromproduct 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 providesa 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 areintroduced 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.

Summary


11/12

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 theprior 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 allreasonable 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 betrademarks of their respective companies, and they are mentioned for identification purposes only. Copyright Nokia 2005. All rights reserved.

White Paper


12/12

Nokia Corporation

NetworksP.O.Box 300

FIN-00045 Nokia Group, FinlandTel. +358 7180 08000Fax: +358 7180 24287www.nokia.comCo

pyright2

005Nokia.

Allrightsreserved.

NokiaandNokiaConnectingPeopleareregisteredtrademarksofNokiaCorporat

ion.

Otherproducta

ndcompanynamesmentionedhereinmaybetrademarksortradenamesoftheirrespectiveowners.

Nokiacode:112

61,

Contra/02/2005

whitepaper service delivery

Documents