Enhancing the IPTV Service

Architecture to Enable Service

Innovation
Anne Bodzinga
Network Architect, Broadband Access
Lucent Technologies

Susan White
Senior Manager, Broadband Access
Lucent Technologies

Marcus Weldon
Chief Technologist for Broadband Solutions, Bell Labs
Lucent Technologies

Abstract

As a result of the intense competition for broadband access services, most service providers are
planning to deploy—or are already deploying—IPTV services in a bundled service offering. This
evolution in service offerings is necessary to maintain customers, grow market share, and
increase the profitability of broadband services. The inevitable effect, however, of migrating to a
triple play service package is the increased complexity of the service architecture as each new
service (e.g., IPTV, VoIP) has its own unique service-control framework and operations and
billing support systems (OSS and BSS). In addition, service providers need to consider how to
differentiate their triple play offerings from other providers who also plan to deploy bundled
service offerings. The inability to differentiate could lead to a reduction in average revenue per
user (ARPU) as the perceived end-user value is eroded by simple discounting of combined
(bundled) service packages. This paper describes these concerns and how they can be overcome
by migrating to a common service architecture based on IMS. The paper also details some of the
new blended services that are enabled by service convergence and that can lead to an overall
increase in revenue as well as a decrease in capital and operational expenditures incurred by the
service provider.

Service Architecture Complexity

Initial Focus on the Internet

Residential broadband access networks were initially built to enable high-speed access to the
Internet. The service architecture is typically based on a centralized broadband remote access
server (BRAS) that terminates Internet traffic encapsulated in PPPoA/PPPoE and provides per-
user authentication and IP address assignment as well as service level agreement (SLA)
enforcement by user flow classification and metering. The BRAS typically has a direct interface
into the remote authentication dial-in user service (RADIUS) server to provide per-user
authentication, authorization, and accounting (AAA). Today, the majority of residential user data
services are “best-effort” with a maximum bandwidth constraint (to prevent one user from
commandeering all available network resources), but typically have no minimum service
guarantees.

However, service providers are increasingly finding that a pure Internet play for broadband access
providers is no longer economically profitable. Many cable TV operators are now offering full
triple play services from their fiber-coax–based networks, and over the last 12 months,
competitive carriers have benefited from the reduced costs of DSL local loop unbundling (ULL)
and plan to compete with incumbent providers to offer triple play services. In addition, voice
revenues for incumbent telecommunications providers are continuously eroding as more
customers migrate to mobile or Internet-based telephony. This intense competition has resulted in
a pronounced move toward new triple play services offerings with IPTV as a clear new service
goal since it provides access to the substantial additional revenue per subscriber ($20–$80)
associated with TV and video services, and it also helps stabilize revenues associated with
traditional voice and data services by decreasing subscriber “churn” to other service providers.

Adding VoIP to Internet Access

Many service providers plan to launch new VoIP service offerings coupled with Internet service
offerings initially over broadband access. The IP multimedia subsystem (IMS) architecture—an
evolution of the softswitch concept involving further disaggregation of elements and support for
different service types—is emerging as the service architecture to support voice and multimedia
services in a converged network.

Using this architecture, VoIP services will be provided using dedicated VoIP phones or
softclients, or regular phones with gateway functionality on the customer premises equipment
(CPE). VoIP packets are directed across the access and aggregation network in a VoIP VLAN—
with appropriately defined quality of service (QoS) parameters—to the session border controller
(SBC). The SBC functions as a SIP back-to-back user agent (BBUA) providing security, NAT
traversal, and other functions. Authentication and session control will be provided by the IMS
platform (via interfaces to AAA servers) with access to common billing and operations systems.
Guaranteed, “circuit-like” quality of service with low delay and jitter (variation in delay) is
required for this service.

Migration to IPTV
IPTV services are much more challenging to offer than Internet access or voice services and can
considerably change the requirements of the rest of the broadband access network. This is mainly
because of the fact that video-based services require higher average bandwidth and higher quality
of service than typical unicast or multicast “data” services as well as different QoS from voice
services (there is lower tolerance for packet loss with video, but higher tolerance for delay for at
least some video services). The migration to IPTV services imposes many associated architectural
changes on the network, as follows:

• Deployment of new triple play–capable DSLAMs based on Ethernet rather than ATM
• More advanced CPE to handle multiple high- and low-quality services
• Deployment of new service platforms, e.g., IPTV and VoD software (“middleware”) and
applications suites
 • Evolution to next-generation access networks such as fiber to the node (FTTN) or fiber to
the premises (FTTP) to significantly increase the per-user bandwidth and service
coverage
• Migration to Ethernet aggregation networks (from ATM over SONET/SDH) to support
high bandwidth multicast and unicast traffic distribution

