# Evolving the Convergence of Telecommunication and TV Services over NGN

Authors: Adel Al-Hezmi; Thomas Magedanz; Jordi Jaen Pallares; Christian Riede
Journal: International Journal of Digital Multimedia Broadcasting
 (2008)

---

## Abstract

The convergence of telecommunication, cable TV, and broadcast networks towards the Internet technology will enable the provision of emerging multimedia services as well as the integration of rich communication capabilities with TV services. However, enabling efficient delivery of interactive personalized multimedia services with mobility support requires an advanced overlay control framework. The IP Multimedia Subsystem (IMS) offers the basic functions to manage multimedia sessions over different access networks. This paper outlines current standardization activities that address the provisioning of TV services over IP networks—known as IPTV—and proposes a novel end-to-end overall architecture based on IMS that enables the delivery of converged multimedia services. Furthermore, the paper presents the FOKUS Media Interoperability Lab as a reference implementation of this framework which covers a widespread spectrum of converged interactive scenarios. The final section gives an impression of the system performance by providing the end-to-end signaling delay of a session setup for live TV service delivered over unicast transmission mode.


---

## Body

## 1. Introduction

Broad end-user
demand and corresponding investments in the deployment of mobile and fixed
broadband infrastructures in the late 90s of the last century paved the way for
the convergence of telecommunication, cable TV (CATV) and broadcast networks
towards the Internet technology,  thus currently
driving the notion of all-IP core networks. This evolution leads to move the
classic telecommunication and broadcast environments towards an open and
integrated programmable broadband network environment. This convergence scenario
will enable the provisioning of emerging multimedia applications with the
integration of telecommunication capabilities (e.g., audio/video telephony,
presence, messaging, etc.) and TV services (live TV and VOD), which will introduce
a formidable market competition between the involved players of the value chain
that embraces service provider, content provider, and network operators
including fixed and mobile telecommunication networks as well as CATV networks.Nowadays, most
of the telecommunication operators, particularly DSL operators, offer telephony
as well as TV services in addition to their service portfolio. BT Vision [1]
from British Telecom in the UK and T-Home Entertain [2] from Deutsche Telekom in Germany
are only two examples of
currently deployed IPTV service platforms. These solutions are built on top of very
high speed digital subscriber line (VDSL) access networks [3] that offer
bandwidths up to tens of Mbps to ensure a good user experience while watching
TV broadcasts by using best effort delivery without quality of service (QoS) on
top of partially managed network infrastructures. (The available bandwidth
depends on the distance from the user facilities to the telephone exchange.) This
procedure to assure QoS by offering more bandwidth than the maximum required
for a certain application is called over-provisioning.
This approach may lead to poor utilization of network resources thus not
accomplishing the objective of minimizing network costs [4].As a matter
of  fact, many current IPTV solutions in
the market are designed as isolated subsystems that support only TV services
and do not interact with other system elements. Most of these solutions use proprietary
interfaces within closed frameworks. Thus, cross-vendor interoperability is not
feasible and openness towards third parties is often impractical as it requires
the publication of such proprietary interfaces. Moreover, these solutions are neither
considering the use of functional components of the Next Generation Network
(NGN) nor the integration of Internet services.The delivery of integrated
multimedia services over IP-based heterogeneous access networks requires a set
of control functions such as identity and session management, authentication, authorization,
accounting, resource allocation, policy enforcement, QoS, and so forth. Within
this context, the long-term all-IP nature of NGN is being impacted by the
so-called IMS [5], which has been considered as an overlay control subsystem on
top of mobile, fixed and cable access networks that provides these supporting
functions. The IMS is standardized by the Third Generation Partnership Project
(3 GPP) [6] and it has been adopted by several standardization bodies such as
ITU-T (International Telecommunication Union - Telecommunication) [7], ETSI
TISPAN (Telecoms & Internet converged Services & Protocols for Advanced
Networks) [8] and
PacketCable [9].Cross-vendor
interoperability and the openness for third party service providers became the
main driver for standardization activities and at the same time generated the
need for standardized service platforms with open interfaces for IPTV over NGN
and non-NGN networks. The most recognized standardization bodies (SDOs) are
ITU-T, ETSI TISPAN, and the Open IPTV Forum [10] which work on the
harmonization of global standards and in the resolution of emerging issues,
which leads to collaborative work with other SDOs as DVB, MPEG, ATIS IIS [11],
and ISMA [12], to name only a few. The approaches of ITU-T, ETSI TISPAN, and
Open IPTV Forum follow 3 directions: IPTV over unmanaged open Internet networks
(with portal walled garden), IPTV over NGN networks and IPTV over IMS based NGN
networks (with walled garden); whilst the first approach does follow best
effort delivery without QoS, the second approach follows NGN paradigms like QoS
but without IMS involvement; the third approach benefits from both NGN
paradigms and IMS functionalities.In this article,
we concentrate on the third approach: IPTV over IMS based NGN networks. The IMS
serves as an overlay control layer that supports session management,
subscription notification mechanisms as well as third party service triggering
and charging facilities. There are currently a set of papers that address
issues of IMS-based IPTV reference implementations referenced in Section2.6 on
related work. This paper also presents a reference implementation of an
end-to-end converged multimedia service delivery platform, which enables the
delivery of interactive and personalized multimedia services such as instant
messaging, rich presence, or VoIP over different access technologies based on
the IMS network infrastructure. The remaining sections are organized as follows.
Section 2 describes the current technologies considered in our approach and
their status within standardization activities as well as related work
addressing similar research issues. Section 3 discusses the logical
architecture and the corresponding reference implementation of an IMS-based
interactive multimedia framework as validation within the FOKUS NGN/IMS
deployment. Section 4 sketches validated scenarios and presents performance
measurement that evaluates this work. The last section outlines conclusions and
future work.


## 2. Technology Overview

This section
offers an overview of the main technologies that are considered in the design
of the NGN architecture as well as in the delivery of multimedia services and
describes important considerations of the IMS within standardization bodies.
Finally, it presents other recent research efforts within the same research
field.


### 2.1. ITU-T and ETSI TISPAN NGN Architecture

