Service Network An Introduction

1
Service NetworkAn Introduction
Andreas TorstenssonOperational Product
ManagerEricsson AB
2
Agenda
The need for a service layer
Building a service network
Service Network Framework
Common Directory
Common Provisioning
Single Sign-On
Application development
QA
3
Evolution from 2G to 3G

• Its all about services
• generating airtime and value added
  charging

4
Services beyond voice success factors
5
Architecture approach
Today Vertical Solutions
6
Service Layer
Applications Content
Service Layer
Control Layer
Connectivity Layer
7
Operator challenges - examples

• Thousands of services will exist in parallel
• The service life-cycle might be as short as just
  a couple of days
• Short time to deploy new services will become a
  strong competetive advantage.
• Ensure compatibility between applications - and
  simplicity for the user
• Minimize costs through common use of functions
  and enablers

Operators need a killer environment rather
than killer applications !!
8
Applications
Multi-Service Network
Single-Service Network

GSM
GSM
WCDMA
End-users
9
New actors
10
Whats on an operators mind?
11
Agenda
The need for a service layer
Building a service network
Service Network Framework
Common Directory
Common Provisioning
Single Sign-On
Application development
QA
12

• Magnitude of services
• Short service life-cycles
• The ability to quickly replace old services with
  fresher ones decides if you keep your customers
• Many service providers
• Tough competition

13
We need to

• Describe an open architecture of co-operating
  systems
• Apply open Industry Standards
• Define Common functions
• Define Reusable guidelines

14
Building a service network

• Building a service network by just adding new
  features to existing architecture will not do the
  trick
• A lot of effort must be put in defining a good
  architecture to get good scalability and
  availability
• The mindset must be thousands of services and
  millions of users in a dynamic environment
  changing every day
• More and more operators are looking for
  multi-national service networks which puts even
  higher requirements on the architecture

15
Agenda
The need for a service layer
Building a service network
Service Network Framework
Common Directory
Common Provisioning
Single Sign-On
Application development
QA
16
Service Network Framework (SNF)The Ericsson
architecture for service networks
SNF
17
Service Network Framework (SNF)The Ericsson
architecture for service networks

• High Scalability
• High Availability
• Manageability
• Standards alignment
• Openness
• Interoperability
• Security
• Flexibility

SNF
18
Definition Service Network Framework (SNF)
The Ericsson solution for
An Architectural Framework consisting of
Reusable Designs for Products and Solutions in
the 3G Service Layer.
19
What SNF is NOT

• NOT a Sales Object
• But the know-how
• NOT a way to lock out competitors
• But a way to define an interface
• NOT a secret
• But a way to share vision with the operators
• NOT another standard
• But a way to apply the right standard to the
  right problem

20
Standard Problems solved

• Single Sign On
• Common Provisioning
• Common OM
• Common Online Charging
• Self-Provisioning
• Integration of legacy

21
Central Entities

• The systems delegate the responsibility for
• Provisioning
• Management (Alarm,Performance,Configuration)
• Charging
• Authentication, Authorization
• to a Central Entity.

22
Combine systems through standardized open
protocols
SNF compliant Systems are building blocks.
Building blocks provide services. Services
are realized by a protocol and its semantics.
E.g. LDAPv3 and the SNF Data model.
23
SNF System Type
Services Provided
Services Consumed

• User Provisioning1
• Fault Report
• Performance Manage
• Manage Configuration

• CAI, CAI-3G, LDAP
• SNMP
• SNMP
• SNMP, HTTP, CLI

• LDAP
• Diameter
• Parlay
• Diameter,
• FTP
• RADIUS Accounting

• SCR Register2
• Diameter Credit Control3
• Parlay Charging4
• CDR Charging5

1,2 Required only if SNF System
hasuser/subscriber data that must be provisioned
3, 4, 5 Required only if SNF System has the need
to charge
24
SNF Deliverables
SNF Overview
CSNA Definitions
SNF Architecture
The documents filled in red are
Reference documents.
Detailed Descriptions (Reference Library)
System Development Guidelines
25
Common functions
..
Enablers
Common Provisioning
Common Single-Sign-On
Common OM
Charging Integration
Application Integration
Scalability RedundancySecurity Manageability
26
Product mapping
MMS
Positioning
Streaming
Browsing
..
Enablers
Common Provisioning

Common Single-Sign-On

Common OM

Charging Integration

Application Integration

IP-Infra/ MPBN
Scalability RedundancySecurity Manageability