Many of these migration steps have already taken place for some service providers, such as
Telefonica and Bell Canada. SBC, Deutsche Telecom, British Telecom, and many other providers
are beginning this migration now or in the near future.
.

The specific service architecture for IPTV services depends on the video service type:
specifically, whether the services are “on-demand,” e.g., video on demand (VoD) or broadcast-
type video and TV.

For VoD services, the user selects the video program he or she wishes to watch, and an RTSP
control message is sent directly to the VoD server or middleware platform. The VoD middleware,
used for control and service intelligence, provides the user authentication for the service and
communicates with the video server to start streaming the video—with the requisite digital rights
management (DRM)—upon successful authentication. These video servers will be regionally or
centrally located, depending on the anticipated demand for the stream.

Maintaining high service quality is essential for these services. In particular, low packet loss per
stream; the service scalability to be able to process and stream thousands or tens of thousands of
simultaneous requests for popular streams; and high network resiliency (restoration times for
premium services on the order of a second or less) are of prime importance.

For broadcast services, when the user changes to a new channel, the set-top box (STB) associated
with the TV sends a “join” message to the DSLAM or fiber access node, using a multicast group
protocol such as IGMP. If the channel is not currently available at the DSLAM, the request is
propagated to the next hop in the distribution network, which is typically an Ethernet/VPLS
switch in the aggregation network. If the channel is unavailable at that location, the request is
further forwarded to the multicast edge router, which will join the multicast group using a PIM
(protocol independent multicast) message to the root of the multicast distribution tree.

Channel authentication can be performed in the STB (if the software client can support filter
criteria), in the home gateway, using per-port filtering, or in the broadband access node, using
per-port access control lists (ACLs). More sophisticated authentication can be performed using
conditional access systems (CAS), either in the broadband access node or external elements such
as BRAS or the edge router devices.

Simplifying the Service Architecture

From a network perspective, the result of adding more value-added services is a more complex
service architecture since each service, as described above, has its own unique service
requirements. This results in a multiplicity of systems with disparate methods for authentication,
and multiple databases for user information, billing and operations systems (BSS/OSS), control
architectures, and methods for QoS enforcement (if any).
 Data IMS IP Video
Services Services Services
• Web browsing • Voice and Video Telephony • Broadcast TV
• E-mail • Location-based services • Video on demand
• Instant Messaging • Messaging services • Pay-per-view
• Streaming services • Presence-based services • Programming guide
• “Converged” wireline/ • “Combined” services
(e.g., Caller ID on TV,
wireless services Web on TV)

Wireline or Wireless
IP Access

VoIP Phone
Mobile Devices Set Top Box
TV Monitor
PC

Figure 1: Architecture per Service

Deployment and support for these systems result in an increase in OPEX and CAPEX costs as
multiple systems have to be purchased, deployed, supported, and upgraded. Furthermore, given
the uniqueness of the various systems, their complexity, and the proprietary or closed or hidden
internal interfaces between functional service elements, there is little or no possibility of
coordinating these multiple service delivery platforms to offer differentiated service “blends,” as
described in the section below.

However, it is also important to recognize the pragmatic need to work within the existing service
provider OSS/BSS framework as much as possible; the goal, therefore, must be to maintain the
service platforms as they exist today but to combine certain functions to simplify the service
delivery and create a flexible network for new services. There are several important categories of
elements that can be combined or used in combination:

• User subscription and authentication information, e.g., AAA functions, service package
or SLAs
• Call and session control, e.g., registration of users and devices, connection and
termination of call or path, and call feature handling
• Bandwidth and QoS control, e.g., policy decision communication to network elements
• Service delivery platform, e.g., user self-provisioning portals, application or asset
management functions, and interfaces to OSS/BSS systems
• Applications, e.g., voice applications leveraged in IPTV networks, IPTV applications
leveraged in mobile telephony networks, etc.

These elements and a recommended common services architecture will be discussed in detail
later in this paper.

From Bundled Services toward Blended Services

Service bundling over broadband access is a requirement for most service providers in order to
retain customers. For many incumbent telcos—in countries with high ULL activity and active
competition from cable TV MSOs—the churn rate for broadband access is increasing rapidly and
needs to be controlled by the service provider in order to reduce the OPEX associated with
attracting subscribers (cost = advertising), retaining subscribers (cost = discount promotions), and
then provisioning subscribers (cost = person-hours). Clearly, it is also important to have a stable
revenue base in order to be able to support ongoing network maintenance and evolution.

Another benefit of bundling is the ability to simplify billing in that a single bill can be sent to the
subscriber. This creates some low-level customer loyalty (as long as one’s competitors do not
offer the same facility across all services) and slightly reduced BSS costs, but it does not address
other OPEX costs associated with maintaining multiple networks and systems as described in the
previous section. However, the major concern of bundling services, other than the fact the OPEX
costs are not truly minimized, is that all other service providers can support the same triple play
“bundle” offering. Therefore, the ability to differentiate on services becomes difficult, with (low)
price differentiation being the only alternative, which, in turn, results in a decrease in the average
revenue per user.

