IMS IPTV v4 2 Cwrice Changes Accepted 2007-6-26A

7/28/2019 IMS IPTV v4 2 Cwrice Changes Accepted 2007-6-26A

http://slidepdf.com/reader/full/ims-iptv-v4-2-cwrice-changes-accepted-2007-6-26a 1/7

Abstract — This article describes a novel architecture for

delivering personalized IPTV experiences to the end users.The framework leverages the IP Multimedia Subsystem(IMS) framework to quickly enable new innovative, multi-media services. We describe the session flows for someimportant use cases, such as accessing the electronicservice guide, Video On Demand (VoD), fast channelchanging, and enhanced parental control services. Ameasurement study for each of these sessions is quantified.

Index Terms — IPTV, IMS, handoff

I. I NTRODUCTION

P Multimedia Subsystem (IMS) is a next generation

network (NGN) architecture for mobile and fixedmultimedia services, standardized by the 3rd GenerationPartnership Project (3GPP) [1]. IMS enables new services andacts as an integration platform for the combination of telecommunications and Internet services. Some of itsattributes are as follows:

I

1. Access Agnostic Infrastructure – services areindependent of underlying access network..

2. Full mobility - transparent connectivity acrossheterogeneous networks, protocols and accessmechanisms.

3. Always on, always here capability via sessions thatcross networks and devices, automatically andtransparently.

4. User-centric context, both device and context-sensitive.

5. Personalized context-aware applications catered tothe needs of an individual or a group of individuals.

6. Flexible user interface enabling users to achievetheir goals efficiently.

7. Privacy, safety and security of information tosafeguard business and consumer integrity and

protect the digital rights of content creators.

In this paper we focus on some of the items outlined above.The vision is to offer seamless, networked-based media over three screens (TV, mobile device, and PC) enabled through

IMS, integrating multimedia with rich communicationsservices to deliver personalized, interactive television nomatter where the viewer is, when the content is requested, or what kind of device is used. In particular, several handoff scenarios between wireline set top boxes and wirelesshandsets will be shown. We show the advantages of thisarchitecture in fast market introduction by reducing thedependence on proprietary vendor solutions. In addition thisarchitecture introduces the flexibility needed to cope withthe emerging 3GPP requirement changes and deliversadvanced features in a timely fashion. There are several

reasons for using an IMS core. Some of the reasons are asfollows:

1. Core service network which is independent of accesstechnology2. Same application is available from any access

method or device.3. Ability to migrate and deploy across fixed and

mobile users4. Standards allow scalable deployment of new services5. Evolution to combined services for enhanced user

experience (presence, messaging, address book)6. Security in IMS is built-in - identity management,

authentication, authorization and service access7. Centralized user profiles shared between

applications8. Architecture designed for scalability and redundancy

9. Common solution to achieve Quality of Service10. Flexible Charging for multimedia and combined

services11. Common Provisioning

Section III discusses the specifics of the IPTV infrastructureusing an IMS core. Section IV investigates in detail sometypical session flow scenarios that we believe are novel in thecontext of IPTV. Section V describes a prototypicalimplementation of the above mentioned scenarios in arealistic environment. In addition, we provide protocol levelmeasurements to highlight valuable insights in thisframework and suggest possible bottlenecks andimprovements from a service provider’s stand point.

II.R ELATED WORK

Bodzinga et al. discuss how IMS and IPTV service platformscan be interworked and integrated to reduce network complexity and provide a flexible network for noveldifferentiated services [2]. An important aspect that IMSaddresses is redundancy and scalability; these issues withinIMS are addressed in [3]. This is particularly attractive for operators that deploy services which scale to a largesubscriber base. Traditional telecommunications networks areoptimized to have dedicated network functions at certainlocations, taking cost, quality of service, reliability and other technical circumstances into account. Load sharing of spread

network functions hardly could be realized. With the IPMultimedia Subsystem (IMS), a totally different approachwill be realized. It is based on the IP protocol carrying bearer and signaling/control traffic. While bearer traffic functionsstill to be optimized with respect to best location, thesignalling and control functions of the network could bespread more or less arbitrarily over the network becauserelatively low traffic between the functions does notsignificantly impact the optimization result of the totalnetwork. This is an additional degree of freedom for assigning such kind of equipment to given locations. It opensup new possibilities for scaling the equipment for total

