Delivering Quadruple Play with IPTV over IMS

Delivering Quadruple Play with IPTV over IMS Bruno Chatras, Mikhaël Saïd France Telecom Research & Development 38-40 rue du Général Leclerc F-92794 Issy Moulineaux Cedex 9 Email: {bruno.chatras,mikhael.said}@orange-ftgroup.com 1 Introduction The interest in IPTV services is increasing as these are perceived as a potential source of new revenues by telecommunications service providers. IPTV services are actually already being deployed by many of them around the globe and tend to be packaged as "triple play" solutions, including telephony and Internet or even "quadruple play" with wireless aspects. Current solutions are essentially vendor-specific and the services they provide are inherited from those available with terrestrial, cable and satellite television, augmented with features enabled by the availability of an upstream channel such as video on demand (VoD), personal video recorder (PVR), and live TV with trick mode (e.g. pause, fast forward ). However, new needs are emerging along with "quadruple play": access independent solutions, integration in a multiservices environment, availability of enhanced services combining features from every component of the "quadruple play" bundle, etc. A common control plane managing both IPTV services and other multimedia communication services would ease responding to these new needs. The IP Multimedia Subsystem (IMS) [1] defined by 3GPP and extended by ETSI TISPAN provides one possible answer and standardisation bodies such as ETSI TISPAN and ITU-T are already working on such an approach. Section 2 of this paper further discusses the motivations and benefits of using IMS-based solutions in support of IPTV. Section 3 highlights a number of technical challenges that an IMS-based solution has to face. Section 4 provides a technical description of the IMSbased solution under standardisation in ETSI TISPAN [2]. 2 IMS-based solutions design and motivations The integration of IPTV services in an NGN environment is one the key features that the ETSI TISPAN technical body will deliver as part of the second release of its NGN standards. Integrating IPTV in NGN aims at enabling IPTV functions to interact with relevant NGN subsystems and use the capabilities they provide, namely dynamic network attachment and management of transport resources with quality of service control. Two variants are being considered in standardisation bodies. The first way, called "IPTV dedicated subsystem", focuses on the integration of existing market solutions in an NGN environment. Its prime objective is to take advantages from NGN environment without replacing existing IPTV systems. The second way, called "IMS-based", consists in using the IMS as a control plane for IPTV services as for any other multimedia services. The IMS-based solution addresses not only basic broadcast (e.g. Live TV) and streaming (e.g. VoD) services but also aims at combining them with communication services (conversational services, presence services and messaging services) so as to provide end-users with a new multimedia experience. Examples of combined services are "click-to-dial from TV", where a user can initiate a call to a number shown on the TV screen (e.g. during a TV show); "Caller ID on TV", where the identity of the calling party is displayed simultaneously on the TV screen and on the phone sets; call forwarding (to a mailbox) when watching TV/VOD; remote parental control using short messages, etc. Besides its ability to ease the design and implementation of combined services the IMSbased approach brings additional inherent benefits: - Common infrastructure: Almost all large Telcos have plans to deploy an IMS infrastructure in support of the replacement of their TDM-networks. Indeed, according to Gartner, in 2010, 77% of all investment for call control layers is forecast to be based on the IMS. The IMS-based approach will leverage this investment by enabling the support of IPTV services on the same network infrastructure than VoIP services. 1

