View
217
Download
0
Category
Preview:
Citation preview
7/28/2019 Session8A-1
1/6
1
Delivering Quadruple Play with IPTV over IMS
Bruno Chatras, Mikhal Sad
France Telecom Research & Development
38-40 rue du Gnral Leclerc
F-92794 Issy Moulineaux Cedex 9
Email: {bruno.chatras,mikhael.said}@orange-ftgroup.com
1 Introduction
The interest in IPTV services is increasing as
these are perceived as a potential source of new
revenues by telecommunications service
providers. IPTV services are actually already
being deployed by many of them around the
globe and tend to be packaged as "triple play"
solutions, including telephony and Internet or
even "quadruple play" with wireless aspects.
Current solutions are essentially vendor-specific
and the services they provide are inherited from
those available with terrestrial, cable and satellite
television, augmented with features enabled by
the availability of an upstream channel such as
video on demand (VoD), personal video recorder
(PVR), and live TV with trick mode (e.g. pause,
fast forward ). However, new needs are
emerging along with "quadruple play": access
independent solutions, integration in a multi-
services environment, availability of enhanced
services combining features from everycomponent of the "quadruple play" bundle, etc.
A common control plane managing both IPTVservices and other multimedia communication
services would ease responding to these new
needs. The IP Multimedia Subsystem (IMS) [1]
defined by 3GPP and extended by ETSI TISPAN
provides one possible answer and standardisation
bodies such as ETSI TISPAN and ITU-T arealready working on such an approach.
Section 2 of this paper further discusses the
motivations and benefits of using IMS-based
solutions in support of IPTV. Section 3highlights a number of technical challenges thatan IMS-based solution has to face. Section 4
provides a technical description of the IMS-
based solution under standardisation in ETSI
TISPAN [2].
2 IMS-based solutions design andmotivations
The integration of IPTV services in an NGN
environment is one the key features that the
ETSI TISPAN technical body will deliver as part
of the second release of its NGN standards.
Integrating IPTV in NGN aims at enabling IPTV
functions to interact with relevant NGN
subsystems and use the capabilities they provide,
namely dynamic network attachment and
management of transport resources with quality
of service control. Two variants are beingconsidered in standardisation bodies. The first
way, called "IPTV dedicated subsystem",
focuses on the integration of existing market
solutions in an NGN environment. Its prime
objective is to take advantages from NGN
environment without replacing existing IPTVsystems. The second way, called "IMS-based",
consists in using the IMS as a control plane for
IPTV services as for any other multimedia
services.
The IMS-based solution addresses not only basicbroadcast (e.g. Live TV) and streaming (e.g.
VoD) services but also aims at combining them
with communication services (conversational
services, presence services and messagingservices) so as to provide end-users with a newmultimedia experience. Examples of combined
services are "click-to-dial from TV", where a
user can initiate a call to a number shown on the
TV screen (e.g. during a TV show); "Caller ID
on TV", where the identity of the calling party is
displayed simultaneously on the TV screen andon the phone sets; call forwarding (to a mailbox)
when watching TV/VOD; remote parental
control using short messages, etc.
Besides its ability to ease the design and
implementation of combined services the IMS-based approach brings additional inherent
benefits:
- Common infrastructure: Almost all large
Telcos have plans to deploy an IMS
infrastructure in support of the replacementof their TDM-networks. Indeed, according
to Gartner, in 2010, 77% of all investment
for call control layers is forecast to be based
on the IMS. The IMS-based approach will
leverage this investment by enabling the
support of IPTV services on the same
network infrastructure than VoIP services.
7/28/2019 Session8A-1
2/6
2
- Common identity and authentication
mechanisms: The IMS identification and
authentication framework provides an
opportunity to extend the features of
existing IPTV services with multi-user
subscription capabilities. This will make
possible allocating different public identitiesand service profiles to different users
sharing the same IMS / IPTV subscription.
Such capabilities will typically be used to
manage different lists of subscribed
channels associated to different users in the
same family.
- Common resource management: The IMS
relieves IPTV application servers from the
task of interacting with transport control
functions for the purpose of reserving
transport resources.
- Multi-access solution: IMS is designed to
be access-independent. Using the IMS as a
control plane will therefore allow users to
access their IPTV services whatever the
access they are connected to. Moreover, the
multi-access capability brought by the IMScomes with the support of service roaming
and service continuity when moving from
one access to another.
- Common charging mechanisms: As a
result of using the IMS for session control
IPTV services will benefit from genericcharging mechanisms and interfaces
applicable to other types of multimedia
services. This will facilitate unified billing
for multi play solutions.
3 Technical Issues
Although the IMS was originally designed as a
generic platform for supporting multimedia
services, IPTV services bring specific technical
challenges that have not yet been fully tackled by
IMS standards.
3.1 Service Discovery and SelectionService Discovery and Selection (SD&S) refers
to a set of procedures that a user needs to go
through before invoking any IPTV service. This
enables the user to discover available services
and retrieve the necessary parameters to activatethe selected service. Electronic Program Guides
(EPG) and VoD catalogues are part of the
service selection information. They can be
unicasted (e.g. retrieved by the user from a portal)
or multicasted (e.g. received on the user
equipment in the form of a specific broadcastedchannel). There exist several competing
standards for the specification of SD&Sprocedures and associated information (e.g.
DVD-IPI or OMA-BCAST for mobile access).
However, the IMS specifications do not
currently include explicit support for such
procedures.
3.2 Control of media flowsSpecific time constraints related to media flows
control have to be taken into account. Channel-
hopping delay is one of the major ones for
broadcast services. Trick mode operations (e.g.fast forward) in VoD and PVR are also subject to
time constraints. In order to avoid that IMS
signalling procedures bring extra delays, it is
necessary to draw a clear separation between
service/session control performed at the IMS
level and media flow control handled end-to-endbetween the user equipment and the content
servers.
3.3 Applicability of session concepts tobroadcast servicesMost of the current broadcast services are
session-free: once the list of subscribed channels
is fetched, the client can perform channel-
hopping without running any session-related
preamble or postamble procedure. With the IMS,
introducing the notion of session enablesadapting network resources to the services and
therefore increases the efficiency of transport
resources management. The initiation of the
session provides IPTV services with the ability
to request and reserve transport resources and
modify these at a later stage (e.g. when zappingfrom SD channels to HD channels). Explicit
termination of IMS sessions enables releasing
these resources, making them available for other
services/users. Moreover, the existence of an
explicit session provides criteria for triggering
the publication of events to be used for presenceservices purposes.
3.4 Negotiation of media properties duringsession establishment
IMS procedures for negotiating media properties
during session establishment follow theoffer/answer model defined in RFC 3264.
According to this model, the offerer provides a
description of the set of media streams and
codecs it wishes to use, while the answerer
responds by indicating whether these streams are
accepted or not, and which codecs will be used.
A stream description in an offer may include a
bandwidth attribute, in which case it indicates
the desired bandwidth that the offerer is prepared
to receive. This model is suitable for
conversational services and is not followed today
for streaming services where bandwidth
information relates to the bandwidth required totransmit a particular content rather than to the
capabilities of the two ends of the
7/28/2019 Session8A-1
3/6
3
communication. Therefore, its applicability to
IPTV needs to be carefully considered and may
require adaptation.
4 Architecture, procedures andprotocols
The principle of the IMS-based solution lies on
the use of IMS architecture and procedures. This
section provides further details on the
implementation of this principle in ETSI
TISPAN standards.
IMS compliant SIP/SDP procedures are used to
establish, modify and release sessions between
the user equipment and the content servers.
Session initialisation provides the ability to
negotiate the characteristics of content channels
and possibly of an associated control channel,
and reserve the required transport resources. Asfar as streaming services are concerned, the
protocol running over the control channel is
expected to be RTSP (or a subset of it).
4.1 Architecture
CORE IMS
Service ControlFunctions
MediaFunctions
User
Equipment
ServiceSelection
UPSF
Transport
RACSFlow controland media delivery
Resource andAdmission control
Session initialisationModification andtermination
ServiceDiscovery
Figure 1: IMS-based solution functional architecture
The IMS-based approach relies on a functional
architecture centred on the core IMS (i.e. theIMS Call Session Control Functions). When
processing session signalling, as for any other
multimedia service supported over the ETSI
TISPAN NGN architecture, the Core IMSinteracts with the UPSF (User Profile Server
Function) to download service profileinformation and with the RACS (Resource and
Admission Control Subsystem) to request and
reserve transport resources related to the session.
Before initiating a session, the user has to
proceed to the selection of a service usingService Discovery and Selection (SD&S)
procedures. SD&S includes three steps:
1) Retrieval from a Service Discovery
Function (SDF) of service providers' serveraddresses (e.g. addresses of service portals);
2) Connection to these servers (known as
Service Selection Functions, SSF) to get
information on available services;
3) Retrieval of relevant information (e.g.
content identifier, media parameters)
required to initiate a session for accessing
the selected service.
After a service is selected, the relevant content
identifier is inserted in the SIP session initiation
message sent towards the IPTV Service Control
Function (SCF) that provides access to this
service.
IPTV Service Control Functions perform service
authorisation during session initiation and
modification, which includes checking IPTV
users' profiles in order to allow or deny access to
the service. IPTV Service Control functions may
also perform credit control and select therelevant IPTV media functions. They act as
standard IMS Application Servers, using the ISC
interface to communicate with the core IMS.
This architecture is designed to make media
flows control out of the IMS scope, in order tocope with the issue highlighted in 3.2. Media
flows control is therefore supported by other
means, using existing protocols: RTSP for trick
mode operation during streaming services and
IGMP for channel zapping during broadcast
services.
IPTV media functions are in charge of
controlling and delivering media flows to the
User Equipment. They are split into Media
Control Functions (MCF), handling media flow
control and managing interaction with the UE(e.g. handling of trick-mode), and Media
Delivery Functions (MDF) sourcing the actual
media flows.
For the purpose of implementing combinedservices IPTV service control functions may
interact with Presence Servers or with
Application Servers hosting the logic ofcommunication services, using IMS capabilities
such as third-party registration, event
notification For example, existing IMSpresence capabilities can be enhanced with
IPTV-specific information such as an indication
of the "currently watched channel", allowing
user's contacts to share experiences and third-
party applications to develop specific services
based on IPTV presence information.
4.2 User DataThe provision of IPTV services involves twocategories of user data:
7/28/2019 Session8A-1
4/6
4
- IMS user profile data: These data are
required for the IMS to operate and are not
related a specific service. They include,
amongst other parameters, triggering filters
(i.e. Initial Filter Criteria - IFC) towards
application servers hosting services the user
has subscribed to.- IPTV user profile data: these data are
specific to IPTV services. They typically
include the list of subscribed channels for a
broadcast service or the parental control
level and language preferences for video on
demand services.
The IMS user profile data are always stored in
the UPSF while IPTV user profile data may be
stored at a different location. They may be stored
transparently in the UPSF as enabled by the IMS
specifications or nearer to the Service Control
Function, if frequent accesses are needed duringthe processing of service sessions. Such data
have to be available to the SCF and may also
need to be available to the SD&S functions in
order to customise the information they present
to the user.
4.3 Service discovery and SelectionAs described in a previous paragraph (see 4.1),
Service Discovery and Selection comprises three
steps. During the first step, users contact the
Service Discovery Function to retrieve the
addresses of the servers (Service Selection
Function) that can provide them with a
description of the available services. This three-
step approach allows the network to provide
access to services and contents from several
service providers.
The communication between the user equipment
and the SDF relies on the SIP SUBSCRIBE and
NOTIFY methods. The user equipment can
acquire the knowledge of the Service Discovery
Function address through provisioning or rely on
the IMS to route the SUBSCRIBE request to the
appropriate SDF, based on initial filter criteria
(IFC) contained in the user profile (See figure 2).
CORE IMS
UserEquipment Service
SelectionServer
ServiceDiscovery
Server
IFC : triggeringto theService Discovery function
1. Suscribe/NotifyProcedure: retrievalofservice selectionservers' addresses
2. Service information and selection
Figure 2: Service Discovery and Selection
When looking at the above figure, it is worth
noticing that only the service discovery step goes
through the IMS.
4.4 Streaming sessionStreaming session initiation is composed of three
logical steps:
- Establishment of a dialogue between the UEand the IMS: this step encompasses the
processing of the SIP session setup, the
execution of a service logic by the SCF (e.g.
checking of user's rights, determination of
appropriate charging rules) and the
selection of the relevant media function;- Negotiation of the control channel between
the UE and the media function necessary to
support trick mode operation;
- Negotiation of one or more content
channel(s) between the UE and the media
function necessary to deliver the requestedcontent.
The three steps can be executed in sequence or in
parallel depending on the parameters available at
the UE to initiate the session. If the UE has
enough parameters to make an offer for control
and content channels at this stage, it can combine
the session initiation request with the offered
control and content channels descriptions in a
single message, as illustrated in the figure 3.
However, if the only piece of information
available to the UE when initiating a session is a
content identifier, the control and content
channels offers have to be sent from the media
function in subsequent SIP messages.
The session initiation is performed using the SIP
INVITE method. Negotiation of the content and
control channel descriptions is achieved by
exchanging SDP descriptions embedded in SIP
messages, following the SDP offer/answer model.
This procedure is very similar to the one already
existing for conversational services. However, as
explained in one of the above paragraphs ( 3.4),the offer/answer model is indeed suitable for use
with conversational services but may require
adaptation for use in the context of IPTV
services, especially regarding the conveyance of
bandwidth information. Work is in progress at
the IETF to extend this model with an indication
of the bandwidth required by an application.
Messages exchanged over the control channel for
trick mode operation are imported from RTSP.
They do not go through the IMS, thereby
answering to the constraint delay as explained in
3.2.
7/28/2019 Session8A-1
5/6
5
IMS procedures also allow the user or the media
function to modify an established session. For
example, on receipt of RTCP reports indicating
downgrade of the network resources, the media
function can decide to modify the media flows
properties in order to adapt them to network
changes. Session modification may also be usedwith SVC (Scalable Video Coding) when
enhancement layers are added or removed during
a session.
Figure 3 gives an example of a session initiation
procedure where the three logical steps identified
above are combined.
CORE IMSUser
Equipment SCF MF
INVITE (SDP offer for RTSP and content)
INVITE (SDP offer)
INVITE (SDP offer)
200 OK (SDP answer)
200 OK (SDP answer)
200 OK (SDP answerfor RTSP and content)
ACK ()
ACK ()
ACK ()
RACS interactions
RACS interactions
RTSP
Figure 3: Streaming session initiation example
When looking at the above figure, it is worth
noticing that RACS mechanisms required to
reserve transport resource and performadmission control for streaming flows areidentical to those required in support of
conversational media flows.
4.5 Broadcast sessionThe broadcast session spirit differs from the
unicast one since media functions are not part of
the initiation process. However, a session can beinitiated between the UE and the SCF to allow
the later to perform appropriate service checking
(e.g. user's rights). Moreover, during session
initiation, media parameters related to subscribed
channels are exchanged via SIP/SDP messages.
This information can be used by the core IMSfor two purposes:
- To build a request to the RACS for
reserving transport resources in the last-mile
segment of the network at service session
initiation time. Here, it is worth noticing thatIMS-initiated mechanisms are not sufficient
to perform admission control beyond the
access part of the network since multicast
flows are shared between users. Additional
mechanisms are currently being studied in
ETSI TISPAN to enable admission control
to be applied to other segments of the
network.
- To provide the RACS with information
required to enable multicast access control
to be performed in the access node: during
session initiation the RACS downloads in
the access node a set of filters related to the
subscribed channels. This way, when the
access node receives an IGMP join requestfrom the UE, it can autonomously allow or
forbid access to the requested channel by
preventing or enabling packets received
from the corresponding source to be
forwarded to the UE.
Figure 4 gives an example of the broadcast
session initiation.
CORE IMSUser
Equipment SCF
INVITE (service package id)INVITE (service package id)
PRACK (SDP answer)
PRACK (SDP answer)
Resourcescontrol
183 Session Progress (SDP offer)
183 Session Progress (SDP offer)
Resources control :
downloadfilters
in the accessnode
for multicast control
200 OK ()
200 OK ()
200 OK ()
200 OK ()
Figure 4: Broadcast session initiation example
As already mentioned, after session initiation,
the UE can use IGMP to perform channel-
hopping without going through the IMS. In casepreviously allocated resources are not sufficient,
an IMS session modification procedure may take
place in parallel with the IGMP join. However,
this procedure can become heavy and inefficient
if frequent modifications are required. ETSI
TISPAN is currently studying an alternativesolution where receipt of an IGMP message by
an access node can trigger a request to modify a
resource reservation. This requires extensions to
the RACS capabilities and is known as a "pull"
procedure.
4.6 Use of IMS for Network Personal VideoRecorder and Time shifting
Network Personal Video Recorder (N-PVR)
allows the user to record a particular live content
and watch it later on. The registered content is
stored in the network. From a user's point of
view, this service involves two steps:
1) The user decides to record a live content.
Specific interactions between the user
equipment and the AS are necessary to
identify the sequence the user wants to
record. Such interactions do not rely on
IMS session-based procedures and may be
achieved using HTTP.
7/28/2019 Session8A-1
6/6
6
2) The user accesses the recorded content.
Since this is a registered content such as a
VoD, the procedures described in 2.1 for
streaming session initiation apply.
Network Time Shifting (N-TS) allows trick
mode operation to be supported on a liveprogram. This procedure relies on the
assumption that the contents of the live programs
are continuously recorded in the networks for a
certain period of time. Therefore, in order to be
able to use trick modes, the user equipment just
needs to turn the broadcast session into a
streaming session with the server that contains
the corresponding recorded content. This is
achieved by sending a re-INVITE request from
the UE to the SCF with an indication of the
currently watched channel (since the SCF may
not know it unless the procedures described in
4.7 are used). When the streaming session isestablished, the UE can use RTSP to perform
trick mode commands on the unicast streams as
defined in 2.1. Going back to a live mode is
possible and would imply the reverse procedure
from streaming to broadcast session.
4.7 Presence enablersPresence enablers are already specified in IMS
but do not currently include IPTV specific
information. However, existing procedures can
easily be used and extended with such
information. This is particularly relevant in
broadcast services where the presence feature
can be used to publish the channel/program
currently watched by the user (See Figure 5).
This capability can be required by particular
applications combining IPTV features with other
IMS services (see 2). It could also be used in
instant messaging applications where a user
would then be able to see what his/her contacts
are watching (very much like some existing
instant messaging applications already enable
users to publish the music they currently listen).
However, in order to cope with numerous
channel-hoppings potentially causing overloadsin the network, a minimum time interval between
publications can be set to limit the number of
messages sent into the network.
CORE IMSUser
Equipment ASAccess Node
Session initiationalreadydone
Join (xcastchannel 1)
Zapping timer
PUBLISH (channel 1)
PUBLISH (channel 1)
IFC
Figure 5: presence for broadcast services
5 Conclusion
IMS is really promising in terms of IPTV
services evolution. IPTV session management
re-uses existing IMS procedures with very fewadaptations as described in this paper. Because
these procedures are identical or similar to those
used in support of conversational services, thissolution facilitates offering advanced services by
combining features from the two worlds.
Moreover this type of solution benefits frommobility management procedures that are
inherent to the IMS and opens the door to IPTV
service continuity when moving from one
network access to another.
IMS-based IPTV will offer a well-standardisedsolution to provide not only basic IPTV but also
quadruple play and enhanced services. It is an
opportunity for the IMS to demonstrate its
commercial value and will likely be at the centre
of multimedia services infrastructure
mutualization.
6 References[1] 3GPP TS 23.228. IP Multimedia Subsystem
(IMS); stage 2.
[2] ETSI TISPAN TS 182 027: IPTV
Architecture; IPTV functions supported by
the IMS subsystem.
7
Glossary
AS Application Server
HD High Definition
IFC Initial Filter Criteria
IGMP Internet Group Management
Protocol
IMS IP Multimedia Subsystem
IPTV IP Television
NASS Network Attachment Subsystem
NGN Next Generation Network
PVR Personal Video Recorder
RACS Resource and Admission Control
Subsystem
RTSP Real Time Streaming Protocol
SD Standard Definition
SDP Session Description Protocol
SD&S Service Discovery and Selection
SIP Session Initiation Protocol
SVC Scalable Video Coding
VoD Video on Demand
TS Time Shifting
UPSF User Profile Server Function
Recommended