IMS-TV: An IMS based Architecture for Interactive, Personalized IPTV

180 Park Ave, Florham Park, NJ 07932

1



network capacity needs and gives a chance to distributeredundancy geographically, which influences network reliability in a positive way. Moreover, the distributed IMSarchitecture based on SIP proxy mechanisms provide better means for redundancy and scalability as compared to ”classicsoft switches” that still follow a nodal architecture.

III. SYSTEM ARCHITECTURE

Figure 1 shows a high-level IPTV network architecture beingsupported by an IMS infrastructure. Three functional layersare defined, namely, the Service layer, the Control layer andthe IPTV control layer. The layered architecture facilitatesinteroperability amongst different vendor solutions andmaintains ease of service creation. The IPTV service layer

provides multimedia services to the end user by means of theIPTV Application Platform (IAP). It implements the portalwith which a user interacts and includes functionalities likethe electronic service guide (ESG), VoD etc. The IAPinteracts with the IPTV Terminal Function (ITF) that handlesdisplay and interactivity functions for users. It also performsfunctions such as content encoding/decoding and bufferingfor both unicast and multicast streams.

Figure 1 - High level architecture

A more detailed implementation is described in Figure 2. The

system is divided into a number of logically separated parts

namely the home network, access network, aggregation

network and the service provider domain.

A. IPTV user profiles

In the IMS IPTV architecture, personalization is an

important feature. To achieve personalization at the

application level (i.e. with personalized EPG’s,

advertisements, or even personalized blended communication

services), every user has an IPTV profile. The relation

between the IPTV profile and the IMS profile depends on theavailability of a home IMS gateway (HIGA) [4]. The HIGA is

a functional block with an attached ISIM card reader, which

can be deployed in the residential gateway or any other

networked consumer equipment. The HIGA translates home

signaling, whether SIP, UPnP or perhaps pure HTTP to IMS

signaling. It also takes care of NAT traversal and secure

connectivity with the P-CSCF in the IMS domain, as well as

identity, device subscription, and management inside the

home domain and towards the IMS core.

In a home network domain without an IMS gateway, every

IPTV account needs to have IMS public/private ID pairings

for the users of the system; these are used to log into the IMS

domain. However, since the TV is a social device, in which

many users are quite often watching TV together, the IMS

IPTV STB contains a default user which represents the

household itself (for example, sip:[email protected]). In this

way, the STB can be configured to use the default household

user to log in the IMS domain, personalizing itself with the

default values for the whole family, or it can be configured tomake the initial login of a personal user (i.e.

sip:[email protected]). Of course, personal user profiles

may be protected with a PIN that needs to be typed in via the

remote control to select a particular profile.

If the household contains a HIGA, the family members can

choose whether they want to have full IMS identity, one

which enables them full communication capabilities

supported by IMS, or they opt to just have an IPTV profile,

that will use the default IMS household identity for

authentication purposes. The IPTV profile information that

needs to be shared between different IMS services is stored in

the IPTV XDMS database [5]. This database is accessed

using XCAP [6], which works over HTTP. These profiles can

be shared by different users and other stakeholders within the

IPTV system.

Figure 2 - IPTV Implementation Architecture using IMS

B. The Multicast Data Channel (MDC)

The multicast data channel is a special IP multicast pipe that

allows the IPTV application server (or any other authorized

node to transmit information to all STBs registered with the

IPTV service). Each STB joins this special multicast group

upon startup and keeps listening to it for as long as it is

powered up. The MDC can be separated on different

multicast groups for special purposes.

The MDC carries information wrapped in an XML schema,

which provides for the ability to differentiate the various

pieces of information, like:

1. Electronic program guide information, a link to

download the EPG from a server, the EPG itself in

XML form, or even EPG updates.

2. Interactivity triggers, in the form of scheduled

actions to be displayed/executed in the STB; an

2



HTML page, showing a pop-up with information or

triggering a special interactivity mode in the STB.

3. Firmware upgrades. The MDC can carry an order for

all STB’s to download an upgrade, immediately or

schedule to some appropriate time.

4. Alert or emergency messages, which should be

shown as immediate pop-ups in the STB; these may

not disappear until the user acknowledges them.