- Common identity and authentication mechanisms: The IMS identification and authentication framework provides an opportunity to extend the features of existing IPTV services with multi-user subscription capabilities. This will make possible allocating different public identities and service profiles to different users sharing the same IMS / IPTV subscription. Such capabilities will typically be used to manage different lists of subscribed channels associated to different users in the same family. - Common resource management: The IMS relieves IPTV application servers from the task of interacting with transport control functions for the purpose of reserving transport resources. - Multi-access solution: IMS is designed to be access-independent. Using the IMS as a control plane will therefore allow users to access their IPTV services whatever the access they are connected to. Moreover, the multi-access capability brought by the IMS comes with the support of service roaming and service continuity when moving from one access to another. - Common charging mechanisms: As a result of using the IMS for session control IPTV services will benefit from generic charging mechanisms and interfaces applicable to other types of multimedia services. This will facilitate unified billing for multi play solutions. 3 Technical Issues Although the IMS was originally designed as a generic platform for supporting multimedia services, IPTV services bring specific technical challenges that have not yet been fully tackled by IMS standards. 3.1 Discovery and Selection Discovery and Selection (SD&S) refers to a set of procedures that a user needs to go through before invoking any IPTV service. This enables the user to discover available services and retrieve the necessary parameters to activate the selected service. Electronic Program Guides (EPG) and VoD catalogues are part of the service selection information. They can be unicasted (e.g. retrieved by the user from a portal) or multicasted (e.g. received on the user equipment in the form of a specific broadcasted channel). There exist several competing standards for the specification of SD&S procedures and associated information (e.g. DVD-IPI or OMA-BCAST for mobile access). However, the IMS specifications do not currently include explicit support for such procedures. 3.2 Control of media flows Specific time constraints related to media flows control have to be taken into account. Channelhopping delay is one of the major ones for broadcast services. Trick mode operations (e.g. fast forward) in VoD and PVR are also subject to time constraints. In order to avoid that IMS signalling procedures bring extra delays, it is necessary to draw a clear separation between service/session control performed at the IMS level and media flow control handled end-to-end between the user equipment and the content servers. 3.3 Applicability of session concepts to broadcast services Most of the current broadcast services are session-free: once the list of subscribed channels is fetched, the client can perform channelhopping without running any session-related preamble or postamble procedure. With the IMS, introducing the notion of session enables adapting network resources to the services and therefore increases the efficiency of transport resources management. The initiation of the session provides IPTV services with the ability to request and reserve transport resources and modify these at a later stage (e.g. when zapping from SD channels to HD channels). Explicit termination of IMS sessions enables releasing these resources, making them available for other services/users. Moreover, the existence of an explicit session provides criteria for triggering the publication of events to be used for presence services purposes. 3.4 Negotiation of media properties during session establishment IMS procedures for negotiating media properties during session establishment follow the offer/answer model defined in RFC 3264. According to this model, the offerer provides a description of the set of media streams and codecs it wishes to use, while the answerer responds by indicating whether these streams are accepted or not, and which codecs will be used. A stream description in an offer may include a bandwidth attribute, in which case it indicates the desired bandwidth that the offerer is prepared to receive. This model is suitable for conversational services and is not followed today for streaming services where bandwidth information relates to the bandwidth required to transmit a particular content rather than to the capabilities of the two ends of the 2

communication. Therefore, its applicability to IPTV needs to be carefully considered and may require adaptation. 4 Architecture, procedures and protocols The principle of the IMS-based solution lies on the use of IMS architecture and procedures. This section provides further details on the implementation of this principle in ETSI TISPAN standards. IMS compliant SIP/SDP procedures are used to establish, modify and release sessions between the user equipment and the content servers. Session initialisation provides the ability to negotiate the characteristics of content channels and possibly of an associated control channel, and reserve the required transport resources. As far as streaming services are concerned, the protocol running over the control channel is expected to be RTSP (or a subset of it). 4.1 Architecture Selection Session initialisation Modification and termination Discovery Flow control and media delivery UPSF Transport Control Functions RACS Resource and Admission control Media Functions Figure 1: IMS-based solution functional architecture The IMS-based approach relies on a functional architecture centred on the core IMS (i.e. the IMS Call Session Control Functions). When processing session signalling, as for any other multimedia service supported over the ETSI TISPAN NGN architecture, the Core IMS interacts with the UPSF ( Profile Server Function) to download service profile information and with the RACS (Resource and Admission Control Subsystem) to request and reserve transport resources related to the session. Before initiating a session, the user has to proceed to the selection of a service using Discovery and Selection (SD&S) procedures. SD&S includes three steps: 1) Retrieval from a Discovery Function (SDF) of service providers' server addresses (e.g. addresses of service portals); 2) Connection to these servers (known as Selection Functions, SSF) to get information on available services; 3) Retrieval of relevant information (e.g. content identifier, media parameters) required to initiate a session for accessing the selected service. After a service is selected, the relevant content identifier is inserted in the SIP session initiation message sent towards the IPTV Control Function (SCF) that provides access to this service. IPTV Control Functions perform service authorisation during session initiation and modification, which includes checking IPTV users' profiles in order to allow or deny access to the service. IPTV Control functions may also perform credit control and select the relevant IPTV media functions. They act as standard IMS Application Servers, using the ISC interface to communicate with the core IMS. This architecture is designed to make media flows control out of the IMS scope, in order to cope with the issue highlighted in 3.2. Media flows control is therefore supported by other means, using existing protocols: RTSP for trick mode operation during streaming services and IGMP for channel zapping during broadcast services. IPTV media functions are in charge of controlling and delivering media flows to the. They are split into Media Control Functions (MCF), handling media flow control and managing interaction with the UE (e.g. handling of trick-mode), and Media Delivery Functions (MDF) sourcing the actual media flows. For the purpose of implementing combined services IPTV service control functions may interact with Presence Servers or with Application Servers hosting the logic of communication services, using IMS capabilities such as third-party registration, event notification For example, existing IMS presence capabilities can be enhanced with IPTV-specific information such as an indication of the "currently watched channel", allowing user's contacts to share experiences and thirdparty applications to develop specific services based on IPTV presence information. 4.2 Data The provision of IPTV services involves two categories of user data: 3