However, by taking the concept of convergence further than simple billing convergence to true
services convergence, service providers can provide a whole new set of blended services that
uniquely enhance the user experience and that can offset the erosion of bundle package value and
actually result in a net increase in the ARPU as shown in Figure 2.
Triple Play Subscriber Revenue

Blended services:
40% increase in revenue per year,
increasing value per year

Bundled services:
Increasing revenue in near term,
decreasing value in long term

2004 2005 2006 2007

Year

Figure 2: Blended Services versus Bundled Services Revenue Progression

Seamless blending of voice (wireline and wireless), video (IPTV), and data services will
maximize revenue potential by offering new services that are created by integrating or
interleaving existing services to form new blended service packages. As a simple example, if a
user is watching TV and receives a voice call, the caller ID can be overlaid on the television using
simple network intelligence that knows the user receiving the call is currently watching TV and
has client-side STB functionality that allows interpreting of the caller ID message and overlaying
it on the TV screen for a predetermined period of time. The support of this feature, without
requiring any additional caller ID–specific hardware, represents an enhanced service to many
users for whom the existence of extra devices in the home is anathema. However, even more is
possible: if the user decides to accept the voice call, the network could automatically store or
pause the viewed program at the current location until the call is completed, at which point an
option to replay the program from where the user left off can be provided in the form of another
“alert” message overlaid on the screen. This seamless interplay of voice services (caller ID), with
video (TV viewing), video storage functions (so-called network PVR), and messaging (the replay
“alert”) represents a truly enhanced user experience.

More detailed examples of such “blended” services will be provided later in this paper, but
broadly, the ability to provide this type of service blending will create a “user-centric” paradigm
with the following attributes:

• The network will become more intelligent, capturing user context, location, multimedia
session status, and more
• Users will define and control their own experiences with multiple personas, profiles, and
preferences accessible from any location (e.g., business or home; cell phone or TV)
• Users will have ubiquitous access to all their services anywhere, anytime, independent of
devices and different network types

From the service provider perspective, the end result of all this user-control and personalization is
an increase in the monthly ARPU and the ability to clearly differentiate service offerings. In
addition, such blended services will help the service provider maintain relationships with
subscribers regardless of how they access the network. The enabler for these types of services is a
common service architecture that will be described in the next section.

Common Service Architecture

Using IMS as the Common Service Architecture

In the previous sections, we identified two major advantages of migrating to a common service
architecture:

• OPEX and CAPEX reductions by simplifying and streamlining the service architecture
• New revenue opportunities and service differentiation by enabling service convergence

To simplify the service architecture, it is necessary to eliminate unnecessary duplication of certain

functions. For example, in today’s triple play networks, a user has to login or interact with several
different applications and associated control platforms. In addition, data is replicated across
applications, resulting in multiple instances of user profiles and preferences. Any interaction
between applications must be dealt with by each application in a pair-wise manner. This is shown
in Figure 3 on the left side.

To avoid this complexity, a separation of the transport and endpoint layer from the session control
layer (which is then access-agnostic) is required. This results in a common session management
function that can be used to provide session control across multiple services and applications as
well as multiple network types with access to common repositories of user information. This is
shown on the right side of Figure 3.
 App 3 App 4
APPLICATIONS
(voice, video, messaging, etc.)
App 5
…
App 2 HSS

Service Broker

App 1
SESSION
App N Control DB
.
.
.

Architecture per service Common architecture

Figure 3: Architecture per Service versus Common Architecture

To enable truly network agnostic service convergence, it is necessary to have an architecture that
works seamlessly across wireless and wireline networks. Furthermore, for true service blending,
it is desirable to have an applications interworking layer that is able to support concurrent,
coordinated access to multiple subtending applications. We refer to such an element as a service
broker.

Based on the key requirements outlined above, we have identified IMS (IP multimedia
subsystem) as the preferred common service architecture for blended triple play services.1 IMS is
already the architecture of choice for conversational services (telephony, video telephony, multi-
party conferencing, and messaging) and has the requisite elements and functional partitioning to
also provide data or “Web” services and video services. These latter services can be provided via
a SOAP/XML or a Parlay/X interface into the IMS framework for applications that do not speak
SIP directly (the protocol of choice for IMS) or as part of the IMS core for SIP–enabled
applications. The IMS framework also provides a unified service-management and session-
control mechanism for applications in both wireline and wireless networks and also provides
many of the common elements mandated earlier in this paper, as shown in Figure 4.

