Download - Whitepaper Service Delivery
-
8/3/2019 Whitepaper Service Delivery
1/12
Service Delivery Platforms
White Paper
-
8/3/2019 Whitepaper Service Delivery
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
-
8/3/2019 Whitepaper Service Delivery
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
-
8/3/2019 Whitepaper Service Delivery
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
-
8/3/2019 Whitepaper Service Delivery
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.
-
8/3/2019 Whitepaper Service Delivery
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
-
8/3/2019 Whitepaper Service Delivery
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/3/2019 Whitepaper Service Delivery
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.
The consulting phase is concerned with and
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.
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 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
-
8/3/2019 Whitepaper Service Delivery
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.
-
8/3/2019 Whitepaper Service Delivery
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
-
8/3/2019 Whitepaper Service Delivery
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
-
8/3/2019 Whitepaper Service Delivery
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