- IMS user profile data: These data are required for the IMS to operate and are not related a specific service. They include, amongst other parameters, triggering filters (i.e. Initial Filter Criteria - IFC) towards application servers hosting services the user has subscribed to. - IPTV user profile data: these data are specific to IPTV services. They typically include the list of subscribed channels for a broadcast service or the parental control level and language preferences for video on demand services. The IMS user profile data are always stored in the UPSF while IPTV user profile data may be stored at a different location. They may be stored transparently in the UPSF as enabled by the IMS specifications or nearer to the Control Function, if frequent accesses are needed during the processing of service sessions. Such data have to be available to the SCF and may also need to be available to the SD&S functions in order to customise the information they present to the user. 4.3 discovery and Selection As described in a previous paragraph (see 4.1), Discovery and Selection comprises three steps. During the first step, users contact the Discovery Function to retrieve the addresses of the servers ( Selection Function) that can provide them with a description of the available services. This threestep approach allows the network to provide access to services and contents from several service providers. The communication between the user equipment and the SDF relies on the SIP SUBSCRIBE and NOTIFY methods. The user equipment can acquire the knowledge of the Discovery Function address through provisioning or rely on the IMS to route the SUBSCRIBE request to the appropriate SDF, based on initial filter criteria (IFC) contained in the user profile (See figure 2). 1. Suscribe/Notify Procedure : retrieval of service selection servers' addresses Discovery Server 2. information and selection IFC : triggering to the Discovery function Selection Server Figure 2: Discovery and Selection When looking at the above figure, it is worth noticing that only the service discovery step goes through the IMS. 4.4 Streaming session Streaming session initiation is composed of three logical steps: - Establishment of a dialogue between the UE and the IMS: this step encompasses the processing of the SIP session setup, the execution of a service logic by the SCF (e.g. checking of user's rights, determination of appropriate charging rules ) and the selection of the relevant media function; - Negotiation of the control channel between the UE and the media function necessary to support trick mode operation; - Negotiation of one or more content channel(s) between the UE and the media function necessary to deliver the requested content. The three steps can be executed in sequence or in parallel depending on the parameters available at the UE to initiate the session. If the UE has enough parameters to make an offer for control and content channels at this stage, it can combine the session initiation request with the offered control and content channels descriptions in a single message, as illustrated in the figure 3. However, if the only piece of information available to the UE when initiating a session is a content identifier, the control and content channels offers have to be sent from the media function in subsequent SIP messages. The session initiation is performed using the SIP INVITE method. Negotiation of the content and control channel descriptions is achieved by exchanging SDP descriptions embedded in SIP messages, following the SDP offer/answer model. This procedure is very similar to the one already existing for conversational services. However, as explained in one of the above paragraphs ( 3.4), the offer/answer model is indeed suitable for use with conversational services but may require adaptation for use in the context of IPTV services, especially regarding the conveyance of bandwidth information. Work is in progress at the IETF to extend this model with an indication of the bandwidth required by an application. Messages exchanged over the control channel for trick mode operation are imported from RTSP. They do not go through the IMS, thereby answering to the constraint delay as explained in 3.2. 4