1. “IP Multimedia Subsystem (IMS)—the open industry standard supplying the next generation of
converged services.” Lucent Technologies white paper, http://www.lucent.com; and “IP Multimedia
Subsystem (IMS) Service Architecture.” Lucent Technologies white paper, http://www.lucent.com
 Service Delivery Platform:
• Microsoft CSF
Web services 1
• IBM Websphere
Application
Layer Parlay/OSA Telephony Presence Location Enhanced IPTV
ISG Servers Servers Servers Server

Service Broker/SCIM
Session
Control 4
Layer Call/Session Central
HSS Database
Control 3

5 RACF

Media 1. Service delivery platform (user

Metro 1
Control & portal to order/change services)
Media and Ethernet Gateways
Network
2
2. Network agnostic applications
End Point
Layer 3. Call and session control
3
Cable, DSL, Fiber 4. User subscription and
Other 4
802.16, 3G, … Access networks authentication information
Access
5.
5 Bandwidth and QoS control –
PSTN RACF (Resource Admission and
Control Function)

Figure 4: IMS–Based Simplified Service Architecture

IMS is designed to provide an access-agnostic architecture, thereby removing the boundaries

between wireless and wireline access as well as different types of wireless (WiMAX, EV-DO,
HSDPA) or wireline (xDSL, fiber point-to-point, xPON) networks. This is achieved by
decomposing the service delivery architecture into a three-tiered model composed of the
application layer, session control layer, and media and endpoint layer.

A crucial part of the IMS architecture is the session control layer, which performs call and session
control and the service brokering function. In essence, it is the separation and delineation of this
session control layer that abstracts the details of the underlying network, enabling network-
agnostic applications with access to a central database of user information.

The service broker function is added to support more complex multimedia applications that
invoke more than one application server at a given time. IMS introduces the concept of the
service capability interaction manager (SCIM) for this purpose. In the absence of this layer, end
users would access applications serially, one at a time, with multiple log-in and authentication
steps and, more importantly, with no interleaving of the various application flows or support for
inter-application dependencies (e.g., if application X responds with Y, then contact Z, else contact
S).

It is important to note that two of the functional elements we have identified in Figure 4 are not
standardized as part of IMS but are extensions to the IMS core framework. The first, the service
delivery platform (SDP), provides a range of user self-service options (via a portal) and the
associated provisioning, billing, and applications management environment. In principle, the SDP
could simply be a suite of IMS applications (under SIP control), but we show this as a Web-
services application suite that is accessible via a Parlay/OSA gateway or, more commonly, the
simpler Parlay/X (SOAP/XML–based) gateway that is tailored for interfacing to Web-services
applications. This depiction is consistent with how IMS typically interfaces with SDPs available
from companies such as IBM and Microsoft.

The second additional element is the resource and admission control function (RACF). This
function (or a similar one) is being standardized by a variety of different standards bodies (3GPP,
3GPP2, ITU-T, and ETSI), with some differences between the standards, but with the main goal
in each case being the definition of two additional features: a policy decision function (PDF) and
a policy enforcement point (PEP) (also known as a transport resource control function (TRCF) in
ITU-T). The PDF is responsible for translating an application server’s request for resources into a
class of service definition (BW, delay/jitter, packet loss, etc.), which, in turn, is translated by the
PEP/TRCF into actionable control parameters that are network-element specific. The RACF
function (or equivalent) will likely be recognized as an interface in the IMS architecture as part of
3GPP IMS 7.0 or 8.0, but until that time, this functionality remains part of the ITU-T NGN vision
that has yet to be fully realized.

Using IMS for IPTV Services Control

In the preceding section, we have highlighted the many attractive attributes of IMS for services
convergence. However, the discussion so far has not fully addressed the issue of interworking
with other service delivery architectures or protocols. Notably, both conventional data services
and video services do not fully conform to the SIP–centric control paradigm, as these services are
typically provided using protocols such a HTTP and FTP (for data) and IGMP and RTSP (for
video). However, there are a variety of ways that the messaging flows can be interworked with
IMS, and we will highlight the different approaches one can take in this section. Our focus will be
on IPTV video services, but many of the same methodologies can also be applied to data services
interworking.

Broadly, there are four different levels of IMS and IPTV convergence:

1. Service interworking between IMS and IPTV: conversion or proxying video control
messages to and from SIP
2. Common subscriber management information: creation of central repositories for
subscriber service descriptors and preferences for voice and video services
3. Common network resource control: policy decision and enforcement functions accessible
by both voice and video applications
4. Common signaling: utilization of SIP for all services

These levels will be described in more detail in the following subsections.

Service Interworking between IMS and IPTV