For each piece of information in the MDC, there is a tag witha timestamp, which marks the validity of the information;there is also a tag that marks whether the information isincluded in the XML content (i.e. the EPG goes inside theXML-wrapped content), or whether it should be obtained viasome other means (i.e. an HTTP GET to a particular server,or a file transfer of some type). The XML wrapper contains aset of tags to identify the desired receivers of the content. Inthis way, the MDC can contain information that it has taggedto be received by a subset of the STB population. Typical tagsthat can be used include the following:

1. Channel being watched: only STB’s currentlydisplaying that channel will react upon the

information.2. Age: only STB’s whose active user falls into the age

range will react.3. Region: only STB’s located in the specified region

will react.4. Gender: only STB’s whose active user has the

desired gender will react (if field is populated)The filtering of the received information according to the

XML tags happens in the STB. In this way, the user can

decide

how much personal information he or she wants to configure

in his/her personal profile in the STB.

C.IPTV control planeThe control plane of the IPTV architecture can be divided

into a set of functions, like session setup, media flow setup,

media flow control, and non-media related functions. The

choice of protocols for each function tries to re-use existing

de-facto standards or IETF standardized protocols when

possible. The key components of the IMS control layer are the

x-CSCFs and the HSS. The S-CSCF evaluates all originating

and terminating messages and may, based on information of

the service, link-in during session setup any number of IMS

Appliaction Servers (ASs) to perform wanted IPTV services.

In all IPTV related SIP messages originating from the ITF,

the IPC will be linked-in. For IPTV, the HSS keeps triggers

and filter information for the IPTV Public Service ID (PSI) or the service identifier. The information is stored and conveyed

on a per IMS Application Server basis. This means that IMS

ASs are allocated dynamically and that SIP messages will be

routed all the time to the same IMS Application Server. The

S-CSCF downloads rules and triggers, upon user registration,

from the HSS.

IV. SESSION FLOW SEQUENCE DIAGRAMS

The set top box (STB) in the IMS IPTV architecture is a

full back-to-back IMS user agent that performs the default

IMS registration upon startup. When the STB is switched on,

it first obtains IP connectivity, which can be statically

configured or obtained via DHCP. As part of the IP

configuration, the STB discovers the IP address or DNS name

of the P-CSCF, which is the entry point to the IMS layer.

Once the STB obtains IP connectivity, it performs an IMS

registration with the predefined default profile. The default profile can be a family user IMS public ID, common for the

house hold or a personalized public IMS ID. Figure 3 shows

the simplified steps of the IMS registration. The only

important aspect of the registration is that the S-CSCF

performs a 3rd party registration of the user in the IPTV AS,

trigered by the information on the IMS user profile stored in

the HSS. After having registered the user, the STB sends a

SIP SUBSCRIBE towards the IPTV AS. The body of the SIP

SUBSCRIBE contains the last setup information that the STB

has cached, with a timestamp on it, wrapped in the same

XML schema in which the information within the multicast

data channel was sent.

The information included contains the following:

1. IP address of the multicast data channel.2. URL to the valid electronic program guide (and

interactive program guide if not the same) for theuser.

3. The latest profile information of the user.4. Any other needed common setup information.

When the IPTV AS receives the SUBSCRIBE, it confirms

the SIP dialog and checks the validity of all the information

in the XML body. Then, the AS generates a SIP NOTIFY

with the updated information wrapped in the same schema,

with a tag indicating whether it is the same as the STB sent

or the client needs to update it.

Figure 3 - STB registration

3



Figure 4 - Subscription to the IPTV service

The SUBSCRIBE/NOTIFY SIP session dialog is active as

long as the STB is actively watching/connected to IPTV. This

SIP session offers an extremely effective personalization

mechanism to reach a particular user (or a small group of

users) in the IPTV system. By having a homogeneous XML

to send metadata information over the MDC or over a SIP

NOTIFY, the IPTV AS has the ability to reach any single

user individually or in a bradcast distribution, without

changing the content of the metadata being sent. The same

type of filters that are applied in the client when receiving

information over the multicast data channel can be applied to

the received NOTIFY’s; so, the STB can filter out undersired

information without compromising the privacy of the

registered user.

The last step of the startup procedure is tuning in to the last

broadcast channel that the registered profile was watching.

Figure 5 describes the simplified flow. The STB triggers a

SIP INVITE towards the IPTV AS. This INVITE contains

simplified SDP information that refers to the type of TV

channel being received, in this case multicast in standard

