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