Blending IPTV Services


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Blending IPTV Services

  1. 1. Blending IPTV Services J. Robert Ensor Markus Hofmann Ivica Rimac Multimedia Networking Research Department Bell Labs / Lucent Technologies Holmdel, New Jersey Email: {jre, hofmann, rimac} communications device—from the comfort of the TV chair, just ABSTRACT by pushing a button on the TV remote control. They want to This paper describes the concept of service blending—the ability control their TV, personal voice services, Internet, e-mail, and of two or more services to interact under a unified control scheme. Instant Messaging (IM) on whichever device they use, wherever We introduce a novel infrastructure component, Service Broker, they are, whether at home, at work or on the go. They want designed to support efficient blending through dynamically personalized, intelligent and seamless interactive features that can loadable program modules called steplets. We demonstrate their enhance and simplify their lifestyles. use through implementation of two IPTV-based service examples. The trend toward converged services and integrated applications is not new. The World Wide Web (WWW, Web), for example, Categories and Subject Descriptors makes switching between applications such as file transfer, C.2.1 [Computer-Communication Networks]: Network streaming video, or e-mail seamless and effortless. The ease with Architecture and Design – network communications. which users can navigate through different applications and H.4.0 [Information Systems Applications]: General, content contributed significantly to the tremendous success of the Communications Applications. Web. Recent advances in networking and the trend toward packet- based infrastructures enable even tighter integration—the convergence and growing together of traditionally separate General Terms communication worlds. Voice-over IP (VoIP) carries phone Design. services over the Internet, and IP-based TV (IPTV) promises to deliver television shows over packet-based networks. This broader convergence is transforming the communications industry, driving Keywords growth and creating new exciting services and revenue Service Blending, IPTV Middleware, Service Broker, Service opportunities. Infrastructure. Service Bundling vs. Service Blending 1. INTRODUCTION Service providers are beginning to introduce IPTV offerings as The universe of electronic communications has been made up of part of a competitive service bundle designed to give consumers a separate worlds, in which specific services are associated with flavor of service convergence. Service bundling offers unified distinct networks. For example, the Public Switched Telephony ordering and billing, and limited interaction for otherwise separate Network (PSTN) has long carried phone calls, while TV networks services. It is only a first, limited form of convergence. Although deliver television programs and the Internet enables exciting data it may help retain some customers in the short term, bundling services. continues to rely on separate networks for each type of service and does not provide the unified control consumers demand. Today, individuals desire to break through the separation of these Service blending, in contrast, enables different applications to communication worlds. They want their communications control one another. It enables the Web or the phone to control the experience to be richer and more integrated. Consumers expect TV and vice versa. the ability to communicate anytime, anywhere using whichever device and method they choose. Instead of having to get up from The following example illustrates the difference between service the comfortable TV chair just to see who is calling on the kitchen bundling and service blending: If a user is watching TV and phone, users would prefer to control the phone – or any other receives a call on her legacy phone, the name of the caller (i.e. the Caller ID) can be overlaid on the television screen using relatively simple technology. While this application provides a limited form Permission to make digital or hard copies of all or part of this work for of convergence, it is still just a bundled service—the Caller ID personal or classroom use is granted without fee provided that copies are service (i.e., a voice service) is overlaid on a TV service. not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy The transition to a blended service occurs when individual otherwise, or republish, to post on servers or to redistribute to lists, services interwork and control each other. One such blended requires prior specific permission and/or a fee. service might automatically record and/or pause the currently IPTV Workshop, International World Wide Web Conference, May 23, viewed TV program when the user picks up the phone to accept 2006, Edinburgh, Scotland, United Kingdom.
  2. 2. an incoming call. Later, when the user hangs up the call, an option Multimedia Subsystem (IMS) is an emerging architectural to replay the TV program from where the user left off can be standard [1] that provides a promising foundation for adding provided in form of an alert message on the TV screen. The support for blending of realtime, interactive services, including seamless interplay of voice services (Caller ID) with TV viewing, telephony and interactive multimedia. While IMS defines a video storage, and messaging (the replay alert) represents a truly comprehensive framework for voice and multimedia applications, converged service. it falls short in detailing the interworking with existing communications infrastructures such as the Web or IPTV. We Blending IPTV services with telephony and Web applications is later on address this issue by introducing our Service Broker, an opportunity to move beyond simple service bundling to create which serves as a bridging element between IMS, the Web, and profitable, personalized, blended lifestyle services. In fact, tight IPTV. integration is the key to true convergence. True convergence is a matter of uniting diverse applications, systems and technologies to build a flexible, scalable service infrastructure—one that can 2.1 IP Multimedia Subsystem (IMS) control voice, data, and video while providing security, reliability, IMS specifications describe a suite of functional elements and superior quality. communicating through standard protocols within an IP core network. This core network is typically surrounded by various Unified Control access networks—including telephony networks and IP networks. True service blending presents demanding new challenges: It An IMS contains call session control functions (CSCF) that requires infrastructure components that provide unified control coordinate calls and sessions among other IMS’s, access among a variety of different applications—Web, IPTV, telephony. networks, and applications. CSCF session controls are based upon These components need to handle and map between the different the Session Initiation Protocol (SIP). IMS signaling gateways state and data models underlying each of the services they blend convert call and session events in other networks to/from SIP. together. Media gateways handle the formatting and transmission of data between an IMS and other networks. An IMS also contains For example, an infrastructure implementing the blended service subscriber data servers that store user and service descriptions; described above needs to handle both the call state model of the these data permit mapping of services and subscribers among voice service and the state model of the IPTV application. It then multiple networks and applications. While the CSCF provides has to map events in one model (e.g. incoming call accepted) to basic coordination among applications, a separate coordination the appropriate command in the other (e.g. start recording). In server, called the Service Capability Interaction Manager (SCIM) addition, it has to map between the communications protocols that may be present to provide more complex interaction management. are used by the underlying applications—e.g. the Hypertext Transfer Protocol (HTTP), the Session Initiation Protocol (SIP), and the Real Time Streaming Protocol (RTSP). In our example Application Servers above, an incoming SIP message triggers an RSTP message that Telephone TV initiates the recording of the TV program. Furthermore, the Networks Networks prevalent media encodings and transmission protocols of telephony are distinct from those on the Web. Therefore, the Subscriber blending infrastructure must contain both signaling and media Data Service gateways for these networks. Servers Broker The infrastructure must also maintain mappings among the IP Core Network Media Resource various user and service identities that are used by applications in Managers SIP-Based Signaling different networks. Finally, the infrastructure must contain Call/Session elements to coordinate the operations of the applications involved Controllers in blended services. It must ensure that the interaction of multiple services does not result in undesired behavior. This is of particular Media Gateways Media Servers importance since different services are likely not to be aware of each other. Other Internet Networks Basically, the infrastructure has to provide an interworking layer that is able to support concurrent and coordinated access to multiple subtending applications. We design and present the Service Broker as the element implementing such layer. Figure 1: Infrastructure Architecture 2. INFRASTRUCTURE As illustrated in Figure 1, our blending infrastructure is based It is important that the infrastructure used to build blended service upon the IMS foundation. We have built an additional element is based on open standards and open interfaces. This significantly called the Service Broker, which serves as a SCIM, but actually simplifies the integration of third-party services and allows goes beyond SCIM functionality; SCIM is designed for blending tapping into the vast pool of existing applications. SIP-based services whereas the Service Broker not only blends The World Wide Web with its open architecture and standardized SIP-based services, but services with a variety of interfaces and protocols proved to be tremendously successful in enabling the delivery mechanisms. Service Broker communicates with the blending of non/near-realtime, content-driven applications. The IP CSCF to receive and send call and session events. It also
  3. 3. communicates with one or more application servers to coordinate Amongst others, steplets add the following two main features that their behavior according to the requirements generated by blended are neither provided by SIP Servlets nor by the Java Servlet service specifications. Specification: 1. Dynamic steplet list. With SIP Servlets, as with general Java 2.2 Service Broker and Steplet Concept servlets, when a message arrives, the servlet engine consults The Service Broker communicates with the CSCF through SIP a static configuration descriptor to determine the servlet that messages and may treat some of these messages as call event will handle that message. The Service Broker, however, triggers. As indicated in the introduction, we have extended the determines an initial steplet list for a message by looking up concept of Service Broker beyond the IMS SCIM, allowing our the “To” (or Request URI) or “From” (or P-Asserted Service Broker to communicate with application servers through Identity) address in a database (the HSS in an IMS network). various protocols, including HTTP and SOAP. It can use these Once a steplet is executing, it has the ability to append a communications to respond to application-specific information, different steplet to the Steplet List for that message. This e.g., calendar updates. Therefore, the Service Broker acts as a ability to chain steplets during execution of the code enables programmable signaling gateway between different kind of dynamic determination of logic to be executed and/or networks and applications [2]. applications to be invoked. This determination can be based on information obtained from outside the Service Broker and The Service Broker’s message handling logic is controlled by even from outside the IMS. It can be based on results from dynamically loaded program fragments named steplets, which are previous application invocations, or results from Presence, written in the Java programming language. Steplets determine Location, and/or Policy Servers. policy issues, such as which application servers messages should be forwarded to, and how the messages that those servers generate 2. Steplet wait capability. The freedom to blend services that should be dealt with. The Service Broker provides the have an interactive element can give rise to long wait times, mechanisms for functionality such as managing messages, whether a steplet would need to wait for a call to be invoking steplets, following the various protocols (e.g. SIP, answered, for a response from a slow network database, or HTTP, SOAP/XML), and maintaining transaction and dialog from an interaction with a user via an Instant Message and a state. link click. With SIP Servlets, which use the underlying Java wait/notify facilities, all of these would tie up threads, Steplets are to the Service Broker what servlets are to a Web reducing the number of subscribers that can be handled by server servlet engine. A key difference, though, is that each HTTP the system and, perhaps more importantly, limiting the types request is typically handled by a single Web servlet. When the of blended services that are practical. In contrast, the steplet HTTP request arrives, the Web server invokes the appropriate wait capability provided in the Service Broker relies on servlet. That servlet may use other classes, of course, but incoming SIP messages as the objects on which steplets wait. ultimately that original servlet is responsible for generating the This allows steplets to release their threads while waiting. response to the client. The latter feature significantly improves efficiency. Without an In the Service Broker, however, an incoming message may be explicit wait facility, a waiting servlet could tie up a thread many handled by a succession of steplets—hence, the name steplet. In minutes. But if steplets use an explicit wait facility, it is some cases, the sequence of steplets might be determined only reasonable to assume that a Service Broker steplet will tie up a upon arrival of the first message. For example, when a SIP thread for, say, at most 20 milliseconds. With an explicit wait INVITE message arrives, the Service Broker might look up the facility, the Service Broker could function smoothly with a pool “To” address in a database, and the database would specify a fixed of, say, 30 worker threads, while without it, the Service Broker list of steplets to handle INVITE messages to the specified might need thousands of worker threads. endpoint. In other cases, the sequence of steplets might be determined dynamically. For example, the Service Broker could look up the “To” address and get the first steplet. That steplet 3. SERVICE EXAMPLES might forward the message to a specific application server, and, We have implemented two applications using the previously based on the server’s reply determine the next steplet to handle described infrastructure. Therein, the Service Broker the message. communicates with Lucent's commercial IMS components via SIP and with IPTV components via SOAP/XML. The IPTV Steplets are similar to SIP Servlets [3]. However, their details are components include different commercial set-top boxes (such as fundamentally different. While SIP Servlets are based on generic Amino and Microsoft Media Center Edition) and a Linux-based servlets as defined in the Java Servlet Specification [4], steplets IPTV server. use a different underlying model. We have chosen a different model because the Java Servlet Specification does not provide some features we see as facilitating Service Brokering and 3.1 IPTV-Based Call Handling because Java Servlets obligate us to implement potentially The first example we present follows the blended IPTV/telephony expensive, unneeded features. Further, although the Java Servlet application described briefly earlier in Section 1. This application Specification was intended to be protocol-neutral, in reality the integrates the handling of phone calls and the recording or pausing generic servlet classes are biased towards HTTP-like protocols. of TV content during phone calls. Figure 2 illustrates the roles of For example, the generic servlet classes assume that requests and this application’s major components. responses are stream oriented, that there is a single response for each request, and that requests and servlets have URL-like When Alice starts watching TV, her set-top box sends an event to pathnames. None of that is true for SIP. the IPTV server, which forwards the event to the IPTV service
  4. 4. package (step 1). This event triggers the IPTV service package to 3.2 Remote Approval store Alice’s status in the user data (step 2). Now, when Bob initiates a call to Alice, call event signals pass to Alice’s Serving In the previous application the Service Broker infrastructure Call Session Controller (S-CSCF). Because Alice has subscribed mediated events from the IMS to the IPTV world. In contrast, we to the call handling application, the S-CSCF is configured to pass next present an example for the class of applications where our the call event signals to the Service Broker (step 3). infrastructure enables the IPTV service to trigger events in and change state according to responses from the IMS world. Content access control for TV services is a powerful feature, e.g., TV Content for preventing children from watching inappropriate content, HSS spending an inappropriate amount of time watching TV, 2 controlling the fees for pay-per-view programming, etc. Currently 1 IPTV deployed content access control mechanisms are very limited in Interface 6 Call Handling their functionality and convenience. Basically, they allow content IPTV 10 Handling 4 Middleware 12 Module authorization only from the content-requesting end point, which 12 10 5 implies that for successful authorization the privileged user has to 11 Service be physically present. Alternatively, the authorization information 7 Broker may be disclosed to the requesting user through an independent DVR 9 5 communication channel (e.g., telephone or IM). However, the 13 12 8 3 latter approach is unreasonable and undermines the power of 1 CSCF access control mechanisms. 14 5 8 9 3 A possible end-point solution is the use of remotely configurable Set-Top set-top boxes (STBs). Nevertheless, the underlying model still STB Phone 12 Phone Box assumes service provisioning to physical end points instead of Alice Bob subscribed users (independent of the used end devices). Hence, this approach requires all STBs to implement content access Figure 2: IPTV Call Handling control features and to provide interfaces for remote configuration. In a home with multiple STBs the privileged user (mother, father) still needs to control and configure each single The Service Broker queries the HSS and learns that Alice is end device to maintain consistent access control rights. To currently watching TV (step 4). Therefore, the Service Broker overcome the aforementioned limitations, we leverage our Service forks the call, sending a SIP control message through the S-CSCF Broker infrastructure to enable Remote Approval. Figure 3 depicts to Alice’s phone and also to the IPTV service package (step 5). the infrastructure and the signaling flow for a Parental Control The IPTV service package acts on the SIP message by sending example scenario. Bob’s caller id and associated info (e.g., his picture) as well as a command menu to the IPTV server (step 6) for display on Alice’s TV (step 7). Meanwhile, Alice’s phone will start ringing. Now Alice can use Profile HSS EPG her TV remote control to send the call to her answering service or to reject the call. When the set-top box receives either of these 4 9 commands, it forwards the request to the IPTV server, which 2 15 Remote Remote 8 13 Application sends it to the IPTV service package. The service package sends a Approval 5 10 Server message to the Service Broker, which specifies that the answering 14 Module Interface IPTV service is receiving the call or that the call is rejected. In either Middleware Service case, the Service Broker ends the call to Alice’s phone. 3 Broker Broker If Alice answers the call with her phone, the S-CSCF gives the call receipt to the Service Broker (step 8). The Service Broker 15 6 11 then forwards the SIP message through the S-CSCF to Bob’s 1 7 12 phone (step 9), establishing the call. Meanwhile, the Service Broker sends a message to the IPTV service package, which instructs the IPTV server to remove the call notification Set-Top STB Phone IM Box Client information from Alice’s TV screen and to initiate temporary recording of the TV content (step 10). The IPTV server instructs a Nanny Bob Alice network DVR to record the content (step 11). When Alice hangs up, the call termination event is passed through Figure 3: Remote Approval the S-CSCF to the Service Broker and to the IPTV service package, which informs the IPTV server that recording may end (step 12). The IPTV server alerts Alice that the recorded content is While parents Alice and Bob are at work, their children are at available (step 13), and Alice selects a playback option to view home supervised by Nanny. She has logged in to the IPTV service the material (step 14). with a restricted user account set up for the children by Alice and Bob. When Nanny tries to access a TV programming that is
  5. 5. currently blocked due to profile configuration (e.g., TV rating), station a user is watching by monitoring all channel changes the IPTV middleware intercepts and displays an authorization could overload the IPTV server. request dialog. Nanny chooses to forward the authorization using the remote control of the STB (step 1). The IPTV middleware • Blending applications may create interference on user determines the corresponding list of authorization users (Bob and devices. For example, in our first application, outputting Alice) configured in the user profile (step 2), and sends a caller info and associated command menus can interfere with asynchronous SOAP request to the Service Broker (step 3), which displays from the TV content provider (under control from includes the requesting user name, ordered list of authorization the IPTV server). In some cases, avoiding this interference users’ identifiers, a globally unique identifier for the TV program, might require some modification of the server or set-top box. and optionally link(s) to additional information about the Likewise, gathering input from the TV viewer without requested content. interference from the IPTV server might require service coordination. Similarly, devices suitable for one part of a Upon reception of the request message, a Remote Approval blended service might not be readily suitable for other parts. steplet invoked by the Service Broker Engine parses the message For example, gathering user input for phone controls from a parameters and checks the presence of the first authorization user TV remote control requires careful control design. in the list (step 4). Based on the presence information, the steplet invokes the appropriate application (step 5) in order to contact the authorization user. E.g., a voice server initiates a phone call to 4. RELATED WORK Bob by means of SIP signaling (step 6) through the voice dialog Blending IPTV and telephony applications requires integration of Bob can authorize or deny authorization for the requested the control and media processing functions of two distinct forms program (step 7). However, Bob decides for the authorization of communication. IPTV applications focus on user transactions forward option to Alice. The voice server processes the dialog and involving services obtained through longer-term sessions. encapsulates Bob’s choice in a corresponding message to our Telephony applications focus on user transactions involving real- Remote Approval steplet (step 8). time interactions associated with shorter-term sessions. While blended IPTV/telephony applications are still novel, substantial Since Bob has chosen to forward the request, our steplet checks work has addressed the combination of Web and telephony Alice’s presence (step 9) and forwards the authorization request to functions. her (step 10 and 11). In our example, Alice receives and instant message with a link to additional information (e.g., online TV IMS specifies network interfaces and collections of servers to guide with short video trailors). Based on the information handle telephony events and to engage application servers that provided, she finds the program appropriate for her children and may implement Web-based services [1]. IMS specifies both SIP grants access to it. Her response (step 12) is processed by the and Parlay interfaces [5] between call handling components and application server (step 13), which sends a corresponding message the application servers. However, it is out of scope of IMS to the steplet and terminates the dialog. Subsequently, the steplet standards to specify interactions or relationships among signals the response to the IPTV middleware encapsulating the application servers. Consequently, the specifications neither necessary information in a SOAP request (step 14). As a result, include service bundling and blending nor specifically address the IPTV middleware updates the user-specific profile IPTV applications. information and simultaneously sends a notification to the STB. Service Delivery Platforms, including Connected Services Future work includes invocation of search engines by an IPTV Framework from Microsoft [6] and Websphere from IBM [7] are steplet in order to provide additional information about the software suites that support the interaction of Web-based requested TV program. applications and telephony events. These software packages also address application interactions. However, these packages do not themselves handle telephony events and they do not integrate real- 3.3 Issues time telephony events with other applications. During the implementation of the two example applications, several issues had to be addresses that potentially create challenges for many blended applications. Especially noteworthy 5. SUMMARY are the following: We have presented and described an infrastructure that enables efficient and true blending of IPTV services. While based on the • Mapping identifiers among various component applications IMS foundation, our infrastructure introduces a novel component, is a challenge. Mapping of telephone numbers or IM body the Service Broker. Utilizing dynamically loaded steplets, the names, user IPTV subscriber names, and IPTV server or set- Service Broker enables service interworking with unified control top box addresses is required. These mappings are handled over multiple applications. by the Service Broker IPTV service package. Separating a user id from a set-top box or TV id would require additional We implemented two service examples that illustrate the input from the users to establish their identities. This possibilities for efficiently blending IPTV services through the use information could also be maintained in the IPTV service of our infrastructure. In the first example, events from the package, or in the IPTV middleware server. telephony world triggered events in and controlled the IPTV service. In the second example, the IPTV service triggered the • Scaling applications to large user communities is a common establishment of interactive sessions in the telephony an IM problem. In this or related applications, scaling may be world. The implementation of these two examples revealed major limited by requirements for sharing information between the challenges inherent to service blending efforts. For example, user set-top boxes and servers. For example, tracking what during the development we had to address scalability issues in
  6. 6. terms of signaling messages and state maintenance, and [3] Anders Kristensen. SIP Servlet API, Version 1.0, February interworking issues in terms of user and address mappings. 4, 2003. Retrieved on January 17, 2006, from: 6. ACKNOWLEDGEMENTS [4] Danny Coward. Java Servlet Specification, Version 2.3, We would like to thank Bill Roome for his leadership in September 2001. Retrieved January 17, 2006, from: developing the Service Broker architecture, and Kristin Kocan and her team for bringing the system to life. spec.pdf. [5] Parlay Group. Parlay 5.0 Specifications. Retrieved January 7. REFERENCES 17, 2006, from Parlay Group web site: [1] Gonzalo Camarillo and Miguel-Angel Garcia-Martin. The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the [6] Microsoft. Enabling Service Delivery Using the Microsoft Cellular Worlds. John Wiley & Sons, August 2004, ISBN Connected Services Framework. Whitepaper, January 2005, 0470871563. retrieved January 17, 2006, from Microsoft Corporation web site: [2] Nicholas M. DeVito, Richard T. Emery, Kristin F. Kocan, William D. Roome, and Byron J. Williams. Functionality and [7] IBM. WebSphere Application Server for Telecom. Retrieved Structure of the Service Broker in Advanced Service January 17, 2006, from IBM: http://www- Architectures. Bell Labs Technical Journal, 10(1), pp. 17–30, May 2005, Wiley Periodicals.