definition. The goal of the SIP INVITE is setting up a ’media pipe’ to the STB to deliver the required set of channels. The

AS responds with a full SDP that describes the type of media

to be received. Finally, when the INVITE dialog is

completed, the STB joins the required multicast channel by

performing an IGMP join.

It is important to notice that an update to the SIP DIALOG

only occurs when the characteristics of the media pipe

change, but not when the channel changes. In this manner,

changing between multicast channels with the same

bandwidth characteristics happens via IGMP, without SIP

intervention. Figure 6 illustrates the procedure. This

behavior is required to achieve a fast channel changing

experience, which would be encumbered if the SIP sessionhad to be updated with every channel change.

Figure 5 - Tuning to a broadcast channel

When the user changes channel to a multicasted media

with different characteristics, the SIP dialog is updated via a

SIP UPDATE. This mechanism is important since it allows

the IMS system to know the proper QoS requirements

requested by the media flow being sent to the user. Of course,

updating the SIP dialog may introduce a small delay in the

channel changing experience, but this update provides for

assured media delivery of the requested standard or high

definition live channel.

Figure 6 - Channel Changing

Nevertheless, it is important for the IPTV provider to knowwhich channel the different STB’s are watching, to providetargeted advertisement or any type of media related addedvalue services. For this to happen, the STB has a channelchanging timeout, which triggers when the user has notchanged channel in the last ‘x’ seconds (for example, five

seconds). When the timeout triggers, the STB sends a SIPINFO towards the IPTV AS, which contains an XML bodywith the status information of the media. In the case of multicast live channels, this status information is simply thechannel being watched.

A. Accessing Video on Demand

As described in the previous section, the SIP INVITE

dialog remains unchanged as long as the media

characteristics do not change. In this way, when the user

decides to watch a Video on Demand movie, or any other on

demand media item, a new SIP session is created, after

4



finalizing the previous one. Figure 7 shows the process. The

first step is finalizing the previos SIP INVITE dialog by

sending a SIP BYE. This SIP BYE triggers as well the release

of the resources for the multicast delivery. After the BYE, the

STB sends a new SIP INVITE towards the IPTV AS, in this

case requesting unicastSD, for example. The response from

the IPTV AS contains an SDP describing the required media,

and transport control protocol, like an RTSP url. The STB

can then utilize the proper media transport control protocol(in this case RTSP) to start the desired VoD item.

Figure 7 - Video on Demand

When the user is watching VoD, the SIP INFO has another

important function. If the user decides to pause or stop the

media, then a SIP INFO is triggered towards the IPTV AS.

The IPTV AS contains the status information of the VoD

being consumed, for example, the time position, or frame

number, and payment information status if needed. This

information can then be used to retrieve the VoD item that

the registered user was watching from another device and

continue the program from where it was stopped. If the user

decides to go back to live TV, the procedure is repeated.

First, a SIP BYE finalizes the unicast SIP media pipe, and

then a new SIP INVITE sets up the multicast delivery again.

B. Change of User Profile

Personalization is a key feature in the IMS IPTV solution.

In this sense, we have already described how the STB

contains a default user for the family entity, as well as

personalized users for the different members of the

household. The process of changing a user profile implies

replicating the startup procedure for the STB, with a new user

IMS identity. Figure (To be drawn by Nacho, Figure 8?)

shows the procedure. The STB first sends a SIP SUBSCRIBE

with Expire=0 to the AS, terminating the subscribe dialog,

and then unregisters the old user profile. After that, the

register and subscribe procedure is repeated for the new user.

Note that if the new user can watch the same channel as the

old user, and there is no active channel change from the user,

the media transport control protocol is not used, i.e. no IGMP

message is sent to leave and join or no RTSP STOP and new

SETUP is issued. It is up to the logic in the AS to update the

state information of the media flows to belong to the new user

instead of the old one. However, if the new user profile doesnot have rights to watch the current channel, then the default

live channel for the new user is set up, using the procedure

described in the startup procedure.

C.Interactivity

The duplex communication nature of the Internet Protocol

allow the IMS IPTV to provide excellent interactivity

features, which coupled with the personalized aspect of

having an IMS registration, offers a complete two way

communication channel between content providers and

consumers. The IMS IPTV system uses a combination of

methods to deliver interactivity triggers, like the MDC,

personalized SIP NOTIFY's, or in-band media related

