The service network framework—An architectural
blueprint for the service network
Andy Johnston, Åke Gustafsson, Anders Eriksson and Mike Slssingar
The emergence of the Mobile Internet has focused special attention on
the service network, which is where network operators can expect to
develop, launch and bill for new services in a streamlined way, tapping
valuable new sources of revenue. Service networks are complex multivendor, multi-technology environments defined by many different interfaces and standards. Consequently, numerous aspects need to be
addressed during the design stage if the service network is to deliver on
its promise. Some key drivers for development in the service network are
reduced costs and increased revenue.
The authors describe Ericsson’s service network framework and its
architectural approach to the service network.
The combination of mobility and the Internet is creating a new and powerful industry
that will deliver attractive, content-rich services to users on the move. However, delivering on the promise of the Mobile Internet
requires innovation and effort in every layer
of the network, including what is commonly called the service layer.
Being the proving ground for many new
services in development, much functionality resides in the service layer. This functionality is needed to ensure that services get
launched, billed for, and maintained in a secure environment. In the service layer, applications and content are separated from
underlying networks, the resulting services
being accessed by users from any device and
via any network.
The Ericsson reference architecture for
creating horizontally layered solutions in
the service layer (Figure 1) is called the service network framework (SNF). This is defined as an architectural framework that
consists of reusable designs for products and
solutions in the service layer.
BOX A, TERMS AND ABBREVIATIONS
3GPP
Third-generation Partnership
Program
BGW
Border gateway
BM
Business management
CAE
Central authentication entity
CAS
Customer administration system
CAZE
Central authorization entity
CCE
Common charging entity
CDS
Common directory system
CME
Central management entity
CN
Core network
CPE
Central provisioning entity
CSE
Central session entity
FW
Firewall
FWLB
Firewall load balancer
HE-VASP Home environment – VASP
HTTP
Hypertext transfer protocol
IETF
Internet Engineering Task Force
18
IMS
IP
L2SW
LAN
LB
LDAP
NM
O&M
RFS
SCR
SLA
SN
UE
UMTS
VASP
VLAN
W3C
IP multimedia system
Internet protocol
Layer 2 switch
Local area network
Load balancing
Lightweight directory access protocol
Network management
Operation and maintenance
Request for study
System component registry
Service level agreement
Service network
User equipment
Universal mobile
telecommunications system
Value-added service provider
Virtual LAN
World Wide Web Consortium
Ericsson believes that the use of a
standards-oriented and product-neutral reference architecture is instrumental in delivering well-designed service networks which
possess the set of technical qualities that is
required to efficiently, flexibly and reliably
deliver functionality in the service layer.
The SNF is designed to help operators to
create service networks that possess several
architectural qualities. For example, the service networks must be supportive of various
business models and processes. They should
also be horizontally layered with common
services available via open interfaces, and
have clear integration points with peer networks in an end-to-end service environment. Similarly, they must be modular, secure, scalable, available, manageable and
standards-compliant.
The service network
concept
Ericsson’s solutions in the service layer are
termed service networks. These are designed
using the SNF, which defines a service network as any collection of products and solutions that fulfills business needs in the service layer.
The emphasis in this definition is on fulfilling business needs while retaining particular architectural qualities in the resultant network. Ideally, the architectural
qualities foster a reliable, scalable, flexible
and cost-effective network solution at any
point in time during the evolution of the
network.
Creating service networks that fulfill the
business needs of the network operator
means satisfying the diverse needs and expectations of various stakeholders. Users, for
example, want simple, quick and inexpensive access to quality services. Network operators want to grow their business and increase competitiveness. Service providers
want to be premium suppliers of services to
as many users as possible. Application developers want to capitalize on the services of
mobile networks in their applications. Content providers want to increase their customer base and find new channels toward
existing customers. And Ericsson wants to
create quality service network solutions that
solve the business needs of its customers.
Network operators who deploy new services have long realized the value of deploying service networks with common architectures that foster common functions
and qualities. An important step in masterEricsson Review No. 1, 2003
ing the complexity of service network design entails applying reference architectures
of reusable patterns and clear concepts
which are based on industry standards and
are specifically designed for creating adaptable solutions.
The SNF provides architectural principles
for creating horizontally layered service networks. By drawing on the architectural components for common management, common
provisioning, common charging and other
common services, the framework supports
the shift from a vertically structured to a
horizontally structured service network.
Any system that adheres to the SNF architecture may be plugged into the framework
and benefit from common provisioning,
management, charging, and so on.
Application
Application
Application
Service layer
Control
Connectivity
Access
Access
Access
Figure 1
The service layer.
Architectural recipes
The SNF architecture is guided by a set of
architectural policies that are intended to
promote and conserve particular qualities in
the architectural framework itself. The policies deal with
• problem solving—the SNF solves real engineering problems;
• preciseness—the SNF is an abstract
framework but provides precise specifications;
• coherency—the SNF uses a coherent architectural framework throughout;
• protocol centricity—the SNF uses protocols as a basic currency for interfaces;
Content
provider
We want to find:
– new channels for our content
– new ways of reaching
our customers
– efficient ways of distribution
• standards orientation—the SNF embraces standards;
• modularity—the SNF emphasizes modularity throughout;
• openness—the SNF applies open interfaces, standards and technologies
throughout;
• product neutrality—the SNF is fully
product neutral; and
• independence of operating system and
programming language—the SNF is
fully independent of operating systems
and programming languages.
Application
developer
We want to find:
– new oppurtunities
– new markets and customers
– new features
Figure 2
Stakeholders of the service network.
Service
provider
User
Open interfaces
I want to have access to
all my services:
– anytime
– anywhere
– with any device
Personal
services
Solutions
designed
using SNF
Business
support
I want to establish new
sources of revenue through:
– many new services
– best offers to my customers
– efficient management
Multiple networks
Network
operator
Ericsson
We want to create highquality service network
solutions that solve business
needs and deliver end-user
value
Ericsson Review No. 1, 2003
I want to:
– reduce my cost
– increase traffic on my networks
– offer services on all networks
19
SNF domain view
SNF
structural view
SNF
SNF
system type view deployment view
SNF
data model view
SNF
tier view
SNF blueprint
Figure 3
Architectural views of the SNF.
Architectural views
The architectural framework of the SNF is
expressed using a set of architectural views.
Each view provides insight into a particular
architectural aspect. These views cover domain, structure, system type, deployment,
tier, data model and applied areas. Each view
works in concert with the other views to capture the architectural statements provided
by the framework and, over time, to enable
the addition of further statements.
Figure 4
SNF domain view.
Business management
(BM)
In addition, the architectural rules and
best practices, which are presented along
functional and qualitative lines, add support
in helping to apply the architecture and provide guidelines. These are held in the
SNF rule and SNF guideline catalogs respectively.
Domain view
The domain view describes an ideal boundary for the service network and defines how
Network management
(NM)
Client
(UE)
Internet
(IN)
Service network domain
(SN)
HE-VASP
20
Core network
(CN)
VASP
Ericsson Review No. 1, 2003
Service
contract
Compound
system
Compound system leve
l
Service
contract
System 1
Service
contract
System level
Component
Service
contract
Component level
System 2
Service
contract
Component
Service
contract
the service network interconnects and collaborates with other systems present in its
environment. Service networks are created
in the context of existing technical environments—that is, established groupings of
functionality interact with the business and
technical functions located in the service
network. The domain view captures and reflects the SNF view of the service network
environment and identifies the domains
with which service networks generally collaborate, making explicit the demarcation
and interfaces (reference points) between it
and other domains (Box B).
System n
Component
SW
component
SW
SW
Service
contract
Figure 5
SNF structural view.
may be provided from a compound system,
a system or a component.
Finally, within this view, the service contract is the description that specifies how a
service can be accessed. It is a combination
of the functionality in the service and the
protocol transfer mechanisms—for example, the lightweight directory access protocol (LDAP) in conjunction with a specific
LDAP schema as opposed to the protocol by
itself. The service contract is independent
of, and is not connected to, a specific compound system, system or component.
Structural view
The structural view provides a set of abstractions that architects can use for uniformly analyzing, modeling and expressing
SNF architectures. Uniform expression is a
necessity for creating solutions from a portfolio of reusable systems.
The highest level in the view is a compound system, which consists of one or more
systems. Much of the architectural guidance
in the SNF comes from what it terms the
system level, which defines a system as a logical and modular building block that provides certain services over established interfaces. A set of systems works as such a building block to deliver the services that are
available in a service network.
A service is an object that represents a collection of functionality accessed via protocols. The service is the SNF mechanism for
indicating interfaces. One or more services
Ericsson Review No. 1, 2003
Users of
services
Figure 6
SNF system and service.
Service contract
System
Provider of servi
ce
System
Service
System
Service
System
Service contract
21
ice>
>
ervice
umes-s
<cons
m
Syste
es-serv
<provid
ger
Mana
a>
on: is-
ializati
<spec
o
Telec
m no
de
ay
Gatew
CME
on
plicati
Ap
CPE
ler
Enab
CCE
tor
Bord
Media
er
ASUS
SCS
E
CSE
CAZ
CAE
CDS
SCR
Figure 7
SNF system type view.
System type view
The system type view introduces and specifies a recurring set of SNF systems, which
in essence, are a set of logical building blocks
for creating service networks. Each system
type (Box C) plays a special role in a service
network and is specified in terms of responsibility and service (interface).
Solution architects may thus refer to system
types as specifications for logical building
blocks within the service network (Figure 7).
Deployment view
Much of the SNF architecture rests on the
assumption that Internet protocol (IP) connectivity is present in the complete solution.
BOX B, DOMAINS OF THE SERVICE NETWORK
Service network (SN)
Provides a set of end-points that supports
each of the interfaces to adjacent domains.
The actual content of a particular service network domain varies depending on the set of
adjacent domains and the business needs.
Business management (BM)
Includes entities, such as customer administration systems (CAS), that the operator uses
to conduct traditional business management
activities—for example, network-wide subscriber management.
Network management (NM)
Includes the entities, such as network management systems, that the network operator
uses to conduct network-wide operation and
maintenance (O&M) tasks.
User equipment/client (UE)
Includes the entities that are expected to
access SNF-compliant products and solutions.
Internet (IN)
Represents the Internet services and qualities employed by the service network
22
domain. These are primarily Internet naming,
addressing and routing services and standards.
Core network (CN)
Contains the access and connectivity functions to the control layer of mobile networks.
The control layer controls calls and mobility
and contains the entities in GSM, GPRS,
UMTS and IP multimedia system (IMS) networks.
Value-added service provider (VASP)
The term value-added service provider indicates a business entity that provides services
to customers of the home environment (HE)
service provider. In terms of business and
technology, the VASP is only loosely affiliated
with the HE service provider.
Home environment VASP (HE-VASP
An HE-VASP is a VASP that has a service
level agreement (SLA) with the HE service
provider. The HE-VASP is strongly affiliated
in terms of business and technology with the
HE service provider (strong trust between
parties).
Ericsson Review No. 1, 2003
BOX C, SNF SYSTEM TYPES
SNF system
Serves as the root of the entire system hierarchy and provides a minimum set of interfaces
with which each system must comply. Every
system type must provide the services provided by the SNF system. The SNF system thus
serves as a template specification for every
system in the service network.
SNF application
Is responsible for providing services that are
consumed directly by users.
SNF enabler
Is responsible for providing services that are
consumed by application systems. The SNF
defines various enablers, such as the common
The IP network is a key aspect of the deployment environment for every system in
the service network.
The SNF deployment view provides guidance for ensuring that the IP network possesses a set of common services and qualities
on which every deployed system can rely.
Examples of common services include naming, addressing, routing, load-balancing,
firewall and security gateway services. Likewise, common qualities include performance, scalability, flexibility, security, and
high availability.
Figure 8 is a conceptual depiction of how
systems are deployed to, and make use of,
an IP network with various common services
and qualities.
Figure 9 shows an example of how a highly available IP network infrastructure can be
realized when systems are deployed onto vir-
directory system (CDS), which serves as a
central directory for user- and service-related
data that exposes a lightweight directory
access protocol (LDAP) interface.
SNF gateway
Is responsible for providing services that allow
systems to delegate protocol handling or conversion tasks. The SNF defines various gateways, such as the border gateway (BGW),
which supports single sign-on for HTTP traffic.
SNF manager
Is responsible for providing service networkwide services. The SNF defines various managers, such as the central provisioning entity
(CPE).
tual local area networks (VLAN). In this example, the application servers have been deployed on VLAN 1, whereas the gateways
have been deployed on VLAN N.
Tier view
The use of N-tier architectures is an accepted and proven approach toward partitioning
or organizing distributed computing architectures that require high levels of scalability and availability. The SNF recommends
that N-tier architecture should be employed
for organizing systems into scalable and
available solutions in a distributed computing environment.
The various tiers include client, presentation, business, integration, resource, and
data. The client tier is concerned with every
device that accesses systems or applications.
System
Figure 8
SNF deployment view.
System
System
<<uses / deployed to>>
<<uses / deployed to>>
<<uses / deployed to>>
SNF deployment environment
(IP network)
IP addressing
DNS naming
IP routing
IP network qualities
Load balancing
Ericsson Review No. 1, 2003
Firewall
Security gateway
23
IP backbone
FWLB
FWLB
FW 1
FW 2
Application
server 1
LB 1
LB 2
L2SW
VLAN 1
L2SW
VLAN 2
L2SW
L2SW
Enabler
Figure 9
High-availability deployment environment.
L2SW
VLAN n
Data model view
Figure 10
SNF tier view.
Client
Presentation
Application
Business
Integration
Integration
Resource
Enabler
Data
24
Data modeling is an important part of all
architectural efforts. The SNF data model
view specifies a uniform data model for userand service-related data and associated provisioning within the service network. The
SNF data model has been designed
• to support various business and service
life-cycle models;
• to enable designs that distribute userrelated data throughout the service network;
• to support and enable the SNF common
provisioning model;
• to support information on how services are
dependent on various systems; and
• to support extensions that accommodate
solution-specific requirements.
Deployment of the data model is generally
made through a directory server (system
type CDS) within an actual service network.
Although the data model can be used to
provide access to all user and servicerelated data in a service network, it does not
necessarily follow that all data is modeled
within the data model. Instead, data can be
referenced, which allows for easy integration
of existing, stand-alone data models, called
affiliate data models. This gives the solution
L2SW
architect room to design service networks
using the main data model and affiliate data
models.
Applied view
The applied view introduces the SNF blueprint, which provides a reference architecture that maps SNF system types, their interfaces, and collaborations to a single view.
Some typical and important collaborations
depicted in the SNF blueprint are
• the central provisioning entity (CPE),
CDS, and system component registry
(SCR)—to achieve common provisioning
of SNF systems that require provisioning;
• the central management entity (CME)
collaborating with all other SNF systems—to achieve common management;
• the common charging entity (CCE) collaborating with all other SNF systems—
to achieve common charging; and
• the border gateway (BGW), central authentication entity (CAE), and central
session entity (CSE)—to achieve single
sign-on for HTTP.
SNF rule catalog
The SNF rule catalog is a set of architectural rules presented along functional and qualEricsson Review No. 1, 2003
itative lines that serves to assist in applying
the architecture provided in the various SNF
views within product and solution development.
The SNF guideline catalog is a set of architectural best practices presented along functional and qualitative lines. Capturing architectural best practices that solve particular design problems in the service layer is
a key part of providing a useful and extensible reference architecture for the service
network.
SNF and standards
As one of its prime architectural policies, the
SNF embraces all standards from 3GPP,
IETF, W3C and others. This is central to its
strategy of maintaining the quality and utility of the framework architecture. As new
standards emerge, the SNF will evolve accordingly.
SNF and products
One of Ericsson’s prime strategies is to apply
the SNF in product and solutions engineering within the service layer. Products are
IN/UE/CN
domain
• DIAMETER CC
• Parlay
• DIAMETER DRT
• FTP
• RADIUS
CCE
NM
domain
• HTTP
• WAP
• POP
• RTSP
• SMS/MMS
• etc
APP
• DIAMETER CC
• Parlay
• DIAMETER DRT
• FTP
• RADIUS account
ASUS
The SNF provides solution architects with
a reliable architectural framework from
which to design and build competitive service networks. By depicting the service network through a series of easily accessible
views, designers can focus on the different
components within the network, highlighting areas where different elements can
be reused. This promotes greater openness,
optimization of resource utilization, and
greater economies of scale. Furthermore, it
allows designers to add functionality and
provide the overall solution with better performance, reliability, scalability and lower
costs of ownership.
CN/IN
domain
CPE
CN/IN
domain
CAE
SCS
• CAI
• CAI-3G
• LDAP
CDS
SCR
Uses
User
Figure 11
SNF data model view—extract.
Figure 12
SNF blueprint.
• HTTP
• RADIUS
BGW
• RADIUS
• SNMP
• HTTP
Use of services
Optional use of services
Ericsson Review No. 1, 2003
Conclusion
• CAI
• CAI-3G
CME
Service
Owns
The SNF is being evolved continuously. The
evolution is initiated via requests for study
(RFS), and work is carried out by an open,
collaborative community of workgroups
throughout Ericsson.
BM
domain
• SNMP
Contracts and pays
Subscriber
SNF evolution
SNF guideline catalog
BM
domain
thus designed and developed according to
this strategy, and product road map information is updated accordingly.
• RADIUS CC
CAZE
TNODE
• RADIUS CC
• LDAP
• HTTP
CSE
SNF system
Provisioning services
Management services
Charging services
25