In the IMS architecture, SIP is chosen as the common signaling protocol because of its inherent
underlying simplicity (it is based on a lightweight text-based request-response paradigm, like
HTTP) and extensibility (new SIP methods can be added and services simply described using
embedded session description protocol fields, etc.). However, the IPTV service architecture has
already been defined and typically uses IGMP for broadcast and multicast services and RTSP for
on-demand services, with both protocols having attributes that are tailored for these respective
services. For example, IGMP is a very simple protocol that, therefore, incurs very little
processing overhead, allowing fast channel-change response times. RTSP, on the other hand, is a
request-response text-based protocol like SIP but has methods for pause, play, and record that are
clearly suited for control of video streaming applications. (Note: incorporation of these RTSP
methods into SIP has been frequently considered and rejected on the grounds that too many
methods or too much functionality will over-burden SIP, and the associated message parsing will
become too onerous.)

Thus, the most elementary level of IMS–IPTV interworking is to simply “snoop” these video
control messages (or a subset thereof) and to use a SIP NOTIFY method to inform the IMS
framework of the current state of the user’s video session. Such snooping functionality is indeed
commonplace for IGMP; the channel “join” and “leave” messages are captured by broadband
access network elements (e.g., IP DSLAMs) and processed by the control module in order to
know which multicast groups to join and distribute to the user ports. It is, therefore, relatively
straightforward to generate a companion SIP message that describes the changing user state (e.g.,
User X watching Channel Y). RTSP snooping is a little more complex because of the
comparative richness (and textual nature) of this protocol, which thus requires greater packet
processing capabilities, but otherwise, a similar methodology is applicable in this case too.

IMS–IPTV interworking can be implemented at various levels in the network. Three options can
be readily distinguished, with each option having pros and cons:

1. IPTV–IMS interworking in home network (e.g., CPE). Pro: no modification of network

elements or servers. Con: adaptation of subscriber equipment and devices.
2. IPTV–IMS interworking in access network (e.g., DSLAM). Pro: no modification of client
devices or code. Con: deep stateful packet inspection in DSLAM (for RTSP) at wire
speed.
3. IPTV–IMS interworking at application servers or SCIM/service broker. Pro: no
modification of client devices or code. Cons: adaptation (“SIPification”) of existing
application servers and not applicable to IGMP (since IGMP messages do not generally
propagate back to the IPTV application server).

Specific examples of access network and application server interworking are provided in later in
this paper; the essential conclusion is that IMS–IPTV interworking is relatively simple to
implement if done judiciously and the underlying video network elements are chosen
appropriately.

Common Subscriber Management Information

Traditionally, subscriber data is stored in various application-specific and network-specific
databases (see Figure 5). The consequence of this dispersion of user data and the lack of an
omniscient view of the user is that subscriber service provisioning and interaction is typically a
complex sequential process that is most likely manual in nature (i.e., it requires operator
intervention). As a result, the ability to dynamically render multifaceted, blended multimedia
services is severely limited. Therefore, the concept of data “federation” in which all subscriber
information in all databases is accessible (using appropriate “trusted” database request protocols)
is a powerful one; a single, comprehensive definition of the user can be created either temporarily
in a “virtual database” generated dynamically by federating data during user activity periods or
more permanently in a database structure that contains the latest federated data.

A consolidated user record or database of subscriber information allows single sign-on for a user,
independent of the access network or local account information, with ubiquitous access to all
services and service profiles. Furthermore, the provisioning of a dynamic service combination
(e.g., watch a movie plus instant message with buddies plus receive personalized alerts) is now
possible since the requisite component service profiles and address books can be easily
referenced “on the fly.”
The lowering of OPEX and CAPEX associated with database elimination or consolidation
following data federation is also beneficial to the service provider, although this step is not
strictly necessary to achieve the sophisticated blended services provisioning previously described.
Application 11
Application

DB

Application
Application 11
HSS
Application 22
Application

DB
Replicated Application
Application 22
Data
Application
Application XX

SESSION CONTROL
Application XX
Application

DB
DB

Data per service Unified Data

Figure 5: Unification Databases and Subscriber Management

Ultimately, the ability of a service provider to provide a service with the service guarantees that
the user requires depends on the ability to control the underlying network resources. For example,
for video services, it is critical to be able to control and manage the ACL in the DSLAM, the BW
and flow priority provisioned in the access network, and the transport network resources allocated
to a given service. In the absence of such control, video services will be no better than best-effort
services and will suffer the same degradation in quality at times of peak demand: a situation that
is clearly intolerable when one is talking about broadcast TV and premium video services (as
opposed to streaming “Web” video).

One solution is to over-design the network so that it is always underutilized. While this strategy
may be successful at low service take rates, it is clearly not an optimal strategy in the long term
from a CAPEX perspective. Moreover, such an approach does not allow service-level
differentiation between different application providers, and a service provider’s own application
or service (e.g., conferencing or VoIP feature server) will be essentially indistinguishable from a
third party’s offering as far as the class of service (CoS) experienced by the end user is
concerned.