IMS procedures also allow the user or the media function to modify an established session. For example, on receipt of RTCP reports indicating downgrade of the network resources, the media function can decide to modify the media flows properties in order to adapt them to network changes. Session modification may also be used with SVC (Scalable Video Coding) when enhancement layers are added or removed during a session. Figure 3 gives an example of a session initiation procedure where the three logical steps identified above are combined. - To provide the RACS with information required to enable multicast access control to be performed in the access node: during session initiation the RACS downloads in the access node a set of filters related to the subscribed channels. This way, when the access node receives an IGMP join request from the UE, it can autonomously allow or forbid access to the requested channel by preventing or enabling packets received from the corresponding source to be forwarded to the UE. Figure 4 gives an example of the broadcast session initiation. SCF MF SCF INVITE (SDP offer for RTSP and content) RACS interactions INVITE (service package id) INVITE (service package id) INVITE (SDP offer) INVITE (SDP offer) 183 Session Progress (SDP offer) Resources control 200 OK (SDP answer) 200 OK (SDP answer for RTSP and content) 183 Session Progress (SDP offer) PRACK (SDP answer) RACS interactions 200 OK (SDP answer) ACK () ACK () ACK () Resources control : download filters in the access node for multicast control PRACK (SDP answer) RTSP Figure 3: Streaming session initiation example When looking at the above figure, it is worth noticing that RACS mechanisms required to reserve transport resource and perform admission control for streaming flows are identical to those required in support of conversational media flows. 4.5 Broadcast session The broadcast session spirit differs from the unicast one since media functions are not part of the initiation process. However, a session can be initiated between the UE and the SCF to allow the later to perform appropriate service checking (e.g. user's rights). Moreover, during session initiation, media parameters related to subscribed channels are exchanged via SIP/SDP messages. This information can be used by the core IMS for two purposes: - To build a request to the RACS for reserving transport resources in the last-mile segment of the network at service session initiation time. Here, it is worth noticing that IMS-initiated mechanisms are not sufficient to perform admission control beyond the access part of the network since multicast flows are shared between users. Additional mechanisms are currently being studied in ETSI TISPAN to enable admission control to be applied to other segments of the network. Figure 4: Broadcast session initiation example As already mentioned, after session initiation, the UE can use IGMP to perform channelhopping without going through the IMS. In case previously allocated resources are not sufficient, an IMS session modification procedure may take place in parallel with the IGMP join. However, this procedure can become heavy and inefficient if frequent modifications are required. ETSI TISPAN is currently studying an alternative solution where receipt of an IGMP message by an access node can trigger a request to modify a resource reservation. This requires extensions to the RACS capabilities and is known as a "pull" procedure. 4.6 Use of IMS for Network Personal Video Recorder and Time shifting Network Personal Video Recorder (N-PVR) allows the user to record a particular live content and watch it later on. The registered content is stored in the network. From a user's point of view, this service involves two steps: 1) The user decides to record a live content. Specific interactions between the user equipment and the AS are necessary to identify the sequence the user wants to record. Such interactions do not rely on IMS session-based procedures and may be achieved using HTTP. 5

2) The user accesses the recorded content. Since this is a registered content such as a VoD, the procedures described in 2.1 for streaming session initiation apply. Network Time Shifting (N-TS) allows trick mode operation to be supported on a live program. This procedure relies on the assumption that the contents of the live programs are continuously recorded in the networks for a certain period of time. Therefore, in order to be able to use trick modes, the user equipment just needs to turn the broadcast session into a streaming session with the server that contains the corresponding recorded content. This is achieved by sending a re-invite request from the UE to the SCF with an indication of the currently watched channel (since the SCF may not know it unless the procedures described in 4.7 are used). When the streaming session is established, the UE can use RTSP to perform trick mode commands on the unicast streams as defined in 2.1. Going back to a live mode is possible and would imply the reverse procedure from streaming to broadcast session. 4.7 Presence enablers Presence enablers are already specified in IMS but do not currently include IPTV specific information. However, existing procedures can easily be used and extended with such information. This is particularly relevant in broadcast services where the presence feature can be used to publish the channel/program currently watched by the user (See Figure 5). This capability can be required by particular applications combining IPTV features with other IMS services (see 2). It could also be used in instant messaging applications where a user would then be able to see what his/her contacts are watching (very much like some existing instant messaging applications already enable users to publish the music they currently listen). However, in order to cope with numerous channel-hoppings potentially causing overloads in the network, a minimum time interval between publications can be set to limit the number of messages sent into the network. Session initiation already done Access Node AS 5 Conclusion IMS is really promising in terms of IPTV services evolution. IPTV session management re-uses existing IMS procedures with very few adaptations as described in this paper. Because these procedures are identical or similar to those used in support of conversational services, this solution facilitates offering advanced services by combining features from the two worlds. Moreover this type of solution benefits from mobility management procedures that are inherent to the IMS and opens the door to IPTV service continuity when moving from one network access to another. IMS-based IPTV will offer a well-standardised solution to provide not only basic IPTV but also quadruple play and enhanced services. It is an opportunity for the IMS to demonstrate its commercial value and will likely be at the centre of multimedia services infrastructure mutualization. 6 References [1] 3GPP TS 23.228. IP Multimedia Subsystem (IMS); stage 2. [2] ETSI TISPAN TS 182 027: IPTV Architecture; IPTV functions supported by the IMS subsystem. 7 Glossary AS HD IFC IGMP IMS IPTV NASS NGN PVR RACS RTSP SD SDP SD&S SIP SVC VoD TS UPSF Application Server High Definition Initial Filter Criteria Internet Group Management Protocol IP Multimedia Subsystem IP Television Network Attachment Subsystem Next Generation Network Personal Video Recorder Resource and Admission Control Subsystem Real Time Streaming Protocol Standard Definition Session Description Protocol Discovery and Selection Session Initiation Protocol Scalable Video Coding Video on Demand Time Shifting Profile Server Function Join (xcast channel 1) Zapping timer PUBLISH (channel 1) IFC PUBLISH (channel 1) Figure 5: presence for broadcast services 6