While both the
ITU-T and the ETSI TISPAN work on standardization the architecture of the NGN,
the objective of this architecture consists in the convergence of heterogeneous
access technologies towards an architecture that is based upon the Internet
transport protocols. Both architectures present a generic multiservice,
multiprotocol, and multiaccess IP-based framework that aims at becoming the
reference model to achieve convergence between fixed and mobile networks based
on the Internet Protocol. This model is based upon the concept of cooperating
subsystems sharing common components. This architecture enables smooth addition
of new subsystems to cover new demands and service classes, and ensures maximum
common usage of network resources, applications and user equipment. That is,
the NGN in essence, should provide the required resources for delivering
multimedia content with high quality over several access networks. To fulfill
these requirements, the Resource Admission Control Subsystem (RACS) or Resource
Admission Control Function (RACF) is defined by the TISPAN and the ITU-T NGN
architecture, respectively. This component is in charge of the admission
control and QoS reservation on the access as well as on the core network.
Furthermore, the Network Attachment Subsystem (NASS) is responsible for dynamic
provision of IP address and user authentication, authorization, and location
management.Within this architecture, the IMS
is a central function that offers control capabilities for managing multimedia
session in a secure, controllable, QoS ensured, and chargeable manner.


### 2.2. The IP Multimedia Subsystem

The initial
specifications of the IMS are defined by 3 GPP [5] and they are based on the
Internet protocols standardized by IETF and then adapted by the ITU-T, ETSI, and
PacketCable 2.0 [9] to the NGN architecture and the cable TV network
infrastructure. The IMS functions are distributed among six control components:
first, the control components include the CSCFs (Call Session Control Functions)
responsible for the session management and the registration of the IMS
subscribers, the GCF (Gateway Control Function) controlling the gateway to the
circuit switch networks and the Media Resource Function Controller (MRFC),
controlling the media resource functions. Second, the media processing
components cover the Media Gateway and the MRFP (Media Resource Function
Processor) for supporting media capabilities such as playing or recording short
announcements, conferencing, transcoding, and DTMF detection. Third, the
HSS/UPSF (Home Subscriber Server)/(User Profile Subscription Function) is in
charge of the management of user and service profiles. Fourth, the application
servers host and execute new value added services in addition to the basic IMS
services. Fifth, the PCRF (Policy and Charging Rules Function) maintains the
allocation of the quality of service and applies the required policies on the
transport and the access network and is responsible of charging. Finally, the
IMS subscribers interact with the IMS elements using the protocols SIP (Session
Initiation Protocol), HTTP and RTP (Real-time Transport Protocol) over the
interfaces Gm, Ut, and Mb.


### 2.3. Multimedia Broadcast Multicast Services (MBMSs)

Whereas the
classical cellular network is primarily voice centric based on a point-to-point
communication model, the emerging multimedia scenarios mandate the need for
supporting broadcast and multicast transmission capabilities. In order to
address these new requirements, 3 GPP has extended the core network and the
radio interfaces in release 6 to support efficient broadcast and multicast IP
packet delivery. MBMS allows two modes of operation: the broadcast mode and the
multicast mode. In broadcast mode, transmissions take place regardless of user
presence in a defined area, whereas in multicast mode solely those areas are
supplied where subscribers need to be served. Concerning the radio interface
point-to-multipoint transmissions in downlink direction are introduced in order
to optimize radio resources. In the core network, the MBMS makes use of
application-based multicast instead of IP multicast. In comparison to previous
3 GPP releases, the Broadcast/Multicast Service Centre (BM-SC) is introduced as
a complete new functional entity serving as central controlling unit. It is
connected to the GGSN (Gateway GPRS Support Node) over the interfaces Gmb and
Gi. The former interface provides access to the control plane functions, the
latter to the bearer plane.


### 2.4. Digital Video Broadcasting (DVB)

The Digital Video Broadcasting (DVB) standard was designed
to broadcast digital TV services and it has been maintained by the DVB project
since 1993 [13]. DVB systems transmit data using a variety of approaches: over
satellite (DVB-S), cable (DVB-C), terrestrial (DVB-T), and handheld (DVB-H). As
DVB-T is mainly targeted at stationary receivers and is not suitable for mobile
devices, the DVB-H standard was proposed, which enhanced the physical and link
layers of DVB-T to reduce power consumption and improve performance in urban
indoor environments. While DVB is initially designed to support broadcast
transmission, there are several standardized solutions such as DVB-RCS (Return
Channel Satellite), DVB-RCT (Return Channel Terrestrial) or DVB-RCC (Return
Channel Cable) or DOCSIS (Data Over Cable Service Interface Specification) that
have been developed to facilitate bidirectional communication channel thus
supporting interactive applications (e.g., VoIP or VOD).The efforts of DVB-IPTV [14], the collective name for a set
of open, interoperable technical specifications, developed by the DVB Project,
in order to facilitate the delivery of digital TV using the Internet Protocol
over bidirectional fixed broadband networks is the DVB project’s answer to
current activities in the sphere of IPTV. In addition to DVB’s interactive
middleware specifications, DVB-MHP (Multimedia Home Platform) and GEM (Globally
Executable MHP) [15], which also include IPTV profiles, give the DVB Project a
good standing in the IPTV world. However, it acts still as broadcast technology
and concentrates on enhanced IPTV with n-play scenarios (beyond
triple/quadruple play) but with open Internet distribution. Thus, operators
will probably never take DVB into account when it comes to personalized
interactive scenarios where AAA and QoS are to be taken in consideration.


### 2.5. Open IPTV Forum

The Open IPTV Forum (OIPTVF) is an industry joint and has 5
key goals: creation of an end-user mass market for IPTV, acceleration of
introduction and deployment, ease the integration of end-to-end IPTV solutions,
creation of IPTV services and harmonization of IPTV infrastructure and, service
development. OIPTVF follows two approaches: managed networks with triple play
walled garden and open Internet with portal walled garden. The currently
released documents of this forum are mainly concentrated on requirements and
first architectural approaches which include 3 key entities: Open IPTV Terminal
Functional (OITF) Entity, IMS Gateway Functional Entity (IG), and Application
Gateway Functional Entity (AG). A main focus is the integration of the home
domain (via DLNA/UPnP [16, 17]) into a fully fledged IPTV solution.


### 2.6. Related Work

