Post on 03-Apr-2018
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
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 2/7
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:family@op.com). 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:dad.family@op.com). 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
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 3/7
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
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 4/7
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
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 5/7
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
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 6/7
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
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 7/7
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