A better alternative therefore is to provide a resource and admission control function (RACF) that
is accessible by voice, data, and video applications so that policy decisions can by executed by
any combination of services, on demand. This is schematically shown in Figure 6. A requested
service would be admitted based on the end user’s subscription and service contract, as well as
based on available network resources. If the service is granted or the service content changes
during the session, proper bandwidth would be allocated or reallocated on the local access
network with differentiated QoS as needed. For example, QoS–sensitive services such as IPTV
can preempt bandwidth allocated to flat rate and non-QoS–sensitive services such as Internet
access, and additional bandwidth management functions such as rate reconfiguration on a DSL
access link (using, for example, dynamic spectrum management techniques) can be implemented
to make more efficient utilization of network resources.

Recognizing the fundamental importance of this functionality, a complete definition of such an

RACF layer by the standards bodies is currently underway. Clearly, a new control element (or
elements) will be required in the IMS core framework to support this function; similarly, some
changes will be required in the network elements. For example, the network element control
module will need to support COPS or diameter interfaces—or, perhaps, a SOAP/XML
interface—for transfer of CoS requests and availability information. Moreover, the constituent
hardware needs to be able to support dynamic, per flow provisioning across all user flows (or
flow aggregates). The former changes are likely to be achievable with software upgrades to
enhance the management modules of the network elements; the latter requires hardware
capabilities that, if not already present, would require new equipment to be deployed. It is,
therefore, critically important for a service provider to carefully consider this emergent
functionality when deploying network elements today in order to avoid premature reinvestment in
the network in the near future.

Data IMS IP Video

Services Services Services
Best effort Conversational Streaming

RACF

Wireline or Wireless
IP Access

VoIP Phone Set Top Box

Mobile Devices TV Monitor
PC

Figure 6: Common Resource and Admission Control Function

The last stage of integration of IMS and IPTV services would be to have a common SIP signaling
protocol for all service control. While this appears to be a logical evolution for reasons outlined
previously, this is not deemed desirable for services with very fast state changes (e.g., channel
changes) or for services that are already well-provided using existing protocols (e.g., VoD using
RTSP). Indeed, the changes to the network elements—the STBs (to generate SIP), the access and
transport network elements (to process and parse SIP), and the application servers (to terminate
SIP)—are sufficiently extensive that it is unlikely that this will occur in the near term or for any
deployed network. In the future, were the migration to all-SIP signaling to be supported, it would
likely only be implemented in new video network deployments—so-called greenfield builds—
with the other methods of interworking IMS plus IPTV continuing to being supported in existing
network builds.

Enhanced Customer Experience

In this section, we describe some of the advanced services that are enabled if the IPTV service
architecture is enhanced with IMS, and we elucidate the various levels of IMS plus IPTV
interworking discussed above. We highlight the fact that customers will not only be able to access
any service on any device in the home but will also experience intelligent interworking between
services and on any device anywhere, anytime.
TV and Telephony Interworking
This service enables a user who is watching the TV to receive a voice call identification on the
TV screen and to record and optionally pause the video stream for the duration of the call.

Function:
1. Display caller ID on TV
2. Provide Answer Call/Pause TV
option:
a. TV program is automatically
recorded on a DVR (and
optionally paused)
b. TV program un-pauses and
replays from the pre-call
location when the call is
complete

Figure 7: TV and Telephony Interworking

There are various requirements to implement such a service. For the simple TV caller ID service
(in example 1), the following must occur:

• The IMS platform must be aware that the user is watching the TV (to “know” to
generate a TV caller ID pop-up).
• IMS must know the identities (addresses) of the various user STBs and the
association between the user’s video “identity” and telephone numbers in order to
send the appropriate caller ID information to the appropriate devices (STBs).

For the extended TV caller ID service with the TV pause and record feature (in example 2), the
following must occur:

• IMS must also know which channel each STB is currently watching in order to store
the appropriate stream for the user.
• IMS must also be able to initiate storage of content for user, and then generate a
record of stored content per user and notify the user that recorded content is available
for viewing upon termination of the voice call.

Example 1: TV Caller ID with Application Level Interworking Only

This example describes a call flow showing how the caller ID can be displayed on the TV screen
(see Figure 08) using interworking between the IPTV middleware and the IMS only.
 SOAP/XML
IMS or HTTP IPTV
1
Service Broker 5 IPTV Server
1 SIP
4 5
Diameter
MC
HSS 3 S-CSCF Router
6
5 SIP
1 2
SIP HTTP IGMP

Bob Pat

Figure 8: TV Caller ID with Application Level Interworking