Various research
efforts tackle the problems of multimedia delivery over IP networks. An
IMS-based architecture to deliver TV services has been introduced in [18].
Although the authors discussed the interfaces between the user equipment (IPTV
Terminal Function) and the network side comprehensively, the paper does not
explain how the IPTV service controls the media delivery components (media
servers) for content delivery and media processing (if it is required).
Furthermore, it is not clear how the content provider, the service provider,
and the network operator could be smoothly involved in the value chain of the
content delivery. Within the Ambient Networks project [19], a service specific
overlay networking for adapting multimedia content has been designed, which is
based on a peer-to-peer communication model for service discovery and service
path management for media delivery [20]. The authors introduce the integration
of the overlay networking for media processing into the IMS session, while
assuming that the end terminals are part of the overlay network and the IMS
network. Since the overlay network, called service-specific overlay network
(SSON), provides already end-to-end session management, the integration of the
IMS session will introduce additional delay to the session setup between
session participants. Unfortunately, the paper does not provide any evaluation
result for this concept. The authors of [21, 22] outline motivations and
benefits as well as technical challenges of IMS-based IPTV solutions. Among the
benefits, they count the provision of a common infrastructure, common identity
management, and common charging, whereas they present challenges such as
broadcasting/multicasting, session management, and negotiation of media
parameters. Our implementation addresses these challenges using MBMS for
multicast/broadcast, a Session Management Enabler (SME) for session control and
using SDP together with SIP for media parameter negotiation, respectively. The
authors of [22] also present an architecture to provide IMS based IPTV
according to ETSI-TISPAN deployed in the ScaleNet project [23] consisting of
functional elements and the description of basic call flows to provide IMS
based IPTV according to ETSI TISPAN. Their work describes a novel IPTV service named
“Click to Multimedia Service.”


## 2.1. ITU-T and ETSI TISPAN NGN Architecture

While both the
ITU-T and the ETSI TISPAN work on standardization the architecture of the NGN,
the objective of this architecture consists in the convergence of heterogeneous
access technologies towards an architecture that is based upon the Internet
transport protocols. Both architectures present a generic multiservice,
multiprotocol, and multiaccess IP-based framework that aims at becoming the
reference model to achieve convergence between fixed and mobile networks based
on the Internet Protocol. This model is based upon the concept of cooperating
subsystems sharing common components. This architecture enables smooth addition
of new subsystems to cover new demands and service classes, and ensures maximum
common usage of network resources, applications and user equipment. That is,
the NGN in essence, should provide the required resources for delivering
multimedia content with high quality over several access networks. To fulfill
these requirements, the Resource Admission Control Subsystem (RACS) or Resource
Admission Control Function (RACF) is defined by the TISPAN and the ITU-T NGN
architecture, respectively. This component is in charge of the admission
control and QoS reservation on the access as well as on the core network.
Furthermore, the Network Attachment Subsystem (NASS) is responsible for dynamic
provision of IP address and user authentication, authorization, and location
management.Within this architecture, the IMS
is a central function that offers control capabilities for managing multimedia
session in a secure, controllable, QoS ensured, and chargeable manner.


## 2.2. The IP Multimedia Subsystem

The initial
specifications of the IMS are defined by 3 GPP [5] and they are based on the
Internet protocols standardized by IETF and then adapted by the ITU-T, ETSI, and
PacketCable 2.0 [9] to the NGN architecture and the cable TV network
infrastructure. The IMS functions are distributed among six control components:
first, the control components include the CSCFs (Call Session Control Functions)
responsible for the session management and the registration of the IMS
subscribers, the GCF (Gateway Control Function) controlling the gateway to the
circuit switch networks and the Media Resource Function Controller (MRFC),
controlling the media resource functions. Second, the media processing
components cover the Media Gateway and the MRFP (Media Resource Function
Processor) for supporting media capabilities such as playing or recording short
announcements, conferencing, transcoding, and DTMF detection. Third, the
HSS/UPSF (Home Subscriber Server)/(User Profile Subscription Function) is in
charge of the management of user and service profiles. Fourth, the application
servers host and execute new value added services in addition to the basic IMS
services. Fifth, the PCRF (Policy and Charging Rules Function) maintains the
allocation of the quality of service and applies the required policies on the
transport and the access network and is responsible of charging. Finally, the
IMS subscribers interact with the IMS elements using the protocols SIP (Session
Initiation Protocol), HTTP and RTP (Real-time Transport Protocol) over the
interfaces Gm, Ut, and Mb.


## 2.3. Multimedia Broadcast Multicast Services (MBMSs)

Whereas the
classical cellular network is primarily voice centric based on a point-to-point
communication model, the emerging multimedia scenarios mandate the need for
supporting broadcast and multicast transmission capabilities. In order to
address these new requirements, 3 GPP has extended the core network and the
radio interfaces in release 6 to support efficient broadcast and multicast IP
packet delivery. MBMS allows two modes of operation: the broadcast mode and the
multicast mode. In broadcast mode, transmissions take place regardless of user
presence in a defined area, whereas in multicast mode solely those areas are
supplied where subscribers need to be served. Concerning the radio interface
point-to-multipoint transmissions in downlink direction are introduced in order
to optimize radio resources. In the core network, the MBMS makes use of
application-based multicast instead of IP multicast. In comparison to previous
3 GPP releases, the Broadcast/Multicast Service Centre (BM-SC) is introduced as
a complete new functional entity serving as central controlling unit. It is
connected to the GGSN (Gateway GPRS Support Node) over the interfaces Gmb and
Gi. The former interface provides access to the control plane functions, the
latter to the bearer plane.


## 2.4. Digital Video Broadcasting (DVB)

