Back toIP CommunicationsCommunity

January 17, 2006

IMS and IPTV, Perfect Together

By TMCnet Special Guest

Introduction

As a result of the intense competition for broadband access services, most voice and data service providers are deploying or planning to deploy IPTV services as part of a “bundled” service offering.  This is a necessary evolution to retain customers, grow market share and increase the profitability of broadband services. However, it also is important to note that simple bundles of services – providing voice, video and data services in a unified package with a single bill – are typically offered at a lower price than the equivalent services offered separately, resulting in a decrease in Average Revenue Per User (ARPU) in the long term.

Clearly, the challenge for service providers is to increase the value of their services to generate increased ARPU, and to decrease the constant customer churn between one provider and another that reduces service profitability.  To accomplish this, service providers need to consider new “blended” service packages that will differentiate their triple play offerings from other providers.

Additionally, migrating to a “triple play” service package increases the complexity in the service architecture as each new service (e.g. IPTV, Voice over IP) has its own unique service architecture.  This approach will lead to increased capital expenditures (CapEx) associated with deploying multiple overlaid networks and services delivery frameworks, and increased operational expenditures (OpEx) resulting from the need to manage multiple networks.

An ideal way to address these critical concerns is to deploy a common services control architecture that can support a wide variety of services, and enable the “blending” of capabilities into novel services packages that offer the end user a unique, seamless multimedia experience.

Services Blending via IMS

Increasingly, the common services framework of choice in the industry is IMS – the IP Multimedia Subsystem – an industry standard for the delivery of multimedia services originally defined by the Third-Generation Partnership Project (3GPP) for next-generation mobile networking applications.  This Services Initiation Protocol (SIP)-based control framework is rapidly gaining acceptance for landline, wireless and converged networks.

In the IMS architecture, SIP is chosen as the common signaling protocol due to its inherent, underlying simplicity (it is based on a lightweight text-based request-response paradigm, like HTTP) and extensibility (new methods can be added and services can be simply described using embedded Session Description Protocol fields).

This represents something of a challenge when interworking with IPTV, however, since the IPTV service architecture has already been defined and uses Internet Group Management Protocol (IGMP) for broadcast/multicast services and Real-time Streaming Protocol (RTSP) for on-demand services, with both protocols having attributes that are tailored for these respective services.  While incorporation of these RTSP methods into SIP has been frequently considered, this approach has been rejected on the grounds that too many methods or too much functionality will over-burden SIP and make processing messages too complex.

Approaches for IMS and IPTV Interworking

A variety of methods have been worked out to address this challenge, however.  The most elementary level of IMS-IPTV interworking is to simply track or “snoop” 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 (what they’re watching, whether the session is paused, etc.).  Such snooping functionality is commonplace for IGMP, and 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 more complex, due to the comparative richness of this protocol, and as a result greater packet processing capability is required.  Apart from this challenge, however, a similar methodology to that described above is applicable in this case.

Such IMS-IPTV interworking can be implemented at various levels in the network.  Three options can be readily distinguished, specifically:

1. IPTV-IMS interworking in Home Network – e.g. Customer Premise Equipment (CPE)
2. IPTV-IMS interworking at Application Servers
3. IPTV-IMS interworking in Access Network (e.g. DSLAM).

Each of these approaches has pros and cons, which we’ll explore here.

In principle, Option #1 may seem like the optimum choice because the CPE “sees” or generates all user service control messages. However, to support interworking with IMS, new functionality would need to be added to existing CPE, which may not be possible in many cases, and could be difficult and costly in most cases. Furthermore, this approach does not naturally allow the access network elements to autonomously adapt to the evolving service needs of the user, since the services intelligence and awareness is concentrated in the CPE.

There are some benefits to Option #2 as well, most notably the fact that there is no need to modify client devices or code to implement this approach.  Again, however, significant adaptation of application servers to support SIP could be required in many cases, which would almost certainly result in significant expense.  Furthermore, this approach is not applicable to IGMP, since IGMP messages do not generally propagate back to the IPTV application server.

Therefore, in many cases, the third option – IPTV-IMS Interworking in the Access Network -- is the favored approach.  We will demonstrate the importance of such Access node-mediated IMS-IPTV interworking by use of a simple services example, as follows:

Consider a relatively simple interactive IPTV-telephony service interaction mediated by IMS -- Caller ID on TV with TV Pause Services. This service enables a user who is watching the TV receive a voice call identification on the TV screen and then – unlike existing notification services -- provides the option for pausing, and recording the video stream for the duration of the call.

There are various requirements to implement such a service.  Perhaps most importantly, the IMS platform must be aware that the user is watching the TV to generate a Caller ID on TV pop-up. Additionally, IMS must know the identities (addresses) of the various user set top boxes, 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. IMS must also know which channel each set top box is currently watching in order to store the appropriate stream for the user. Finally, IMS must also be able to initiate storage of video content for user, 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.

Implied in the above example is the need to modify the allocation of resources – most notably bandwidth -- in the access node as the multicast video stream the user was originally watching (along with many other users served by the access node, one assumes) changes to a personalized unicast flow from the network DVR. Clearly this process will place an additional load on the access node and resources may need to be adjusted accordingly. For example, trunk or backplane bandwidth, along with appropriate flow priority, may need to be allocated to the “on-demand” flow to ensure the requisite streaming quality; this is particularly true if the user has paid a premium fee for this Caller ID + Network DVR service “blend.” By performing the IMS-IPTV interworking in the access node, the policy decision and transport admission control function (elements of the ITU-T Resource Access Control Facility, or RACF, standard) can be implemented intelligently and autonomously in the access node itself, thereby reducing the potential load on other network-level RACF elements.

In addition to the preceding voice + video blended service, many other blended service options are possible using similar IMS-IPTV or even IMS-Data Services interworking. In all cases, there are considerable benefits to be realized by interworking these at the access node, since it is optimally situated for such purposes – it is close to the end user (and so “sees” the user-specific flow information) but does not incur the additional cost and management complexity potentially associated with providing similar services by interworking in the user’s home/CPE.  Furthermore, if future services enhancements are required, the upgrade need only be performed in the access node (which can serve thousands of users), rather than in all the CPE elements of all the attached users.

Thus, overall, of the three potential methods of IMS-IPTV interworking outlined in this paper, interworking in the access node provides the most efficient and future-proof solution for providing novel blended services with the necessary quality of service.

Conclusion

As operators seek to deploy new voice (VoIP) and video (IPTV) services to enhance their existing service offerings, there is a need to simultaneously reduce the cost and complexity of the network, in terms of OpEx and CapEx, as well as to increase the ARPU, in order to realize a faster return on investment.  These seemingly conflicting goals can be met by deploying a common services control framework, which minimizes the redundancy inherent in current (separate) control systems and provides the ability to offer sophisticated services blends that will help attract and retain new customers (as well as increase the ARPU).  IMS, in our view, is the control framework of choice, due in large part to the ease with which networks that do not currently operate under IMS control (e.g. IPTV networks and systems) can be integrated into an IMS service delivery scheme.  Further, we see integration at the access node as the preferred choice for IMS+IPTV interworking in many, and likely most cases.

-----

Mr. Weldon is Chief Technical Officer of Broadband Solutions at Lucent Technologies.