IMS Architecture Overview
IMS Architecture Overview
IMS Architecture Overview
• Introduction
• IMS architecture
The presentation gives an overview of IMS architecture, including how it can help
telecommunication operators to achieve their goal of delivering advanced and
innovative services, with reference to Accenture International experiences within
incumbent, large and minor TelCos.
The main topics discussed are:
- IMS and Telecommunications Operators services
What is IMS and why it is important for TelCo
- IMS architecture
Elements, funtions, protocols and standards behind IMS
- IMS role in Operators technology roadmaps
How TelCo drives their business towards IMS solutions
- Accenture clients and IMS: some highlights
IMS experience and VoIP solutions in major Accenture clients
Copyright © 2007 Accenture All Rights Reserved. 3
Agenda
• Introduction
• IMS architecture
IMS
There are both business and technical drivers associated with IMS deployment, that
will bring benefits in service creation capabilities as well as in cost optimization
Increase
Revenue
Service
Copyright © 2007 Accenture All Rights Reserved.
Enhancements
6
IMS and Service Enhancements: main keywords
From To
• Access agnostic
VoIP IM Mail VoD …
User
DB Integrated services platforms
• Services independent Services
voice
video
data
IP
Control
• Open architecture
Transport
• Multi-device
• Vendor independent
Copyright © 2007 Accenture All Rights Reserved. IMS enabled 7
A controlled path from separate infrastructures to all-IP
and IMS
services tightly associated with specific IMS introduces a structured, layered architecture
terminals and access networks with “standardized” interfaces
layered networks with separated, non - clear path for integrating 3G world and “internet”
integrated service control layers ubiquitous access to all services from any
non-uniform user profiling device: IMS as access independent and all
IP pervasive but issues in guaranteeing QoS services developed on IMS are access agnostic
and charging for real-time, integrated uniform support for customer profiling, service
services access control and charging, integration with
Copyright © 2007 Accenture All Rights Reserved.
“legacy” networks 8
Agenda
• Introduction
• IMS architecture
The 3rd Generation Partnership Project (3GPP) is a collaboration agreement that was established in
1998 bringing together a number of telecommunications standardization bodies. Scope of 3GPP was to
produce globally applicable Technical Specifications and Technical Reports for a 3rd Generation Mobile
Systems based on GSM, GPRS and EDGE core networks and the radio access technologies.
The European Telecommunications Standards Institute (ETSI) is an independent, non-profit organization, whose mission is to
produce telecommunications standards for today and for the future. responsible for standardization of Information and
Communication Technologies (ICT) within Europe
Alliance for Telecommunications Industry
European Telecommunications Standards Solutions (ATIS) is a U.S.-based
Institute is an independent, non-profit organization that is committed to rapidly
organization, whose mission is to produce developing and promoting technical and
telecommunications standards for ICT within operations standards for the communications
Europe ETSI
Japanese Telecommunication
Asian Association of Radio
ARIB ATIS Technology Committee, with the
Industries and Businesses, to purpose of contributing to
conduct research & development standardization in the field of
on utilization, realization and 3GPP telecommunications by
popularization of new radio establishing protocols and
systems in telecommunications standards
and broadcasting. CCSA TTC
TTA (Telecommunications Technology
China Communication Standards TTA Association) is an IT standards organization
Association, to contribute to the that develops new standards and provides
development of information industry one-stop services for the establishment of IT
standards as well as providing testing and
Copyright © 2007 Accenture All Rights Reserved. certification for IT products 11
IMS layers and functions : overview
The resulting IMS architecture defines
elements and functions on three layers:
MAP
ISC SIP
OSA-SCS ISC IM-SSF
Si
Dh
SLF S-CSCF
Control Dx SIP
Layer Mw
Mg
SS7
SIP over IP
Sh Cx I-CSCF Mi
HSS BGCF MGCF SGW
DIAMETER DIAMETER Mj
Mw SIP Mr Mn
H.248/
M p Megaco
INTERNET
IP Core
UTRAN Network GGSN
GGSN MRFP MGW PSTN/
Fixed Network BRAS
PLMN
BRAS
DSLAM
DSLAM
Copyright © 2007 Accenture All Rights Reserved. 12
IMS Core Network Element : CSCF
The CSCF elements are responsible for SIP session control and implements the logics for the following
functions:
user authentication
call routing
controlling the generation of call detail records (CDRs) for accounting purposes
Each network will typically have multiple CSCFs of each type, allowing load sharing and supporting
increased reliability through the use of backup servers.
All the CSCF will use the session initiation protocol (SIP) as signaling protocol. Interaction with other
domains using different protocols are performed by dedicated elements which allow protocol translation.
A P-CSCF is the first point of contact for the IMS terminal, and performs
the following main functionalities:
forwards the registration requests received from the UE to the I-CSCF
forwards the SIP messages to the S-CSCF that administrate the user, whose address
is defined during the registation
forwards the request and the answers to the UE
The P-CSCF is assigned to an IMS terminal during registration, assigned either via DHCP, or in the
PDP Context, and does not change for the duration of the registration.
Sits on the path of all signalling messages, and can inspect every message
Authenticates the user and establishes an IPsec security association with the IMS terminal. This prevents spoofing
attacks and replay attacks and protects the privacy of the user.
Can compress and decompress SIP messages using SigComp, which reduces the round-trip over slow radio links
May include a PDF (Policy Decision Function), which authorizes media plane resources e.g. quality of service (QoS)
over the media plane. It's used for policy control, bandwidth management, etc ... The PDF can also be a separate
function.
Can be located either in the visited network (in full IMS networks) or in the home network (when the visited network is
not IMS compliant yet).
Some networks might use a Session Border Controller for this function.
its IP address is published in the DNS of the domain (using NAPTR and
SRV type of DNS records), so that remote servers can find it, and use it
as a forwarding point (e.g. registering) for SIP packets to this domain.
its IP address is published in the DNS of the domain (using NAPTR and SRV type of DNS records), so
that remote servers can find it, and use it as a forwarding point (e.g. registering) for SIP packets to this
domain.
I-CSCF queries the HSS using the DIAMETER Cx interface to retrieve the user location (Dx interface
is used from I-CSCF to SLF to locate the needed HSS only), and then routes the SIP request to its
assigned S-CSCF.
Up to Release 6 it can also be used to hide the internal network from the outside world (encrypting part
of the SIP message), in which case it's called a THIG (Topology Hiding Inter-network Gateway).
From Release 7 onwards this "entry point" function is removed from the I-CSCF and is now part of the
IBCF (Interconnection Border Control Function). The IBCF is used as gateway to external networks,
and provides NAT and Firewall functions (pinholing).
It is a SIP server always located in the home network. The S-CSCF uses
DIAMETER Cx and Dx interfaces to the HSS to download and upload user
profiles - it has no local storage of the user.
All necessary information is loaded from the HSS.
it handles SIP registrations, which allows it to bind the user location (e.g. the IP address of the
terminal) and the SIP address
it sits on the path of all signaling messages, and can inspect every message
it decides to which application server(s) the SIP message will be forwarded, in order to provide their
services
it provides routing services, typically using ENUM lookups
it enforces the policy of the network operator
there can be multiple S-CSCFs in the network for load distribution and high availability reasons. It's the
HSS that assigns the S-CSCF to a user, when it's queried by the I-CSCF.
The SLF expose Dx and Dh interfaces, which have the same syntax and semantic of the Cx and Sh
interfaces provided by the HSS.
The SLF does not perform any logic on its interfaces, but replies to the requestor with a REDIRECT
message, specifying the address of the HSS which is able to fulfill the request received.
Both the HSS and the SLF communicate through the DIAMETER protocol.
It is exploited for :
– Playing of announcements (audio/video)
– Multimedia conferencing (e.g. mixing of audio streams)
– Text-to-speech conversion (TTS) and speech recognition.
– Realtime transcoding of multimedia data (i.e. conversion between different codecs)
– An MRFP (Media Resource Function Processor) is a media plane node that implements all
media-related functions.
If the breakout occurs in the same network as the BGCF then the BGCF selects a MGCF
(Media Gateway Control Function) that will be responsible for inter-working with the PSTN,
and forwards the signaling to MGCF. Otherwise it forwards signaling to BCGF of another
operator network
The MGCF then receives the SIP signalling from the BGCF and manages the interworking
with the PSTN network.
Application Servers
The IM-SSF is the node in the IMS domain which provides inter-
working between the SIP session control and the Intelligent
Network of traditional networks.
OSA
Third Party IN legacy SIP
Compliant
Services Services Services
Services
CSE/
OSA AS\ OSA AS SIP AS
IN legacy
– ISC (between S-CSCF and OSA Gateway/IM-SSF/SIP AS) allows to receive/notify SIP messages from/to
the S-CSCF to realize the service session control
– Cx beetwen S-CSCF and HSS is used to retrieve/update the subscriber profile data
– Sh between HSS/OSA- Gateway/SIP-AS is used to retrieve/update the subscriber profile data related to
the service. The HSS is responsible for policing what information will be provided to each individual
application server.
– Si between HSS and IM-SSF is used to retrieve/update the subscriber profile data related to IN services
Copyright © 2007 Accenture All Rights Reserved. 24
Agenda
• Introduction
Registration
UE 1 UE 2
domain A
UE must register to the IMS domain.
I–CSCF
HSS
P–CSCF S–CSCF
I–CSCF
HSS
P–CSCF
UE 1 UE 2
IMS domain B
UE 3
Copyright © 2007 Accenture All Rights Reserved. 26
Example: Registration and Basic Call Flow
Session set up
UE in different IMS domain
UE 1 UE 2
IMS
The session origination procedures specify the
S–CSCF S–CSCF signaling path between the UE initiating a
domain A
session setup attempt and the Serving-CSCF
that is assigned to perform the session
origination service. This signaling path is
determined at the time of UE registration, and
I–CSCF remains fixed for the life of the registration.
HSS
P–CSCF S–CSCF
I–CSCF
HSS
P–CSCF
UE 1 UE 2
IMS domain B
UE 3
Copyright © 2007 Accenture All Rights Reserved. 27
Example: Registration and Basic Call Flow
Session set up
UE in the same IMS domain
UE 1 UE 2
IMS
The session origination procedures specify the
S–CSCF S–CSCF signaling path between the UE initiating a
domain A
session setup attempt and the Serving-CSCF
that is assigned to perform the session
origination service. This signaling path is
determined at the time of UE registration, and
I–CSCF remains fixed for the life of the registration.
HSS
P–CSCF S–CSCF
I–CSCF
HSS
P–CSCF
UE 1 UE 2
IMS domain B
UE 3
Copyright © 2007 Accenture All Rights Reserved. 28
Example: Call Flow with services :
Call Barring and Number Portability
User A initiates a call to a number that has been ported to an external network.
User A has the Call Barring service, which prevents him to call 1xx numbers, hence the S-CSCF triggers the
Application Server to apply the CB logic. The AS retrieves the profile associated to User A from the HSS,
perform the service logic, and sends back the message to the S-CSCF allowing the call.
• Introduction
• IMS architecture
• Applications deployed on ASs are the basic blocks used to develop services.
• Services can be provided directly by a single application or can be the result of the orchestration of
several applications, eventually hosted on different Application Servers.
• Application Servers are the execution environments for applications, providing framework facilities
such as protocols and interface support, database connections, security, monitoring and more…
Application Server
BSS i/f
NB i/f
BSS Presentation Interfaces
Charging
DB i/f
Service Logics
DB Connections
Layer
Performnance
Configuration
Conn Pools
Fault Mgmt
Libraries APIs
Assurance
Security
Data Layer
Execution Environment
OSS Data
Connectors
SB i/f
Protocols Listeners
Southbound systems
• Application Containers can be based on different paradigms, depending on the structure of the
application execution environment and on the technique used to convey messages between different
components inside the application server.
Two main execution environments types are currently exploited to develop application servers:
SLEE (Service Logic Execution Environment) architecture is based on an execution model with
application hosted as independent service building blocks (SBB).
Each SBB can be triggered and activated by one or more events, generated inside the SLEE
Interfaces are realized implementing Resource Adaptors, which manage listeners and protocols, and
are able to raise specific events when interrogated by network requests.
The SLEE environments manages the entire lifecycle of events, applying subscribe/notify and routing
rules between RAs and SBBs.
SLEE Container
This kind of service environment has been SBB SBB SBB SBB
specifically thought for TelCo operators, as
allows following features:
Event Dispatcher
Modular development of service logics
Events Collector
Easy combination of different Service
Block to provide convergent services
Resource Adapters can be added or Resource Resource Resource
extended without modifying the service Adapter Adapter Adapter
logics implemented inside SBBs
External system
Servlet Containers are execution environments which bind the execution of a service logic to the
receiving of a particular request.
Service Logic lifecycle is entirely managed by the environment
Requests are associated to service logics depending on the type of message received (servlet model)
Service Logics are activated synchronously with request elaboration
Combination of service logics is managed redirecting messages inside the container
Servlet Container
The servlet paradigm can be used
implementing adaptors for several protocols, Service Service Service Service
allowing the development of fast network
oriented services:
Service Logics are directly connected to Execution Execution Execution Execution
queue queue queue queue
network messages
Can manage queuing, overloading and
prioritization of requests Protocol Protocol Protocol
Protocols and interfaces can be added Listener Listener Listener
implementing new listeners
External system
• Introduction
• IMS architecture
The Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) is a
standardization body of ETSI, specializing in fixed networks and Internet convergence.
TISPAN is the ETSI core competence centre for fixed networks and for migration from switched circuit
networks to packet-based networks with an architecture that can serve in both to create the Next Generation
Network.
•This focus on fixed accesses together with the choice of using the IMS network in the core architecture led to
new requirements and to an evolution of the original IMS solution.
TISPAN and 3GPP are now working together to define a harmonized IMS-centric core for both wireless and
wireline networks, enabling new convergent accesses and services.
3GPP /
TISPAN
IMS
Wireless access Wireline access
AGW
AGW
The NGN standard functional architecture, defined by TISPAN, is composed by a “service layer”
and a “transport-layer” both based on IP.
•This subsystem-oriented architecture enables the addition of new subsystems over the time to cover new
demands and service classes. The architecture ensures that the network resources, applications, and user
equipment are common to all subsystems and therefore ensure user, terminal and service mobility to the
fullest extent possible, including across administrative boundaries.
NASS makes possible to expose towards upper-layer systems users presence informations and at the
same time apply policies to control network access based on varoius users profiles
• Introduction
• IMS architecture
IMS is going to play a key role in Operators technology context for controlling and enabling the
introduction of innovative/convergent services in an ALL IP environment
IMS is emerging as the de facto convergence model for fixed, mobile and enterprise telephony. IMS
will be used to keep control of the network while using IP technologies: Service and Control Layers
will be implemented using IMS architectures as a key: element to support both IP multimedia
sessions over heterogeneous media type.
IMS architecture will be used as “the” mean for obtaining fixed and mobile convergence (3GPP-
TISPAN): different IMSs for mobile and fixed networks will be integrated and merged into a
single infrastructure (e.g. single HSS –Data Base for all users)
Innovative and advanced Services (e.g. combinational ones) will leverage convergent IMS-enabled
Service Layer
IMS alone is not enough, it will be complemented with additional functional elements such as:
external interfaces, databases, enablers (presence, location,…), QoS server, media server, IMS-
enabled terminals
Service interconnections with legacy and consolidated platforms in the short term
and with non-IMS platforms will be needed to deliver the integrated experience that
users ask for.
Service interconnection
Control
Transport
PSTN IP PLMN
Service Orchestration
Service Control
Core Services
Control
Transport
PSTN IP PLMN
Copyright © 2007 Accenture All Rights Reserved. 45