27
Product mapping example Provisioning(Provisioni
ng is the handling of all end-user related data
in the network)
Business need
SNF central entity
SNF central entity
New business models Self provisioning Customer
expecations
SNF rules SNF guidelines
Existing functionality (legacy)
Common Provisioning
EMA
CPE
Ericsson Multi Activation
Central Provisioning Entity
28
Agenda
The need for a service layer
Building a service network
Service Network Framework
Common Directory
Common Provisioning
Single Sign-On
Application development
QA
29
Common Directory Business Problem

• Challenges today
• User has several identities (e.g. e-mail,
  MSISDN, SIP-URL)
• Duplication of Configuration and User data
• Grouping of services done by implementation
• Difficult to introduce new capabilities from
  existing services
• Massive scaling in case of success
• Evolution

30
SNF data model

• A global data model with loose coupling to
  affiliate data models.
• The global data model contains references to the
  affiliate data models

User Information Model
A
B
C
31
Some benefits

• Existing Data Models neednt be adapted to the
  SNF Data Model. Supports legacy integration.
• The SNF Data Model remains relatively insulated
  from change as customisations and new
  implementations of affiliate models become
  available
• Differing Data Access Technologies can be
  retained in the affiliate data models
• Solution Architects may still adopt
  Affiliate-Much or Affiliate-Little architectures

User Information Model
A
B
C
32
Data in Common Directory
Which Users are registered ?
Which Mobile Internet Services are Available for
a user ?

• 4673xx, user_at_ operator
• 44865, user_at_operator
• ..

Common Directory

• Yellow pages
• Taxi call
• ..

Which Resources Are available for the user ?
What has the user chooses as his personal service
portfolio ?

• MPC 1
• CS Access in DK
• .

33
Agenda
The need for a service layer
Building a service network
Service Network Framework
Common Directory
Common Provisioning
Single Sign-On
Application development
QA
34
User and service provisioning
Customer care
Operator Business Systems
Operator telecom network
Service providers
End-user
35
Network without common provisioning

• Necessary to support of a wide range of
  interfaces and protocols
• XML/HTTP
• MML
• LDAP
• Corba
• and more...

• More issues to solve
• Changes in interfaces?
• Redundancy?
• Routing?
• New nodes?
• New interfaces?
• New protocols?
• Lead time to update CAS
• implementation after
• network change/upgrade

Hard to maintain
Core Network
Service Network
HLR
FNR
Applications
AUC
EIR
Enablers
36
Common ProvisioningOne single interface towards
all business systems
EMA
Prov. Manager
CD
Core Network
Service Network
HLR
FNR
Applications
AUC
EIR
Enablers
37
Common Provisioning Solution - Benefits

• End-user self-provisioning
• self provisioning stimulates service usage and
  lowers cost
• Lower operating expences (OPEX)
• minimize integration effort needed per
  personalized application to hours instead of
  weeks.
• efficient management of services
• Shorten time to service deployment
• Service portfolio can be adapted more often
  increase of attractiveness of operator portal

38
Interfaces CAI3G

• Based on the SOAP standard (XML/HTTP)
• Suitable for web service integration
• Easy integration by use of API
• Hiding network complexity
• Capable of managing complex data models
• Support for notification towards Business systems
• Advanced error handling

39
Business Support System

• CAI3G is an RPC-like interface.
• The focus is on an API level. The CAS system does
  not have to know the actual SOAP message that
  will be sent over the line.
• A CAI3G WSDL file is provided for easy
  integration.
• The WSDL file together with a SOAP client
  software will provide the CAI3G API.
• A wide range of SOAP clients for most programming
  languages and operating environments are
  available.
• Technology is fully inline with latest web
  service trends.
• Preferred technology among most operators and
  vendors.
• More and more tools supporting the web service
  technology is introduced on the market.
• Large community on the web

CAS
createSubscriber()
SOAP 3PP
CAI3G WSDL file
SOAP message (XML/HTTP)
Intranet / Internet
SOAP message (XML/HTTP)
Ericsson Multi Activation
SOAP 3PP
CAI3G WSDL file
createSubscriber()
CAI3G driver
40
Example Restaurant finder application
We want to build a service Restaurant finder,
which will use a Restaurant data service and a
positioning enabler to provide the end-user with
information about the closest restaurants
Restaurant Data
Restaurant finder application
1
2
41
Use case Deploy service
Flow of events
1. Install application software
SCR

• Register provisioning template in System
  Component Register (SCR)
• Meta information about the data model
• Definition of service dependencies
• Service instance information