1. Pat logs on to the IPTV middleware server. The IPTV server obtains video service
information from the HSS using a service broker function that translates the
middleware API protocol (e.g., SOAP/XML, HTTP) into SIP. Upon authentication, Pat
receives an EPG (electronic programming guide) tailored for her.
2. Pat browses the EPG and selects a multicast TV channel.
3. Bob calls Pat, and S-CSCF checks HSS for the subscription package.
4. Because Pat has subscribed to the “TV Caller ID” service, the SIP message is forwarded
to the service broker.
5. The service broker initiates a SIP message to Pat’s phone (which rings) and a
SOAP/XML or HTTP message to the IPTV server.
6. The IPTV middleware server generates an alert message that causes the STB client to
overlay caller ID information on TV screen.

The issue with this approach is that there is no knowledge within the IMS of the actual stream
(multicast channel) that the user is watching, only the fact that the user recently logged on to the
IPTV middleware server to obtain his or her EPG. Thus, the stream cannot be recorded on behalf
of the user as the network does not know which stream to record. This limitation arises from the
fact that the multicast control (IGMP) messages only propagate between the STB and the video
server and multicast router. Overcoming this limitation requires access-network–level IMS plus
IPTV interworking as described in the next example.

Example 2: TV Caller ID with Access Network Level Interworking

1. Pat logs on to the IPTV middleware server. The IPTV server obtains video service
information from the HSS using a service broker function that translates the
 SOAP/XML messages generated by the middleware into SIP. Upon authentication, Pat
receives an EPG (electronic programming guide) tailored for her.
2. Pat browses the EPG and selects multicast TV channel X. The access node snoops the
IGMP join message.
3. The access node spawns a SIP message to inform IMS that Pat is now watching channel
X.
4. The SIP channel change message is forwarded to the HSS to record the status change.
5. Bob calls Pat, and S-CSCF checks HSS for the subscription package.
6. Because Pat has subscribed to the “TV Caller ID” service, the SIP message is forwarded
to the service broker.
7. The service broker initiates a SIP message to Pat’s phone (which rings) and a
SOAP/XML or HTTP message to the IPTV server.
8. The IPTV middleware server generates an alert message that causes the STB client to
overlay caller ID information on TV screen.

SOAP/XML
IMS or HTTP
IPTV

Service Broker 1 IPTV Server

7
1
Diameter
6 7 HTTP

MC
4 8 Router
HSS S-CSCF
5 1 2
3
SIP
SIP 7 Access
Node

5 7 2 IGMP

Bob Pat

Figure 9: TV Caller ID with Access Network Level Interworking

At this stage, the phone rings, and the caller ID is overlaid on the TV screen. The major benefit of
the interworking function in the access node is that the IMS now has the knowledge of the actual
stream the user is watching and from which STB. This will enable pause and record functions to
be performed, and this is described in the following call flow.
 SOAP/XML
or HTTP

12
Service Broker 14 IPTV Server
11
SIP
10 14 13
9
MC
DVR
HSS S-CSCF MC Router
Video 15
UC Stream MC Video
9 Playback stream

SIP 16
14
SIP
Access
10 Node
14
9

Bob Pat

Figure 10: TV Pause and Record

9. Pat decides to accept the incoming call by picking up the phone. The SIP “OK” message
travels back to the service broker.
10. The service broker forwards the SIP message to Bob, who established the call.
11. The service broker queries HSS to determine Pat’s channel status.
12. The service broker sees that Pat is watching channel X and has subscribed to the TV
pause and record service, and it initiates a “record video channel X” message to the
IPTV server.
13. The IPTV server instructs a network DVR to join and record multicast channel X
currently being watched by Pat.
14. When Pat hangs up, the service broker informs the IPTV server.
15. The IPTV server alerts Pat that playback is available.
16. Pat selects the playback option, and the IPTV server initiates play-out of a stored stream
from the DVR.

In addition to the preceding voice plus video blended service, many other blended service options
are possible using different levels of IMS plus IPTV interworking. A few such examples are
described in the following sections.

Mobile IPTV
This service enables a user to forward TV services to any location, on any device, with the same
look and feel as at home. An example is enabling IPTV services in a car for backseat passengers
to watch. Furthermore, if the car journey is completed before the end of the program, the user
could opt to initiate a record function (similar to the above example) and then continue the TV
session in his or her home. Another example could be a business person who is traveling and
could access the same range of services from a hotel room as he or she can from home, also with
a network DVR option available.

This is a perfect example of how IMS adds value to IPTV: such services require interworking
between mobile and fixed (wireline) networks for which IMS is ideally suited because of its
network agnosticism and ability to provide session control from the home network (via the S-
CSCF) to a remote location (via the P-CSCF and I-CSCF functions).

A major benefit of combined wireline and wireless IPTV services is the lower CAPEX and
OPEX investments required to set up and run the service (given that a single investment is
leveraged for both networks), while providing new revenue streams with the delivery of different
content. It also provides new advertising revenue and promotional opportunities for service and
content providers.