The Digital Video Broadcasting (DVB) standard was designed
to broadcast digital TV services and it has been maintained by the DVB project
since 1993 [13]. DVB systems transmit data using a variety of approaches: over
satellite (DVB-S), cable (DVB-C), terrestrial (DVB-T), and handheld (DVB-H). As
DVB-T is mainly targeted at stationary receivers and is not suitable for mobile
devices, the DVB-H standard was proposed, which enhanced the physical and link
layers of DVB-T to reduce power consumption and improve performance in urban
indoor environments. While DVB is initially designed to support broadcast
transmission, there are several standardized solutions such as DVB-RCS (Return
Channel Satellite), DVB-RCT (Return Channel Terrestrial) or DVB-RCC (Return
Channel Cable) or DOCSIS (Data Over Cable Service Interface Specification) that
have been developed to facilitate bidirectional communication channel thus
supporting interactive applications (e.g., VoIP or VOD).The efforts of DVB-IPTV [14], the collective name for a set
of open, interoperable technical specifications, developed by the DVB Project,
in order to facilitate the delivery of digital TV using the Internet Protocol
over bidirectional fixed broadband networks is the DVB project’s answer to
current activities in the sphere of IPTV. In addition to DVB’s interactive
middleware specifications, DVB-MHP (Multimedia Home Platform) and GEM (Globally
Executable MHP) [15], which also include IPTV profiles, give the DVB Project a
good standing in the IPTV world. However, it acts still as broadcast technology
and concentrates on enhanced IPTV with n-play scenarios (beyond
triple/quadruple play) but with open Internet distribution. Thus, operators
will probably never take DVB into account when it comes to personalized
interactive scenarios where AAA and QoS are to be taken in consideration.


## 2.5. Open IPTV Forum

The Open IPTV Forum (OIPTVF) is an industry joint and has 5
key goals: creation of an end-user mass market for IPTV, acceleration of
introduction and deployment, ease the integration of end-to-end IPTV solutions,
creation of IPTV services and harmonization of IPTV infrastructure and, service
development. OIPTVF follows two approaches: managed networks with triple play
walled garden and open Internet with portal walled garden. The currently
released documents of this forum are mainly concentrated on requirements and
first architectural approaches which include 3 key entities: Open IPTV Terminal
Functional (OITF) Entity, IMS Gateway Functional Entity (IG), and Application
Gateway Functional Entity (AG). A main focus is the integration of the home
domain (via DLNA/UPnP [16, 17]) into a fully fledged IPTV solution.


## 2.6. Related Work

Various research
efforts tackle the problems of multimedia delivery over IP networks. An
IMS-based architecture to deliver TV services has been introduced in [18].
Although the authors discussed the interfaces between the user equipment (IPTV
Terminal Function) and the network side comprehensively, the paper does not
explain how the IPTV service controls the media delivery components (media
servers) for content delivery and media processing (if it is required).
Furthermore, it is not clear how the content provider, the service provider,
and the network operator could be smoothly involved in the value chain of the
content delivery. Within the Ambient Networks project [19], a service specific
overlay networking for adapting multimedia content has been designed, which is
based on a peer-to-peer communication model for service discovery and service
path management for media delivery [20]. The authors introduce the integration
of the overlay networking for media processing into the IMS session, while
assuming that the end terminals are part of the overlay network and the IMS
network. Since the overlay network, called service-specific overlay network
(SSON), provides already end-to-end session management, the integration of the
IMS session will introduce additional delay to the session setup between
session participants. Unfortunately, the paper does not provide any evaluation
result for this concept. The authors of [21, 22] outline motivations and
benefits as well as technical challenges of IMS-based IPTV solutions. Among the
benefits, they count the provision of a common infrastructure, common identity
management, and common charging, whereas they present challenges such as
broadcasting/multicasting, session management, and negotiation of media
parameters. Our implementation addresses these challenges using MBMS for
multicast/broadcast, a Session Management Enabler (SME) for session control and
using SDP together with SIP for media parameter negotiation, respectively. The
authors of [22] also present an architecture to provide IMS based IPTV
according to ETSI-TISPAN deployed in the ScaleNet project [23] consisting of
functional elements and the description of basic call flows to provide IMS
based IPTV according to ETSI TISPAN. Their work describes a novel IPTV service named
“Click to Multimedia Service.”


## 3. IMS-Based Overall Architecture

