1. IMS - enabling services, wherever the
customer and whatever the access
Duncan Mills - Vodafone
Stuart Walker – Leapstone
Sponsored by
2. Copyright 2005: MultiService Forum
Agenda
• From NGN to Fixed Mobile Convergence
• 3GPP and TISPAN overview
• The IMS Architecture
• Service Layer
• MSF and IMS
• Q&A
3. Copyright 2005: MultiService Forum
Where has NGN come from?
• In fixed line there has been a long term move towards a VoPacket
replacement for PSTN
• Driver has always been to reduce Opex in fixed line networks by
optimising bandwidth usage, whilst replacing outdated TDM
switching fabric.
– Compressed speech into less than 64kbps channels
– Further optimisation using VAD, Silence Suppression, AAL2 or IP multiplexing
yields significant reduction in core network bandwidth requirements.
• Drivers in 3GPP are more service related
– IMS is borne out of a need for ‘feature rich’ service
– Bandwidth requirements and their impact on capacity on the Radio interface
are actually worse than now.
• Now, IMS possibly provides the final piece in the business case
for NGN that makes the decision to move justifiable…
FIXED MOBILE CONVERGENCE
4. Copyright 2005: MultiService Forum
Different drivers = same end goal?
• If fixed wants OpEx saving and fabric replacement, but mobile
wants new services, how come the answer is the same
architecture for both?
– Both sides see the advantage to common, seamless services over
any access.
– IMS is defined in 3GPP so it has all the requirements for mobile
operators built in.
– SIP controlled voice is already available in fixed networks (particularly
for enterprise customers) so it extends existing technology.
• However, an IMS deployment supporting only voice does not
make sense
– Mobile has to go from no installed base to the full suite of available
service to be justifiable.
– IMS delivering single services (voice, PoC etc) is too expensive and
too limiting in the service set it facilitates
5. Copyright 2005: MultiService Forum
Who gains from Fixed and Mobile
convergence?
• Manufacturers
– Single development stream reduces R&D costs
– Next gen. networks = next gen. device = new revenue
streams – to deploy it, operators have to buy it!
• Has to be priced to make initial CapEx recovery for the
operator a short term deliverable.
• Operators
– Optimised ‘all IP’ network reduces OpEx
– Opens the fixed market’s customers to mobile operators and
vice versa.
– Next Gen Services = new revenue streams – to use it, the
customers have to buy it
• Has to be the right service set, priced to make the
services attractive to the customer
6. Copyright 2005: MultiService Forum
Who gains from Fixed and Mobile
convergence?
• End Users
– Common service set available regardless of device they use,
the location they are in or the access medium they are using.
– New services available – location based, blended interfaces
combining multiple inputs into a single presentation.
– Single sign on – one identity that goes everywhere with you.
BUT
The food chain runs from the End User upwards.
What services do they want? When will they buy them? At
what price point?
7. Copyright 2005: MultiService Forum
3GPP IMS - Architecture
I-CSCF
AS
OSA-
GW
IM-
SSF
MGCF
P-CSCF
GGSN
PDF
Gm
Sh
Cx
Si
ISC
Mw
Mw
Mi
Mb
Mj
Mr
Mm
Mb
Multimedia
Content
Mk
Legacy Bearer
ISUP or BICC
MRFC
UE
MRFP
Gm
HSS
BGCF
IM-MGW
Mg
SLF
Dx Dh
Gq
Go
Mp Mn
3GPP Profile SIP
Other Control Plane
Bearer
Legacy protocol
S-CSCF
8. Copyright 2005: MultiService Forum
TISPAN – Top Level Architecture
Taken from TISPAN WI02007 (Overall Functional Architecture)
Other
net
works
Other
subsystems
Core IMS
PSTN/ISDN
Emulation
subsystem
Customer
Premises
Equipment
Service Layer
Transport Layer
Transfer Functions
Resource and
Admission Control
Subsystem
Network
Attachment
Subsystem
Applications
User
profiles
9. Copyright 2005: MultiService Forum
TISPAN – IMS Core
Taken from TISPAN WI02029 (Functional Architecture IMS)
Other
IP
Networks
IP Transport (Access and Core)
T-MGF
I-BGF
AS
UPSF
P-CSCF
I/S-CSCF
BGCF
SLF
Charging
Functions
IWF
UE
« Core IMS»
Mw
Mw/Mk/Mm
Mr
Mg
Mj
Mi
Mp Mn
Gm
Gq
ISC
Cx Dx
Dh
Sh
Ic
Rf/Ro
Rf/Ro
Ib
Ia
Id
PSTN/ISDN
SGF
MRFC MGCF
MRFP
Resource and Admission Control Subsystem
Network
Attachment
Subsystem
If
Ie
Mw
IBCF
Mk
Mk
10. Copyright 2005: MultiService Forum
TISPAN NGN mapped on to 3GPP IMS
+TISPAN add ons
I-CSCF
AS
OSA-
GW
IM-
SSF
MGCF
P-CSCF
GGSN
PDF
Sh
Cx
Si
ISC
Mw
Mw
Mi
Mb
Mj
Mr
MRFC
UE
MRFP
Gm
HSS
BGCF
IM-MGW
(T-MGF)
Mg
SLF
Dx Dh
Gq
Go
Mp Mn
S-CSCF
SGF
I-BCF
I-BGF
IWF
PSTN/ISDN
Other IP
Networks
IMS Core
Transport
NASS
Applications
RACS
CLF, UAAF, PDBF, UPSF
SPDF
A-RACF, SPDF
L2TF, RCEF, AMF
None of these functions are
included in the 3GPP architecture
RACS
11. Copyright 2005: MultiService Forum
3GPP IMS applicability to NGN
• In R6, 3GPP IMS has been made ‘Access Independent’
– the technology used to transport SIP messages to the edge of
the IMS network does not affect the functionality within the
IMS network itself.
• This allows IMS to be applied to any
form of Access technology that is
capable of transporting SIP control
messages to the P-CSCF
– WLAN, DSL, Cable Modem, FTTx,
Satellite, Broadband Wireless all become
irrelevant – all that matters is SIP
presentation to the P-CSCF.
– Only aspect of Access that is relevant is
User Equipment capability and QoS.
P-CSCF
I-CSCF
MRF
MGW
MGCF
IMS
S-CSCF
SIP Application
Servers
SIP Application
Servers
HSS
13. Copyright 2005: MultiService Forum
IMS as a common ‘middleware’ layer
MRF
IMS Core
RNC
MSC(Server)
SGSN
GGSN
CN
MGW
BSC
UMTS/GPRS
SIP Application
Servers
P-CSCF
I-CSCF
S-CSCF
HSS
SIP Application
Servers
SIP Application
Servers
IMS Applications
MGCF
BGCF
MGW
VoIP Interworking
Elements
IP Bearer Network
14. Copyright 2005: MultiService Forum
IMS Nodes (1/2)
Database Elements
– HSS (Home Subscriber Server)
– SLF (Subscription Locator Function)
IMS Control Elements
– CSCF (Call Session Control Function)
– S-CSCF (Serving CSCF)
– P-CSCF (Proxy CSCF)
– I-CSCF (Interrogating CSCF)
Control Plane Interworking Elements
– MGCF (Media Gateway Control Function)
– BGCF (Breakout Gateway Control Function)
– SGW (Signaling Gateway)
IM-SSF
I-CSCF
MRF
MGW
MGCF
HSS
CSE(SCP) SIP Application
Servers
OSA-SCS
sgw
OSA Application
Server
S-CSCF
P-CSCF
BGFC
15. Copyright 2005: MultiService Forum
IMS Nodes (2/2)
IM-SSF
I-CSCF
MRF
MGW
MGCF
HSS
CSE(SCP) SIP Application
Servers
OSA-SCS
sgw
OSA Application
Server
S-CSCF
P-CSCF
BGFC
IMS Service Elements
– AS (Application Server)
External Service and Service
Interworking Elements
– OSA Elements - SCS (OSA
Service Capability Server, OSA
Framework, OSA Application
Server
– CAMEL elements - IM-SSF (IP
Multimedia Switching Service
Function), CSE (CAMEL
Service Environment)
Resource Elements
– Media Resources Function
(MRF)
Media Interworking Elements
– MGW (Media Gateway)
16. Copyright 2005: MultiService Forum
Benefits of a SIP control plane
• SIP is an end-to-end signalling protocol used to
establish, modify and tear down IP sessions
• The IMS nodes can remain in this SIP signalling
path throughout a session, ensuring that the
network is always aware of the service:
– Allowing the network to control the QoS of the bearer
– Allowing the network to invoke rich services on behalf of
the user
– Allowing for traditional and new charging models (e.g.
duration-based, A-party pays, A-party pays for the
voice, B-party pays for the video etc)
17. Copyright 2005: MultiService Forum
“So what ?”- says the subscriber
Infrastructure with no clear application….. this wouldn’t be the first time
18. Copyright 2005: MultiService Forum
Service Co-ordination
Service Orchestration
Service Brokerage
Service Control
IN with the benefit of hindsight
19. Copyright 2005: MultiService Forum
SIP based service orchestration –
Service Velocity and Service Agility
Penetration
(number of subscribers using service)
Duration
(active
service
lifetime)
Traditional
Telco
Services
Short Lived
Services
Niche Market
Services
Service Velocity – new
applications and services
to market quicker to
address the short lived
service market
Service Agility – flexibly
bundle applications into
customer products to
address niche subscriber
markets
New market – economically
realizable through faster and
more flexible service layer
20. Copyright 2005: MultiService Forum
IMS Service Orchestration Model
S-CSCF
Parlay App
gsmSCF
ISC
ISC
ISC
CAMEL OSA API
OSA SCS
IM-SSF
SIP Application
Server
Mw
P/I CSCF
HSS
Cx
Sh
Si
MAP
Session Control
Service Orchestration
Service Logic
Service Interaction Management
S-CSCF - Subscriber service profile
pulled from HSS at Registration time.
Multiple profiles per subscriber (profile
per alias)
Profile is a list of priority ordered
services point triggers SPT.
SPT = boolean expression using
SIP Method
SIP Headers and Contents
Session Case
SDP contents
Service Interactions handled through
a SCIM function, depicted as part of
the SIP AS although not really
defined.
Service profile updates pushed to S-
CSCF from HSS.
21. Copyright 2005: MultiService Forum
MSF R2 Service Orchestration Model
Call Agent
Service Broker
Parlay App
IF 9
IF 9
IF 9 IF 11
Parlay / Parlay X
Gateway
Service Logic
Gateway
SIP Application
Server
IF 7
Session Control
Service Orchestration
Service Logic
Service Interaction Management
ParlayX App
IF 12
Other Application
Environments
Call Agent Invokes Service Broker
on originating and or terminating
side of call. Call Agent can apply
embedded service logic before
and after invocation of Service
Broker.
Service Broker engaged set of
priority ordered applications on
seven ‘trigger’ conditions
(oCallAttempt, oBusy, oNoAnswer, oHangup,
tCallAttempt, tBusy, tNoAnswer)
Conflict resolution / Interaction
handling implied but not defined.
Permit multiple applications per
link in SIP chain for efficiency.
22. Copyright 2005: MultiService Forum
Shared Service Data
Diameter
Sh
Diameter
Sh Diameter
Sh
HSS
Shared Network
Database
Buddy Lists
Address Books
Prepaid Balance
etc
Application
Servers
HSS provides a shared network data repository
allowing applications to share subscriber data.
In multi-HSS deployments, Dh interface to SLF
is used to locate correct HSS for subscriber.
Sh interface (Diameter) - operations
Sh-Pull (read data)
Sh-Update (modify data)
Sh-Subs-Notify (request notification of data change)
Sh-Notify (notification of change)
Defined Data Sets
Repository Data – opaque data, network defined
IMS Public Identity
IMS User State
S-CSCF Name
Initial Filter Criteria
Location Information
User State
Charging Information
MSISDN
23. Copyright 2005: MultiService Forum
Parlay and ParlayX
Parlay X API’s
Common
Third Party Call
Call Notification
Short Message
Multimedia Messaging
Payment
Account Management
Terminal Status
Terminal Location
Call Handling
Audio Call
Multimedia Conference
Address List Management
Presence
Parlay API’s
Framework
Call Control
Generic
Multi-party
Multi-Media
Conference
Content Based Charging
Terminal Capabilities
Presence and Availability
Policy Management
Data Session Control
Account Management
User Interaction
Mobility Management
Generic Messaging
Multimedia Messaging
Address List Management
Presence
Network Elements
Parlay Gateway
Parlay X Web Services
Parlay
Applications
Parlay X
Applications
Network Protocols
(e.g. SIP, INAP, etc)
Parlay API’s
Parlay X APIs
24. Copyright 2005: MultiService Forum
SIP AS
Multiple mechanisms exist for creating SIP applications.
SIP-CPL – Call Processing Language. An XML based scripting language for controlling call services.
Designed to be implemented on either network servers or user agent servers via a lightweight CPL
interpreter. Limited but safe, no variables, no loops, no ability to run external programs.
SIP-CGI – Common Gateway Interface. Like HTTP CGI, the script resides in a network server and passes
message parameters through environment variables and sends instructions back via the standard output.
CGI scripts can be written in most programming languages.
SIP Servlet – Servlets are similar to GCI but rather than a separate process messages are passed to
class that runs in the JVM on the server. As they are Java based SIP servlets should be portable between
server platforms.
JAIN SIP – A low level API that maps directly to the SIP RFC.
JAIN SIP Lite – A high level API; uses a greater degree of protocol abstraction and acts as a high level
wrapper around the SIP protocol. Requires much less knowledge of the SIP protocol on the part of the
developer than JAIN SIP.
25. Copyright 2005: MultiService Forum
Legacy Service Access via IMS-SSF
SSF function
SIP Proxy or B2BUA
SIP
INAP / TCAP
SIP
IM-SSF function allows access to legacy
IN services from the SIP service
network.
Acts as a proxy in the SIP domain and
as an SSP in the IN domain.
Effectively peers SIP to ISUP and
applies the SSP functions. Only works in
one direction, i.e. IN services on a SIP
network.
Realistically some legacy services may
require SIP-I to be delivered to the IM-
SSF in order to prevent information loss.
IM-SSF products are commercially
available.
26. Copyright 2005: MultiService Forum
Other Service Models
Service Delivery Platforms SDP
No consensus to date on what architectural elements constitute an
SDP Some vendors use the term SDP for their application servers
or content delivery solutions, whereas other vendors and service
providers tend to include a whole portfolio of products and
components such as CRM systems or rating engines in their SDP
offering.
In general, an SDP should be seen as a commercial bundle of
different products, possibly offered by different vendors.
Some comment elements of SDPs are :-
• Service Execution Platform (e.g. Application Server)
- a core element of an SDP providing the deployment and
execution environment for broad range of voice and data
applications.
• Network Abstraction Layer (e.g. Parlay GW )
- a core element of an SDP providing standardized interfaces to
core network elements and services.
• Service Exposure Layer (e.g. Parlay X GW)
- an optional element exposing service capabilities (usually via
Web Services) to 3rd party service providers and enterprises.
• Content Delivery Platform
- an optional element usually present in mobile SDPs for the
provisioning of multimedia content to mobile devices.
Network Elements
Web Services
Service Exposure
Layer
Network Abstraction
Layer
Service
Execution
Platform
Content
Delivery
Platform
27. Copyright 2005: MultiService Forum
OSE (OMA Service Environment)
Main components
Application – either in house or third party
Policy Enforcer – applies policies (authorization,
authentication, ..) to the interaction between the Application and
the Enabler or between Enablers.
Enabler – Intrinsic functions providing access to the underlying
network resources. OMA only define interfaces not individual
methods for the enabler.
Execution Environment – provides Life Cycle, Load Balancing
and other OA&M functions.
29. Copyright 2005: MultiService Forum
Media Specific Applications - SDP Modification
Insulate Applications from the full media awareness – present to them only the media
parameters appropriate to their function.
Authentication
App
Voice
App
Video
App
Whiteboard
App
Service Orchestration
Function
INVITE
m=audio
m=video
m=application
INVITE
m=audio
m=video
m=application
INVITE
m=audio
m=video
m=application
INVITE
m=audio
INVITE
m=audio
INVITE
m=video
INVITE
m=video
INVITE
m=application
INVITE
m=application
INVITE
m=audio
m=video
m=application
Audio
Video
Application
SDP
Audio
Video
Application
SDP
Audio
Video
Application
SDP
Audio
Video
Application
SDP
Audio
Video
Application
SDP
STORE
EXTRACT
EXTRACT STORE
STORE STORE STORE
EXTRACT
EXTRACT
EXTRACT
Treat as a single service chain, SDP ‘components’ updated as the chain progresses.
Parallel invocation could reduce latency but needs potentially complex rules to re-
combine multiple SIP INVITEs to the destination.
30. Copyright 2005: MultiService Forum
Partial Media Terminating Applications
Applications may terminate the media session (directly or via a shared media server). In such
cases there is no onward signalling from the application.
However, the application may have only terminated a single media type; in such cases the
Service Orchestration Function should ‘fork’ the INVITE and continue with session
establishment and service invocation for the remaining media types.
Authentication
App
Voice
App
Video
App
Whiteboard
App
Service Orchestration
Function
INVITE
m=audio
m=video
m=application
INVITE
m=audio
m=video
m=application
INVITE
m=audio
m=video
m=application
INVITE
m=audio
INVITE
m=audio
INVITE
m=video
INVITE
m=video
INVITE
m=application
INVITE
m=application
INVITE
m=video
m=application
Audio
Video
Application
SDP
Video
Application
SDP
Video
Application
SDP
Video
Application
SDP
Audio
Video
Application
SDP
STORE
EXTRACT
EXTRACT STORE
REMOVE STORE STORE
EXTRACT
EXTRACT
EXTRACT
Audio
MCU
INVITE (conf=xxx)
m=audio
31. Copyright 2005: MultiService Forum
MSF Release 2+ (IMSF) - Objectives
Import IMS functions into the R2 architecture in
order to :-
• Support nomadicity (roaming) of terminals and
users.
• Support inter working between core IMS and
MSF R2+
– Roaming of IMS subscriber to R2+ network
– Roaming of R2+ subscriber to IMS network
32. Copyright 2005: MultiService Forum
MSF Release 2+ (IMSF) – Architectural Snapshot
AG TG SG SBG-NE
DCA
SCA
RCA
SBG-NC
SB
BM
MS
HSS
AS PGW
SLG
PA PXA AG = Access Gateway
TG = Trunking Gateway
SG = Signalling Gateway
SCA = Static Call Agent
DCA = Dynamic Call Agent
RCA = Routing Call Agent
MS = Media Server
SBG = Session Border Gateway
BM = Bandwidth Manager
SB = Service Broker
HSS = Home Subscriber Server
AS = Application Server
PGW = Parlay(x) Gateway
SLG = Service Logic Gateway
PA = Parlay Application
PXA = Parlay X Application
P-CSCF
S-CSCF
I-CSCF
SCIM
OSE
IM-SSF
SDP
OSA SCS
1st Gen VoIP End Points IMS End Points
33. Copyright 2005: MultiService Forum
A typical example of a rich voice call
• A has a subscription with fixed operator X
• B has a subscription with mobile operator Y
• B is roaming to mobile network Z
• A calls B – voice call
– A has originating services, B has terminating
services
• B adds in video
– A has terminating services
• A adds in white-boarding
– A has originating services
34. Copyright 2005: MultiService Forum
A typical example of a rich voice call
User
B
DSL/Cable Modem
DSLAM/CMTS
RNC
GGSN
Network Z UMTS/GPRS
Network X MSF R2+
User
A
SGSN
Network Y IMS
GRX
SBG-NE
P-CSCF
P-CSCF
RCA
I-CSCF
I-CSCF
S-CSCF
DCA
S-CSCF
HSS
HSS
AS
AS
35. Copyright 2005: MultiService Forum
Summary
• IMS offers the ability to rapidly define and
implement services that interact with each
other seamlessly, regardless of the access
technology and location of the end user.
• Subscribers have their services available to
them on multiple types of end user device and
with common presentation and identification.
• The access technology no longer governs the
service presentation to the end user, and so a
vast new range of services is conceivable.