Video and Data Services Blending

As another blended service example, consider the option of experiencing personalized and
interactive communications while watching TV. For example, during a football match, a user
might want to study some detailed statistics of a particular player or communicate with another
user by e-mail or video conference. Alternatively, while watching breaking news on the weather,
a user might want to get more information on an approaching storm or consult the latest news
articles on the Web. Other interactive examples include the ability to shop or vote during a
particular TV program.

Figure 11: Video and Data Services Blending

Such video and data services blending combines intelligent network applications that assess and
predict a user’s personal preferences and provide sophisticated content search and management
applications to provide a unique consumer experience. The service broker function of IMS again
acts as the coordinator of these different applications, allowing the seamless creation of blended
services.

These services provide clear opportunities for service providers to differentiate their services with
targeted per-user content and advertisements and to create new transaction-based revenue streams
(if per-click–based advertising revenue sharing is supported, for example)

Location and Video Services Interworking

This blended service enables consumers to locate family and friends from their TV screen. The
location capability is provided by the family member’s mobile phone using existing mobile phone
location technology as well as potentially other means such as transaction locations. This
information is then made available as a multimedia TV channel (containing content from a
dynamic mapping service with coordinates superimposed by a second application).

Ann is here.

Figure 12: Location and Video Services Interworking

This service clearly appeals to personal and family safety concerns and can also be used to check
other local events or current status (such as traffic maps, local weather maps, etc.).

Summary

The intense competition between broadband access providers is forcing service providers to offer
more value-added bundled services over the broadband connection with the aim to retain
customers and increase profitability. IPTV services in particular are a clear target, providing
access to a substantial additional revenue opportunity in the order of $20 to $80 per subscriber.

However, the service architecture for IPTV is significantly different to that of data services,
which, in turn, is also different from VoIP services. Each service uses different methods for
authentication, stores user information in separate databases, has separate billing and operations
systems, and uses different control architectures and methods for QoS enforcement. The result is
an increase in OPEX and CAPEX costs as multiple systems need to be purchased, deployed,
supported, and upgraded.

Another concern related to service bundling over broadband is that all other service providers can
support the same triple play bundle offering. Therefore, the ability to differentiate service
becomes difficult, with low-price differentiation being the only alternative, which, in turn, results
in a decrease in ARPU.

In order to reduce capital and operational expenditures and, in addition, to enable service
differentiation that will facilitate increased revenue per user, a common services architecture is
required that works seamlessly across wireline and wireless networks. This common services
architecture must maintain the service platforms as they exist today but combine certain functions
to simplify the service delivery (eliminating unnecessary duplication) and create a flexible
network for new services. We identified the following functions that can be combined or used in
combination:

• User subscription and authentication information

• Call and session control
• Bandwidth and quality of service control
• Service delivery platform
• Network agnostic applications

In addition, new revenue opportunities and service differentiation can be achieved by migrating
from bundled services to a new set of blended services that uniquely enhance the user experience
and create a user-centric paradigm. Seamless blending of voice, video (IPTV), and data services
will enable the service provider to integrate or interleave existing services to form new blended
service packages.

Based on these key requirements, we have identified IMS as the preferred common service
architecture that has the requisite elements and functional partitioning to provide data and video
services in addition to conversational and multimedia services. IMS has the following attributes:

• Access agnostic architecture: removing the boundaries between wireline and wireless
access
• Separate session control layer: enabling network-agnostic applications with access to a
central database of user information
• Service capability interaction manager: service broker function that enables the support
of more complex blended services that invoke more than one application server at a given
time

Two additional functional elements are also required as extensions to the IMS core framework to
fulfill the requirements listed above. These include a service delivery platform and a resource and
admission control function, both of which are developing well-defined interfaces into the IMS
core framework.

In order to use IMS for IPTV service control, interworking between the two service architectures
is required as video services do not conform to the SIP–centric control paradigm of IMS. Video
services are typically provided using protocols such as IGMP and RTSP. To enable the delivery
of sophisticated blended services, these messaging flows need to be interworked with IMS. This
can be done by “snooping” the video control messages and informing the IMS framework of the
current state of the user’s video session. The interworking function can take place in the home
network, the access network (e.g., DSLAM), or at the application servers. Each approach has its
relative merits and should be relatively simple to implement. Additional levels of convergence
were also discussed, including common subscriber management information, common network
resource control, and common signaling.

The resulting simplified service architecture will provide important OPEX and CAPEX
reductions for the service provider but, at the same time, allow the delivery of new, sophisticated
blended services enabling real service differentiation. This will provide an opportunity for the
service provider to build profitable new revenue streams over their broadband access networks
and take market share by creating customer affinity and loyalty.
Copyright © 2005–2006 Lucent Technologies