Based on the
TISPAN and the ITU-T NGN architecture (see Figure1), we have developed an IMS-based framework
that enables the delivery of converged multimedia services merging IMS, TV, and
cross-fertilization services such as “video follow me,” “see what I see” or
“remote parental control.” Figure 2 depicts the architecture of the reference
implementation which has been recently deployed in the FOKUS Media
Interoperability Lab (MIL) [24]. The architecture follows the IMS layered model
and embodies five layers and two planes that will be described later in this
section. The layers include access and transport, content delivery function,
IMS-based service control function, and servicer enablers and applications. On
the other hand, the planes embrace the content provider and the end user.Figure 1
ITU-T and ETSI TISPAN NGN architecture.Figure 2
Reference implementation at the MIL.The access and transport layers include various access technologies as well as the IP
core network. The access layer should be capable of supporting bidirectional
communication over fixed (e.g., DSL and Cable TV) and wireless (e.g.,
UMTS/HSPDA, WLAN, and DVB-T/H) technologies, and at the same time enable the
delivery of IP packets via unicast or multicast transmission mode. The
transport layer is responsible for the provisioning of the IP addresses using
the NASS and routing IP packets along with RACS that manages the required
resources on the access as well as on the IP core.The content delivery control function (CDCF) is realized through a set of distributed media servers so-called Content Delivery and Storage Function (CDSF) that
provide media processing and content delivery from the content provider to the
consumers. Media processing includes transcoding, caching, editing, content
injection (e.g., for advertisement), encrypting, and so forth. Content delivery
covers relaying content from one input channel to one or a set of output
channels (e.g., from a unicast to a multicast leg), linear content streaming or
with trick function support controlled with the RTSP protocol, content fetching
from the content provider via FTP or HTTP, content downloading over unicast or
multicast bearers via FTP or FLUTE protocol, respectively. Most of these
functions are implemented based on the GStreamer libraries [25].The IMS-based control function covers the IMS core elements, namely, the CSCFs, the MGC,
the MRFC,  the MGC (the later three
elements are not depicted in Figure 2), and the HSS. In order to control the
CDSFs, a new element called Content Delivery Control Function (CDCF) is
introduced. It enables the application servers to trigger all media processing
and delivery functions exposed by the CDCF via the SIP protocol based on the
RFC4240 [26]. In our implementation, the control interface is implemented based
on the Sofia-SIP Library [27] that extends the
media server with an SIP interface, whereas the CDCF controls the CDSF via APIs
and thus they are deployed in a single node. The FOKUS open IMS core is used as
a reference implementation of the CSCFs and the HSS [28].The service enablers are represented through a set of service blocks where each one of
them provides an internal functionality used by the end-user or other service
enabler. The design of these enablers follows the Open Mobile Alliance (OMA)
approach [29]. The realization of each enabler is deployed as standalone entity
or hosted within an Application Server (AS) that provides an execution
environment as well as resource management. FOKUS has developed several types
of application servers such as the SIP Servlet Execution Environment (SIPSEE)
[30], which is based on SIP and HTTP Servlet technologies and supports the IMS
Service Control (ISC) interface. On top of the SIPSEE platform, the following
enablers are deployed.(i)
Session manager enabler (SME) performs all related
service control and session management for delivering TV services [31]. The SME
is in charge of session setup of live TV or Video-on-Demand content, bearer
selection, mobility across several access networks, group management, and
triggering the media delivery plane for content processing and delivery.(ii)
Content management enabler (CME) is responsible for the
life cycle of the content. It covers the relationship with the content
provider, content discovery and delivery from the content provider to the
network delivery elements for further processing or content storage.(iii)
Service provisioning enabler (SPE) provides consumers
with the information related to TV service provisioning such as the Electrical
Programming Guide (EPG) and enables the consumer to discover the available
services and related content.(iv)
Digital rights management server is in charge of the
management of content licenses and related keys for content encryption and
decryption. However, other security related issues such as authentication,
media authorization or data integrity are covered by lower layers such as the IMS
or IP layer.
In order to manage users’ availability and current activity (e.g., the current TV channel
being watched), we can use the Presence Server along with the XML Document
Management Server (XDMS) repository to store user data. Both servers are
implemented and deployed on the top of the IMS core as standalone application
servers. Sharing the current activity of any multimedia application among end users
will improve the social characteristic of the service and will increase the
service or content popularity within user communities.The application layer covers applications that provide customized and
interactive services to end users. Applications may compose a set of service
enablers and provide this as a bundled offer. To access the basic functions of
the service enabler open and standardized interfaces need to be defined. To
enable this vision, OMA Service Environment or Parlay X approaches can be
applied. This will allow opening IMS services and IPTV services towards Web 2.0
and third party service providers. Furthermore, advanced interactive
applications related to live TV programs or VOD sessions could be realized
straightforward (e.g., voting, personalized advertisement or shopping).The content provider plane presents the content provider (professional or user
generated) who produces and offers multimedia content. It is the source of all
types of multimedia content including live or stored content. For content
delivery this plane interacts with all layers via the available reference
interfaces defined by the IMS towards the IMS subscriber, namely the Gm, Mb and
Ut interfaces. This will enable end users to behave as content providers.The End-User plane presents user premises to consume the service offer and interact with
the system elements. End-user equipment could interconnect to any wired or
wireless access technologies and enables the user to get IP connectivity
directly or via an intermediate home gateway hosted at user premises. Such
gateway would offer the user the ability to build up a meshed network within
his home environment based for instance on WLAN, Bluetooth or sensor network.
This plane communicates with the IMS-based network through the Gm, Mb, and Ut
reference points.For framework
management the TISPAN NGN operation supporting subsystem (OSS) specification
can be applied where the main principles and concepts for managing NGN elements
have been included and mapped within ITU-T approved Recommendation M.3060 “Principles
for the Management of Next Generation Networks.” However, TISPAN release 2 will
define the end-to-end data model to cover all the mandatory and optional
information related to NGN element provisioning.Based
on the functionalities provided by these service enablers, we have implemented
interactive applications like network initiated voting requests (interactive
quiz show), personalized targeted advertisement with embedded shopping
information with integrated shopping portal (see Figure3), and “see what I
see” home content sharing with content pushing capabilities (see Figure 4).Personalized targeted advertisement
with embedded shopping information (a) and shopping portal (b).
(a)(b)Surfing the home media
content (a) and pushing the home media content to my contacts (b).
(a)(b)


## 4. Framework Validation

Based on the
design principles of the logical architecture discussed in the previous
section, we would like to present a proof of concept implementation, which is
integrated in the FOKUS Media Interoperability Lab (MIL) [24] that has been
validated through several demo applications. This section first presents an
end-to-end content delivery scenario and later discusses the related end-to-end
delay values for session setup obtained by practical experiments.


### 4.1. End-to-End Content Delivery Scenario

