IMS FOCUS Group
Raffaele De Peppe (Telecom Italia)
© GSMA 2012
All GSMA meetings are conducted in full compliance with the GSMA’s anti-trust compliance policy
GSMA IMS
GS
S Focus
ocus G
Group
oup
„
IMS is an increasingly important technology across all of telecoms
–
–
„
Increased activity in GSMA WG’s
WG s also shows the need for
renewed focus on IMS.
–
–
–
–
„
Many Fixed line operators have IMS networks
Mobile operators are headed towards IMS as a result of RCS and VoLTE.
IREG – VoLTE, VoHSPA, SR-VCC guidelines, Video over LTE.
CPWP – IMS service
i identification
id tifi ti work,
k LS exchange
h
with
ith 3GPP
3GPP.
IWG work on VoLTE commercial/business models and charging principles
and subsequent work between IREG and 3GPP (RAVEL work item).
RCS project.
GSMA’s IMS activities are connected but in a limited way – need
to have a consolidated and unified view of:
–
–
–
Why IMS is needed, and what it enables within GSMA context.
What IMS could enable in the future – services, business opportunities…
H
How
GSMA goes about
b t ffostering
t i innovation
i
ti
and
d an ecosystem.
t
2
CONFIDENTIAL – BSC Doc 54_03
2
Mission of the IMS Focus Group
„
1.
2.
3.
4.
To enable the Vision of an IMS-based future through following steps:
Id tif requirements
Identify
i
t tto b
be mett tto enable
bl IMS
IMS-based
b
d services
i
tto deliver
d li
business models that foster competition
–
Consumer, interconnect and roaming
g requirements
q
to shape
p a
carrier grade IMS reference architecture
Focus on Service Innovation – new services and exposure of IMSbased services to 3rd Party developers
developers.
–
New service ideas to be brainstormed within the Group;
–
scope setting
g for IMS API
Define a functional IMS Reference architecture, to provide the
framework within which all current and future GSMA IMS work will exist
–
To be completed within the Focus Group
–
Will cover QoS/Policy Control and evolution from/integration with
existing network and services
Terminals implementation focus
–
Scope setting
3
CONFIDENTIAL – BSC Doc 54_03
Market
a et Trends
e ds a
and
d Business
us ess Drivers
e s ((1/2)
/ )
„
F d
Fundamental
t l shifts
hift iin th
the iindustry
d t
–
–
–
„
Voice -> data for traffic dominance and revenue stream (although
voice/SMS revenue still higher than data).
TDM -> IP as technical basis for networks; SS7 evolution stops and IMS
replaces this. Capability to deliver more than ‘just voice and text’ yet still
have interoperable, ecosystem-creating services.
Operator delivered services -> Applications as consumer service
model, although Operator role is still to provide services that require high
availability and reliability, and to provide connectivity for Applications to
use.
Applications that replicate and/or enhance operator services cause
greatest disruption
–
VoIP, Messaging, Social Media, Enterprise applications all emerging
from 3rd Party App community
4
CONFIDENTIAL – BSC Doc 54_03
Market
a et Trends
e ds a
and
d Business
us ess Drivers
e s ((2/2)
/ )
„
Challenge for operators has been understood for some time
–
„
IMS can enable this
–
–
„
Harness the diversity and creativity of the App Developer community
without exposing themselves to the associated risks
Maintain the operator values of interoperability, availability, connectivity,
ecosystem
Expose operator ‘services’
services as ‘capabilities’
capabilities to application developers –
why create your own IM component of an App if operators can include
you in their wider service?
Operators need to focus on the traditional value statements and not
replicate or diverge in service implementation, then expose this value
to app developers
–
interworking principles; roaming principles; charging principles; Naming
conventions; interworking and compatibility with legacy; Service
provisioning on handsets; Single subscription for multiple devices;
exposure off APIs
API
5
CONFIDENTIAL – BSC Doc 54_03
IMS
S Quest
Questionnaire
o a e
„
Distributed to GSMA asking about current and planned
IMS deployments
–
–
–
„
„
„
Questions on the company characteristics
Option to answer either as a company with current IMS
deployment or with future plans
Questions on architecture and services to be deployed
deployed.
12 responses
p
– range
g of g
geographic
g p
focus,, size of company.
p y
4 mobile only, 8 multiple access (mostly fixed and mobile)
Spread of sizes from 10M subs to >100M
6
CONFIDENTIAL – BSC Doc 54_03
Service
Se
ce Innovation
o at o ((1/2)
/ )
„
‘E t
‘Extensively
i l St
Standardised
d di d S
Services’
i
’ – those
th
already
l d b
being
i worked
k d on
–
„
Innovative Services – new areas of p
possible focus
–
–
–
„
VoLTE, Video over LTE, VoHSPA, RCS
Unified Communications or ICT Integration Services – includes the
‘Enterprise Communication Suite’, and models like Rogers’ OneNumber.
Social TV - covers both TV-based clients and device based interaction
with TV content.
Gaming, IMS-based eHealth, in-App IMS interactivity also
considered.
considered
Much of the work from the ‘Extensively Standardised Services’ fulfils
requirements for Innovative Services.
–
No need to invent new voice, IM, Video etc. capabilities.
7
CONFIDENTIAL – BSC Doc 54_03
Service
Se
ce Innovation
o at o ((2/2)
/ )
„
E
Exposure
off IMS-based
IMS b
d capabilities
biliti via
i an API
–
–
„
IMS API could be an extension of on-going RCS API work
Re-use OMA RESTful API
When defining new services or capabilities, key areas of specification
are identified
–
–
–
–
Description of the service – to ensure that re-use of existing capability
is identified early.
Billable events – so that the service can be charged for as the operator
and/or market determines
Terminal/User Agent impacts – what the device needs to support
Technical interface definitions – User-Network, Network-Network and
Roaming Interface requirements.
8
CONFIDENTIAL – BSC Doc 54_03
Reference
e e e ce Architecture
c tectu e ((1/2)
/ )
„
A hit t
Architecture
to
t supportt key
k requirements
i
t from
f
previous
i
chapters
h t
–
–
–
–
–
–
–
–
–
Consistently implementable service-specific UNI
Consistently implementable service-specific NNI
Consistently implementable service-specific Roaming interfaces
Access agnostic requirements to enable Fixed Mobile Convergence for
relevant services.
QoS and Policy enforcement capabilities.
Service identification
C
Capability
bilit tto charge
h
ffor services
i
Interface for exposure of IMS service capabilities to third Party
developers.
Security of using IMS services.
9
CONFIDENTIAL – BSC Doc 54_03
Reference
e e e ce Architecture
c tectu e ((2/2)
/ )
3rd Party Applications
(HSS, P/I/S-CSCF, MGCF+MGW. MRFC+MRFP)
Ch i IInterfaces
Charging
t f
10
CONFIDENTIAL – BSC Doc 54_03
Interconnec
ct
IMS Elements
El
t
Po
olicy/QoS
(Voice, Video Telephony, IM, Capability Exchange, Video Share,
Image Share, other services from Chapter 3, …)
ISBC
Application Servers
ASBC
A
Policy/QoS
Accesss Interfa
ace
User Equipment
IMS API
Wholesale
o esa e IMS
S opt
option
o
Local networks
Centralised network
3rd Party Applications
(HSS, P/I/S-CSCF, MGCF+MGW. MRFC+MRFP)
Charging Interfaces
L
Local
l and
dC
Central
t l Billi
Billing elements
l
t
11
CONFIDENTIAL – BSC Doc 54_03
Interc
connect
IMS Elements
Polic
cy/QoS
(Voice, Video Telephony, IM, Capability Exchange, Video Share,
Image Share, other services from Chapter 3, …)
IS
SBC
A li ti S
Application
Servers
ASBC
Polic
cy/QoS
Accesss Interface
User Equipmentt
IMS API
Conclusions
Co
c us o s
„
Shift in attitude to IMS due to
–
–
–
„
Growing role of IMS in fixed network, where fixed and mobile access are
present and so could be used for mobile too.
Discontinuity in voice and SMS service delivery created by the
implementation of LTE networks.
Need to implement new person-to-person services, to offer similar
service experience to OTT, but with the added value of interoperability,
full reachability and security.
On this basis, need to look at what IMS could offer if used more
broadly.
broadly
–
–
–
Understand the need to innovate in the service space building on
operator values around interoperability and interconnect
expose services to 3rd party app developers via an API
Need an industry wide set of principles and technologies to enable this
12
CONFIDENTIAL – BSC Doc 54_03