White Paper

Service Delivery Platforms

 White Paper

Contents

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

2
White Paper
Executive summary
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 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 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 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.
3

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 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 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.
4
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 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
operator’s 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 operator’s 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.
White Paper
Value chain
The value chain is a business concept: it is
used to define the operator’s 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 operator’s 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 operator’s 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 operator’s IT department and typically
includes the operator’s portal/home page,
White Paper
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
SDP Scope
Terminal Access Delivery
Network
Channel
Figure 1. : The service delivery value chain.
claiming that the result will be a service
delivery platform cannot meet this all-
important objective.
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. 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.
Value
Service Chain Content
Logic
Mgmt
Service delivery
framework
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.
5
 White Paper

Reference Architecture

The Reference Architecture defines the

framework and establishes a common Content/Service Provider

Operational Management System

language and a common understanding

Customer Care and Billing

between all parties involved during the
consulting phase. Once established, it is Service Logic Value Chain
easier to reach agreement on identifying the Mgmt
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 Integration and Capability Exposure
implementation. The implementations are
different due to the specific and differing Delivery Common
blend of business and technical challenges Channel Services
— 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 End-User / Terminal
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
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
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.

6
White Paper

Service integration

The market expects operators to offer

a comprehensive service portfolio and to
Each Ability needs to be able to operate
add new services at regular intervals: independently and with the minimum
of management intervention
services that can be self-provisioned via the

Sharing and Failover

Web. The Integration Framework and
Service Logic Value Chain

Interface Load
Capability Exposure is the layer that binds
everything together. However, this layer has The Ability to add and Mgmt
to be dynamic so its functionality must: remove services
• Allow the delivery channel infrastructure to dynamically using

Channes Glomming

Dynamic Interfave
multiple possible hosts
be changed without affecting the services

Discovery
• Enable new common services to be added
automatically
Integration and Capability Exposure

Interface Authorization
• Allow value added services to be managed
Delivery Channel Common Services

And Access Control

and changed dynamically
• Provide security between the functional The Ability to Change The Ability to add and
groups, particularly between the service Delivery Channel remove Common Service
logic (which is not in the trusted domain) configurations and and physical
and other functions
add new channels configurations
• Provide load sharing and failover facilities
• Enable interface abstraction, e.g. automatic
allocation of the delivery channel based
upon the subscribers’ profile. Figure 3. Service integration impacts all four domains

7

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 today’s marketplace.
It’s 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 enable
a customized SDP design and a phased
introduction plan. In line with industry
trends, these workshops utilize a four layer
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
8
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
White Paper
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 operator’s 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
White Paper

third parties. In turn, everything is aligned

within the reference architecture. Use Case Models Nokia Products

The reference architecture should therefore

SDP
be seen as a tool; it is not a rigid structure.
Architecture
It is a tool that is used to establish a common
Model
understanding between all parties about
why and how the individual components of rd
3 Party Products Customer Products
an SDP should be structured. It provides
a reference framework to map functions and
services within the architecture and enables 2 1 3
integration points and areas for functional
reuse to be easily identified.

It can be used to define brand-new SDPs SDF

and to model and subsequently enhance Component
SDPs. And this unique concept also makes it Model
possible to systematically identify, Customer Specific
decompose and co-ordinate the task of Generic Solution
Design Model Solution
modelling the key systems, subsystems
(e.g IMS) 4 Design Model
and core components and to identify the (e.g IMS for Cust X)
message flows between all elements of the
proposed solution.

Figure 5. Nokia SDP design model.

9

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 operator’s
strategy; it must not determine that
10
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
White Paper
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.
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

Networks
P.O.Box 300

www.nokia.com
Nokia Corporation

Fax: +358 7180 24287

Tel. +358 7180 08000
FIN-00045 Nokia Group, Finland