In this
subsection, session establishment for an end-to-end content delivery scenario
over a unicast or a multicast transmission mode is presented. The end-user
terminal (either a set-top box or a mobile device) is a full IMS subscriber
that performs the default IMS registration upon startup.Figure5 shows
the general sequence flow of the session setup. When the terminal is switched
on, it first obtains IP connectivity and a valid IP address via DHCP, Packet
Data Protocol (PDP) context activation or static configuration (step 1). Then,
the terminal discovers the address of the P-CSCF and then performs the IMS
registration request (step 2). Once the registration is finished, terminal
provisioning of all available IMS and TV services with related configuration
parameters such as Public Service Identifier (PSI) and Electronic Programming
Guide (EPG) is performed through pull, push or subscribe/notification mechanisms
(step 3). Once the user starts the live TV service (step 4), the terminal sends
an invite request towards the IMS core network, where the AS triggers the CDCF
to relay the corresponding content from a particular content source to the end user
(steps 5 to 7). After content delivery is finished or upon user decision the
session is terminated by issuing a BYE (steps 8 and 9). A more detailed description
of the signaling flow between the service enablers and the IMS is illustrated
in Figure 6.Figure 5
Session setup of a live TV service.Figure 6
End-to-end messages flow of a live TV session.Figure6
illustrates the detailed sequence flows between user terminal, the service
enablers, and the IMS-based network. It shows two IMS subscribers (Alice and
Bob) with a set-top box or mobile terminal equipped with an IMS SIM (ISIM) card
containing one IMS Private Identity (IMPI) and at least one IMS Public Identity
(IMPU). We assume that Alice and Bob are subscribed to an IMS-based live TV
service whose service profiles with the required configuration information are
stored on the HSS. The scenario is divided in three phases. In the first phase
once Alice
starts the live TV service, the terminal sends an SIP invite request carrying
the PSI of the live TV service, the channel name, and terminal capabilities
(step 1). Based on the PSI, the S-CSCF routes the request to the SME deployed
on the SIPSEE AS. The SME checks first if this channel has been already
requested by any user beforehand, which is not the case in this scenario.
Therefore, it inquires the CME to obtain this content from the content provider
and prepare it for delivery.The CME behaves as an SIP back-to-back user agent between the CP and the
CDCF. It requests the CDCF to initiate a “prepare for relay” session via an SIP
Invite message that includes the following.(1)
The SIP URL of the relay service (e.g.,relay@CDCF-ims-domain.com),
following the RFC 4240 [26].(2)
A new content ID that identifies the
relay session for further requests.(3)
Media parameters as media codecs, IP
address, and ports offered by the CP.
After the SME receives the internal content ID from the CME, it triggers the CDCF to relay
this content to Alice's unicast IP address or IP multicast address (if multicast
is supported on the network and on Alice’s device), indicating the internal
content ID to identify the relay session (steps 4-5). The relay session
parameters offered by the CDCF are forwarded to Alice's terminal. Once Alice's terminal receives the 200 OK message,
it will allocate the required local ports (or will join a multicast group if
required) to receive the content stream (steps 6-7).Now Bob requests
the same TV channel. Likewise, the Invite message is routed through the IMS
core to the SME. Since the TV content is being already streamed from the CDCF,
the SME does not initiate another prepare for relay session with the CDCF. In
case both Alice and Bob are using the same multicast bearer to receive the
content, the SME will provide Bob with identical session parameters as Alice. Otherwise (steps 9–11), the SME will
trigger the CDCF to relay the TV channel to Bob’s terminal by inserting Bob’s
session parameters and the content ID. Later, based on the CDCF response, the
SME will forward to Bob the session parameters of the allocated bearer (steps
12-13).When the user
switches to a new channel or session parameters change, an SIP reinvite message
is used (not illustrated in the last sequence diagram). Since the SME keeps
track of the user’s current channel, advanced interactive applications such as
voting or shopping might be provided. The SME enables third party applications
to attach the necessary related metadata within a dedicated channel (e.g., live
TV). To deliver such information, our implementation uses the SIP message or
the SIP Info messages. In order to improve efficiency and lower latency in
channel-change scenarios, a multicast signaling channel in the IGMP protocol or
in-band signaling attached to the content streams can be used following the
approach proposed in [21].


### 4.2. Performance Measurements

To estimate the
end-to-end delay for session set-up, we measured the triggering latency between
the request initiation and the reception of the SIP 200 OK response message as
defined in the previous subsection. We have not mentioned here the SIP ACK
message in order to keep the call flow clearly arranged. Once the SME receives
the first request for a particular TV channel, the CDCF is triggered to accept
the content stream as an input for the relay session, thereafter the SME
requests the CDCF to relay this stream to the user over a unicast or a
multicast bearer. Further users’ request for the same TV channel requires that
the SME initiates only one SIP invite request for each request and this is the
case, only if a unicast bearer is used for each request. As explained in Section4.1, in case of
multicast bearer (decided by the SME internally), the SME already knows the
initialized IP multicast address and responses with this address without
signaling towards the CDCF again.The aim of the performance
measurements is to determine the total signaling delay (denoted in Figure6
with Dtotal) including the round trip time of the first RTP packet.
The time for setting up the stream towards the CDCF and relaying to the user is
denoted as Dsig (see Figure 6).We consider a test
scenario setting up one single session for content delivery towards CDCF
(prepare for relay) and a unicast transmission session for each user request
(relay).The testbed setup
is illustrated in Figure7, as follows.Figure 7
Testbed setup.(1)
Users are emulated by a testing tool called SIPNuke [32],
which is developed at FOKUS and can generate thousands of SIP requests
with various rates, receive RTP traffic and log the corresponding
statistics.(2)
The FOKUS Open IMS core
covering the P-/I-/S-CSCF and the HSS is deployed on one machine with
Intel Core 2 Duo at 2.2 GHz with 4 GB RAM.(3)
The SME/CME is hosted and
executed on the SIPSEE deployed on an Intel Core 2 Duo at 2.2 GHz with 4 GB RAM.(4)
The CDCF is the FOKUS implementation described in Section3. It is deployed on Intel Core 2 Duo at 2.2 GHz with 4 GB RAM.(5)
The content provider is emulated through a VLC (Video LAN
Client) [33], which streams movies in MPEG-TS streams over unicast connections
to the CDCF. The VLC runs on Intel Core 2 Duo at 1.8 GHz with 1 GB RAM. These nodes are connected via a Fast-Ethernet
LAN (100Base-T) network, where 6 hops between user terminals and the SME/CME, 2 hops between the SME/CME and the CDCF, 1 hop between the CP and the CDCF, and 6 hops between the CDCF and user terminals.Figures8, 9, 10, and 11 depict different measurements calculated on the client with increasing
calls per second rates. The total session delay Dtotal is depicted
in red and the signaling delay Dsig is depicted in blue. The total
number of simultaneous sessions for each realization is represented in the
horizontal axis. The duration of each media session is 10 seconds, where the
client receives RTP traffic then issues the SIP Bye message to terminate the
session. Each delay value in the graphs corresponds to the median of series of
repeated 10 measurements. Regarding the Dsig value, the measurement
is done when the first 200 OK arrives at the user terminal. This duration is
the sum of the network delays over the tested communication media and the
processing delay induced by the IMS core network, the SME and the CDCF. Respectively,
the Dtotal depicts the time when the first RTP packet arrives at the
user terminal. This is not taking into account when the first complete video
frame is to be displayed at the terminal. In the case of the MPEG2 video
encoding the first complete frame is displayed as soon as the
first “I” frame
is decoded.Figure 8
Session delay at 3 cps.Figure 9
Session delay at 5 cps.Figure 10
Session delay at 7 cps.Figure 11
Session delay at 10 cps.


### 4.3. Discussion