Restaurant Data
Restaurant finder application
1
2
1
2
3
4
5
42
Service deployment and configuration
1..N
1..1
43
Example End-user activation
44
Example End-user activation (II)
45
Example End-user activation (III)
46
Example End-user service usage
47
Example End-user service usage (II)
48
Service life-cycleSupport for different business
models
49
Agenda
The need for a service layer
Building a service network
Service Network Framework
Common Directory
Common Provisioning
Single Sign-On
Application development
QA
50
Why Single Sign-On ?

• Today, many services and networks handle
  identities, authentication, authorization and
  sessions in their own way
• End-users are forced to handle disparate
  identities and authentication mechanisms
• Multiple authentication
• Unnecessary authentication signaling
• The Service Network Framework recommends common
  security services for authentication and
  authorization

51
Why is Single Sign-On needed?
Although new technologies like Broadband and GPRS
are available..
services are not used to full extent.
It has been proven that each new user
authentication necessary to reach a service
reduces its usage by 50.
52
User experience without Single Sign On
User-base
Users might give up when a new authentication is
required.
53
User experience with Single Sign On
100
User-base
Passwords elimintated. Direct access to
personalized services
54
What is Single Sign On?
Single Sign On (SSO) enables users to access
different services without authenticating at
each one.
For the end user, SSO simplifies access to
services. For mobile operators, SSO increases
traffic.
55
What is an AAA Server? a very important node
when building a SSO solution
Authentication Who is it? Identified by
username/password or MSISDN
Authorisation Where can I go? Policies define
services authorised for user

• Accounting What will it cost?
• Data collection for charging, auditing, usage
  information

56
Single Sign-On What it is ?
Central Authentication

• Single user authentication
• A user coming from any access path (CS, PS or
  Internet) needs to be authenticated only once to
  become authenticated to the SN.
• Transparent service authorization.
• Once the user has been authenticated to the SN,
  the user will be transparently granted the right
  to launch any of his/her SN subscribed services,
  possibly according to some policies.
• Session Management.
• Once a user has been granted to launch a service,
  the necessary user information is transparently
  made available to the granted service so it can
  start operation.

Central Authorisation
Central Session Management
57
Walled-garden SSO

• The walled garden model represents all the
  services that the operator is hosting
• In this model the operator apart from handling
  the subscribers identities, plays the role of the
  Service Provider (SP)

Walled-Garden model is the first step into the
identity management
58
Federated SSO
IDENTITY PROVIDER
SERVICE PROVIDER
SERVICES
SERVICE PROVIDER
SERVICES
A Federation is the group formed by an operator
(Identity Provider) and a number of service
providers that have business agreement for
providing services to their common user.
Federation increases the operator business
potential
59
What is Liberty Alliance?

• Liberty Alliance is a consortium of 160
  organizations working on to establish an open
  standard for federated network identity.
• http//www.projectliberty.org
• Ericsson and Liberty
• Part of the Liberty management board
• Participation on the first public Liberty IOP
  (RSA 2003, SF)

Ericsson is committed with Liberty Alliance
Project as part of the management board
60
Agenda
The need for a service layer
Building a service network
Service Network Framework
Common Directory
Common Provisioning
Single Sign-On
Application development
QA
61
Ericsson Mobility WorldWe support a quarter of a
million developers!

• Online support tools
• Newsletters
• Device support
• Application evaluation
• Developer Days
• Awards

• Ericsson Mobility World Developer Program

www.ericsson.com/mobilityworld
62
Ericsson Mobility Worldof value to developers

• Opportunities to register as Community members to
  find web-based information and development
  support
• Opportunities to join the Ericsson Associates
  program to benefit from special services and
  promotion activities
• Opportunities to become one of our Business
  Partners to be included in Ericsson solution
  offerings to operators

63
Ericsson Mobility WorldFor Community members

• Up-to-date information about whats
  happeningwithin the Mobile Internet arena
• Information on Mobile Internet technologies
  and related Ericsson products
• Web based tools and guides give opportunities to
  develop compatible applications and services

64
Ericsson Mobility WorldFor Ericsson Associates

• Access to technical news and early product
  information
• Access to pre-release development tools,
  prototype handsets and test labs
• Access to global marketing opportunities such as
  our online Application Catalog
• Access to services such as consulting services,
  testing services and training

65
Ericsson Mobility WorldFor Business Partners

• The business partner relationship is specific in
  each case, depending on company, application and
  requirement.
• Provides global and local opportunities to join
  Ericsson in activities for and with our
  Customers.

Business Partners
66
Any questions?