triggers. The feedback channel can be configured in thetrigger itself; so, a voting message, for example, can be sent

via a SIP MESSAGE, an HTTP PUT, or even with an SMS

triggered from the STB. SIP provides all the needed

functionality to set up specialized media channels, like VoIP

or videoconference, chatting, or gaming, which further enrich

the TV experience to transform it into a social events based

on rich multimedia communications.

D.Remote authorization

Remote Authorization service allows TV end-users to

request permission for ordering video content that is not in

their profile as an acceptable rating. The service can be

activated from the VoD Guide which will present an optionfor requesting remote authorization after users have selected

video content that has higher age rating than is allowed in

their user profile. An SMS message will be sent to the

authorizer's mobile device, which contains information about

the request, like requestor's name, content title and rating.

Following the instruction provided in the request message,

the parent can either approve or decline the request and reply

back. A pop-up message will be displayed on the requestor's

TV screen, notifying whether his request is approved or not.

If approved, the user can choose to view right now or later by

accessing it from the user's VoD list. A typical session flow

is shown in Figure 8

5



Figure 8 - Remote authorization

V. EXPERIMENTS

This section highlights some of the various features

implemented in the prototype and attempts to make some

basic measurements (e.g. channel change times, remote

authorization delay, et cetera). Figure 9 and Figure 10

illustrate a personalized user portal which can be navigatedonly by a remote control, and its access is controlled by

means of an identification code. Figure 11 shows the end user

applications, namely messaging to other users, broadcast TV,

Video on Demand, profiles and settings and Video calls.

Figure 12 shows the channel line up and information on the

currently viewed show (eg. rating, duration et cetera). The

VoD screen in Figure 13 shows a listing of the user's

available video for purchase. The purchased video is

highlighted with a green icon. Figure 14 shows a screen shot

of a voting application that allows a user to review and rate

shows while watching the show. These kind of interactive

scenarios add tremendous value in differentiating a service

provider's offer.

Figure 9 - User portal

Figure 10 - Access control (personalized profile selection)

Figure 11 - Applications (Chat, VoD, TV, etc.)

Figure 12 – Electronic Program Guide (EPG)

Figure 13 – Video On Demand screen

6



Figure 14 - Voting application

We now provide some measurements regarding the time ittakes to perform STB registration, VoD access, fast channelchange and parental authorization.

Functionality Elapsed Time (seconds)

STB registration 0.83 sec (figure 3)

IPTV service subscription 1.31 sec (figure 4)

VoD access < 5 sec (figure 7)

Fast channel change 0.41 sec (figure 6, leave-join-media)

Parental authorization < 20 sec (depending onaccess network delays)

VI. CONCLUSIONS

This paper investigated an IMS based architecture for the

delivery of IPTV services. In particular, session flows for

linear TV, video on demand, remote parental authorization,

and interactive services were some of the use cases that were

discussed in this paper. This paper demonstrates the great

promise that IMS-TV has and its the potential to deliver

differentiated services, which offer attractive, interactive, rich

multimedia experiences for the end user.

R EFERENCES

[1] R. Levenshetyn and I. Fikouras, “Mobile services interworking for imsand xml webservices,” IEEE Communications Magazine, 2006.[2] A. Bodzinga and S. White, “Interworking iptv services with ims,” inTelecommunications Network Strategy and Planning Symposium, November 2006, pp. 1–5.[3] M. Hammer and W. Franx, “Redundancy and scalability in ims,” inTelecommunications Network Strategy and Planning Symposium, November 2006.[4] T. Cagenius, A. Fasbender, and L. Barriga, “An IMS gateway for serviceconvergence in connected homes,” in Proceedings of the 45th FITCE congress, Athens, Greece, August 2006.[5] F. inc., XDMS: The FOKUS XML Document Management Server ,http://www.fokus.fraunhofer.de/bereichsseiten/.[6] J. Rosenberg, The Extensible Markup Language (XML) Configuration

Access Protocol , http://tools.ietf.org/html/draft-ietf-simple-xcap-12.

[1][2] 12.ZigBee Alliance, “ZigBee Specification,” December 1, 2006.

7

http://tools.ietf.org/html/draft-ietf-simple-xcap-12



IMS IPTV v4 2 Cwrice Changes Accepted 2007-6-26A

Documents

Transcript of IMS IPTV v4 2 Cwrice Changes Accepted 2007-6-26A