As
we see in the measurements, from a certain total simultaneous number of
sessions (here from 60 up to 100), both signaling and total delay grows
constantly slowly on a rate of 3 and 5 call per second. On a rate of 7 and 10
the delay increases gradually at the beginning and then exponentially after
reaching the middle of the horizontal axis. Within this context, we lean on the
ITU-T Recommendation G.114 [34] and adopt its recommendations to the issue of
session establishment delay researched in this paper. Reference [34] defines the
level of acceptance for mouth-to-ear delay as not to exceed 200–280 milliseconds to
keep all users very satisfied or satisfied. Based on these results we should
make four important observations.(i)
The signaling delay plays a
significant impact on the total delay where several nodes are involved in the
signaling path including the UE, IMS core, the SME/CME, and CDCF.(ii)
The delay of the first request
(clearly seen in Figures8 and 9) is always higher than in the following messages.
This is due to the relay session set-up between the content provider (VLC), the
CDCF, and the preparation of the related pipeline on the CDCF (steps 2 and 3 in
Figure 6).(iii)
Processing time on the SME/CME becomes
a big penalty at high rates. Especially when several sessions already exist on
the SME (more than 60 and 30 sessions for rates of 7 and 10 cps, resp.):
this leads to retransmission of previous requests (either Invite or Bye
messages) after a certain time. As a result of that, the actual rate of
received requests on the SME is much higher than the 7 or 10 cps and
consequently the measured delay increases exponentially.(iv)
As soon as the processing time on
the SME increases, retransmissions are triggered by the IMS core as well as by client
nodes even if the packet was successfully delivered, since the retransmission
timeout is smaller than the total latency.
The results indicate that: while the SME performs well under low call rate, the
latency would be at acceptable limit (less than 200 milliseconds) with a higher
request rate only if a load balancing process is applied for incoming requests.
However, this is not the case in the current implementation and so this issue
has to be considered for future work.


## 4.1. End-to-End Content Delivery Scenario

In this
subsection, session establishment for an end-to-end content delivery scenario
over a unicast or a multicast transmission mode is presented. The end-user
terminal (either a set-top box or a mobile device) is a full IMS subscriber
that performs the default IMS registration upon startup.Figure5 shows
the general sequence flow of the session setup. When the terminal is switched
on, it first obtains IP connectivity and a valid IP address via DHCP, Packet
Data Protocol (PDP) context activation or static configuration (step 1). Then,
the terminal discovers the address of the P-CSCF and then performs the IMS
registration request (step 2). Once the registration is finished, terminal
provisioning of all available IMS and TV services with related configuration
parameters such as Public Service Identifier (PSI) and Electronic Programming
Guide (EPG) is performed through pull, push or subscribe/notification mechanisms
(step 3). Once the user starts the live TV service (step 4), the terminal sends
an invite request towards the IMS core network, where the AS triggers the CDCF
to relay the corresponding content from a particular content source to the end user
(steps 5 to 7). After content delivery is finished or upon user decision the
session is terminated by issuing a BYE (steps 8 and 9). A more detailed description
of the signaling flow between the service enablers and the IMS is illustrated
in Figure 6.Figure 5
Session setup of a live TV service.Figure 6
End-to-end messages flow of a live TV session.Figure6
illustrates the detailed sequence flows between user terminal, the service
enablers, and the IMS-based network. It shows two IMS subscribers (Alice and
Bob) with a set-top box or mobile terminal equipped with an IMS SIM (ISIM) card
containing one IMS Private Identity (IMPI) and at least one IMS Public Identity
(IMPU). We assume that Alice and Bob are subscribed to an IMS-based live TV
service whose service profiles with the required configuration information are
stored on the HSS. The scenario is divided in three phases. In the first phase
once Alice
starts the live TV service, the terminal sends an SIP invite request carrying
the PSI of the live TV service, the channel name, and terminal capabilities
(step 1). Based on the PSI, the S-CSCF routes the request to the SME deployed
on the SIPSEE AS. The SME checks first if this channel has been already
requested by any user beforehand, which is not the case in this scenario.
Therefore, it inquires the CME to obtain this content from the content provider
and prepare it for delivery.The CME behaves as an SIP back-to-back user agent between the CP and the
CDCF. It requests the CDCF to initiate a “prepare for relay” session via an SIP
Invite message that includes the following.(1)
The SIP URL of the relay service (e.g.,relay@CDCF-ims-domain.com),
following the RFC 4240 [26].(2)
A new content ID that identifies the
relay session for further requests.(3)
Media parameters as media codecs, IP
address, and ports offered by the CP.
After the SME receives the internal content ID from the CME, it triggers the CDCF to relay
this content to Alice's unicast IP address or IP multicast address (if multicast
is supported on the network and on Alice’s device), indicating the internal
content ID to identify the relay session (steps 4-5). The relay session
parameters offered by the CDCF are forwarded to Alice's terminal. Once Alice's terminal receives the 200 OK message,
it will allocate the required local ports (or will join a multicast group if
required) to receive the content stream (steps 6-7).Now Bob requests
the same TV channel. Likewise, the Invite message is routed through the IMS
core to the SME. Since the TV content is being already streamed from the CDCF,
the SME does not initiate another prepare for relay session with the CDCF. In
case both Alice and Bob are using the same multicast bearer to receive the
content, the SME will provide Bob with identical session parameters as Alice. Otherwise (steps 9–11), the SME will
trigger the CDCF to relay the TV channel to Bob’s terminal by inserting Bob’s
session parameters and the content ID. Later, based on the CDCF response, the
SME will forward to Bob the session parameters of the allocated bearer (steps
12-13).When the user
switches to a new channel or session parameters change, an SIP reinvite message
is used (not illustrated in the last sequence diagram). Since the SME keeps
track of the user’s current channel, advanced interactive applications such as
voting or shopping might be provided. The SME enables third party applications
to attach the necessary related metadata within a dedicated channel (e.g., live
TV). To deliver such information, our implementation uses the SIP message or
the SIP Info messages. In order to improve efficiency and lower latency in
channel-change scenarios, a multicast signaling channel in the IGMP protocol or
in-band signaling attached to the content streams can be used following the
approach proposed in [21].


## 4.2. Performance Measurements

To estimate the
end-to-end delay for session set-up, we measured the triggering latency between
the request initiation and the reception of the SIP 200 OK response message as
defined in the previous subsection. We have not mentioned here the SIP ACK
message in order to keep the call flow clearly arranged. Once the SME receives
the first request for a particular TV channel, the CDCF is triggered to accept
the content stream as an input for the relay session, thereafter the SME
requests the CDCF to relay this stream to the user over a unicast or a
multicast bearer. Further users’ request for the same TV channel requires that
the SME initiates only one SIP invite request for each request and this is the
case, only if a unicast bearer is used for each request. As explained in Section4.1, in case of
multicast bearer (decided by the SME internally), the SME already knows the
initialized IP multicast address and responses with this address without
signaling towards the CDCF again.The aim of the performance
measurements is to determine the total signaling delay (denoted in Figure6
with Dtotal) including the round trip time of the first RTP packet.
The time for setting up the stream towards the CDCF and relaying to the user is
denoted as Dsig (see Figure 6).We consider a test
scenario setting up one single session for content delivery towards CDCF
(prepare for relay) and a unicast transmission session for each user request
(relay).The testbed setup
is illustrated in Figure7, as follows.Figure 7
Testbed setup.(1)
Users are emulated by a testing tool called SIPNuke [32],
which is developed at FOKUS and can generate thousands of SIP requests
with various rates, receive RTP traffic and log the corresponding
statistics.(2)
The FOKUS Open IMS core
covering the P-/I-/S-CSCF and the HSS is deployed on one machine with
Intel Core 2 Duo at 2.2 GHz with 4 GB RAM.(3)
The SME/CME is hosted and
executed on the SIPSEE deployed on an Intel Core 2 Duo at 2.2 GHz with 4 GB RAM.(4)
The CDCF is the FOKUS implementation described in Section3. It is deployed on Intel Core 2 Duo at 2.2 GHz with 4 GB RAM.(5)
The content provider is emulated through a VLC (Video LAN
Client) [33], which streams movies in MPEG-TS streams over unicast connections
to the CDCF. The VLC runs on Intel Core 2 Duo at 1.8 GHz with 1 GB RAM. These nodes are connected via a Fast-Ethernet
LAN (100Base-T) network, where 6 hops between user terminals and the SME/CME, 2 hops between the SME/CME and the CDCF, 1 hop between the CP and the CDCF, and 6 hops between the CDCF and user terminals.Figures8, 9, 10, and 11 depict different measurements calculated on the client with increasing
calls per second rates. The total session delay Dtotal is depicted
in red and the signaling delay Dsig is depicted in blue. The total
number of simultaneous sessions for each realization is represented in the
horizontal axis. The duration of each media session is 10 seconds, where the
client receives RTP traffic then issues the SIP Bye message to terminate the
session. Each delay value in the graphs corresponds to the median of series of
repeated 10 measurements. Regarding the Dsig value, the measurement
is done when the first 200 OK arrives at the user terminal. This duration is
the sum of the network delays over the tested communication media and the
processing delay induced by the IMS core network, the SME and the CDCF. Respectively,
the Dtotal depicts the time when the first RTP packet arrives at the
user terminal. This is not taking into account when the first complete video
frame is to be displayed at the terminal. In the case of the MPEG2 video
encoding the first complete frame is displayed as soon as the
first “I” frame
is decoded.Figure 8
Session delay at 3 cps.Figure 9
Session delay at 5 cps.Figure 10
Session delay at 7 cps.Figure 11
Session delay at 10 cps.


## 4.3. Discussion

As
we see in the measurements, from a certain total simultaneous number of
sessions (here from 60 up to 100), both signaling and total delay grows
constantly slowly on a rate of 3 and 5 call per second. On a rate of 7 and 10
the delay increases gradually at the beginning and then exponentially after
reaching the middle of the horizontal axis. Within this context, we lean on the
ITU-T Recommendation G.114 [34] and adopt its recommendations to the issue of
session establishment delay researched in this paper. Reference [34] defines the
level of acceptance for mouth-to-ear delay as not to exceed 200–280 milliseconds to
keep all users very satisfied or satisfied. Based on these results we should
make four important observations.(i)
The signaling delay plays a
significant impact on the total delay where several nodes are involved in the
signaling path including the UE, IMS core, the SME/CME, and CDCF.(ii)
The delay of the first request
(clearly seen in Figures8 and 9) is always higher than in the following messages.
This is due to the relay session set-up between the content provider (VLC), the
CDCF, and the preparation of the related pipeline on the CDCF (steps 2 and 3 in
Figure 6).(iii)
Processing time on the SME/CME becomes
a big penalty at high rates. Especially when several sessions already exist on
the SME (more than 60 and 30 sessions for rates of 7 and 10 cps, resp.):
this leads to retransmission of previous requests (either Invite or Bye
messages) after a certain time. As a result of that, the actual rate of
received requests on the SME is much higher than the 7 or 10 cps and
consequently the measured delay increases exponentially.(iv)
As soon as the processing time on
the SME increases, retransmissions are triggered by the IMS core as well as by client
nodes even if the packet was successfully delivered, since the retransmission
timeout is smaller than the total latency.
The results indicate that: while the SME performs well under low call rate, the
latency would be at acceptable limit (less than 200 milliseconds) with a higher
request rate only if a load balancing process is applied for incoming requests.
However, this is not the case in the current implementation and so this issue
has to be considered for future work.


## 5. Conclusion

This paper
presented the current standardization activities in the sphere of IMS-based
IPTV. It described a novel end-to-end overall architecture that is based on the
IMS and enables the delivery of converged multimedia services over unicast,
multicast, and broadcast transmission modes following the approaches from ITU-T
and TISPAN. The framework provides advanced session management functionalities
and at the same time it presents an infrastructure that identifies all players
in the value chain: from the content provider to the network operator and to
the end user. Services proposed in order to embed interactivity and
personalization in the platform have been identified, plus we have shown how
the framework supports emerging services such as personalized services, on-line
voting or other service enablers to help users discover contents from a vast
media database. The related components in such architecture are presented. A
model for framework validation and a general performance scenario and related
measurement result has been described and discussed.Future work in
this research direction involves scalability, load balancing, distributed
management, and media processing: this includes for instance how to distribute
the multimedia processing across multiple CDCFs or how to store the media
contents among different CDCFs or network nodes. The capabilities of the NGN
and IMS in terms of distributed architecture will ease the deployment of IMS
based NGN networks in the near future. Nevertheless, further steps besides the
ease of content discovery and the provision of user interactivity are the
integration of context information to form ad hoc groups in a community sense.
This requires matching mechanisms of context to content. To make the promising community
services more attractive, the integration of applications which support the
shared multimedia experience (application sharing, white boarding, etc.) need to
be investigated.



---

*Source: 843270-2008-12-22.xml*