Internet Draft Dae-Gun Kim Document: draft-kim-mmusic-iptv-req-00.txt Lark-Kwon Choi Expiration Date: December 2005 Sang-soo Lee Jin-Han Kim KT July 2005 Internet DraftDae-Gun KimDocument: draft-kim-mmusic-iptv-req-000.txt Lark-Kwon ChoiExpiration Date: DecemberApril 2005Sang-soo LeeJin-Han KimKTJulyOctober 20052 Requirements for Internet Media Guides on Internet Protocol Television Services draft-kim-mmusic-iptv-req-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document specifies requirements for implementation of Internet Media Guide (IMG) over Internet Protocol Television (IPTV) because there are still different concepts about applications and technical implementation of IMG. Triple Play Services (TPS) for IPTV need more efficient and integrated IMG than existent IMG for ordinary TV. Such variations raise not only the question of compatibility between different vendors of IMG systems, but bring the confusion at consumer side: which one system is most suitable to viewers and what are the criteria for suitability of IPTV IMG system for viewers. These requirements are designed to guide choice and development of IMG feature. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1 Introduction ...................................... 2 2 Terminology ....................................... 4 3 Types of IMG on IPTV .............................. 5 3.1 Mosaic IMG ........................ ............... 5 3.2 Text IMG .......................................... 6 3.3 BoxList IMG ....................................... 6 3.4 Mini IMG ....................... .................. 7 3.5 Ticker IMG ........................ ............... 7 4 Requirements for IPTV.............................. 8 5 IANA Considerations ............................... 10 6 Normative References .............................. 10 7 Informative References ............................ 10 8 Acknowledgements .................................. 10 9 Authors' Addresses ................................ 11 10 Full Copyright Statement .......................... 11 1 Introduction Recently, IPTV - Internet protocol television - refers to the delivery of digital television and other audio and video services over broadband data networks using the same basic protocols that support the internet. There is nothing new about the idea of using internet technology to deliver video, but internet protocol television should not be confused with the web experience of streaming video, which has generally fallen far short of anything we might expect to see on television. With increasing broadband access speeds, together with improvements in digital video compression, it is now possible to deliver high- quality video services over a telephone line. A small decoder box can connect a television to a telephone or network point, rather than an serial socket, cable or satellite feed, and in theory the pictures should be just as good. Using new advanced compression schemes, in the future it will even be possible to deliver high-definition television in this way. While the public internet may not currently be able to guarantee the quality of service necessary for live broadcasts, it is certainly possible to download programs to a local storage device. A number of start-ups are already looking to exploit the opportunity to cut out cable companies and provide a package of programming without incurring the massive capital expenditure associated with building their own network. Significantly, it becomes economically viable to reach a global market, even with niche material. The IMG (Internet Media Guide) imports programming information from broadcaster or transmitter sources. The viewers can then search, filter, sort, and select programs for immediate or future viewing. The IMG file is accessed through the IMG loader, or it is streamed steadily for immediate IMG content refreshing in case of interactive IMG that gathers IMG information through IP networks. An IMG is used to describe a set of multimedia services (e.g. television program schedules, content delivery schedules) but may also refer to other networked resources including web pages. IMGs provide the envelope for metadata formats and session descriptions defined elsewhere with the aim of facilitating structuring, versioning, referencing, distributing, and maintaining (caching, updating) such information. The EPG metadata may be delivered to a potentially large audience, who use it to join a subset of the sessions described, and who may need to be notified of changes to this information. Hence, a framework for distributing EPG metadata in various different ways is needed to accommodate the needs of different audiences: For traditional broadcast-style scenarios, multicast-based (push) distribution of EPG metadata needs to be supported. Where no multicast is available, unicast-based push is required, too. Furthermore, IMG metadata may need to be retrieved interactively, similar to web pages (e.g. after rebooting a system or when a user is browsing after network connectivity has been re-established). Finally, IMG metadata may be updated as time elapses because content described in the guide may be changed: for example, the airtime of an event such as a concert or sports event may change, possibly affecting the airtime of subsequent media. This may be done by polling the IMG sender as well as by asynchronous change notifications. However, generally we expect IMG Senders to be well-connected hosts. Finally, with many potential senders and receivers, different types of networks, and presumably numerous service providers, IMG metadata may need to be combined, split, filtered, augmented, modified, etc., on their way from the sender(s) to the receiver(s) to provide the ultimate user with a suitable selection of multimedia services according to her preferences, subscriptions, location, context (e.g. devices, access networks), etc. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Internet Protocol Television (IPTV): Digital TV service is provided over IP networks such as DSL and fiber broadband access networks to television set. IPTV includes the use of the IGMP signaling protocol to switch channels, and the use of multicasting to improve efficiency by ensuring that only the channels that watched are transmitted to the subscriber. IPTV services also can include Video on demand(VOD), Voice of IP (VoIP), Internet, etc. Triple Play Services (TPS): Integrated services of telephone (voice), Internet(data), digital TV(video) are provided to customers by simple and single networks. These services are combined close to each other. Internet Media Guide (IMG): IMG is a generic term to describe the formation, delivery and use of IMG metadata. The definition of the IMG is intentionally left imprecise. IMG Element: The smallest atomic element of metadata that can be transmitted separately by IMG operations and referenced individually from other IMG elements. IMG Metadata: A set of metadata consisting of one or more IMG elements. IMG metadata describes the features of multimedia content used to enable selection of and access to media sessions containing content. For example, metadata may consist of the URI, title, airtime, bandwidth needed, file size, text summary, genre and access restrictions. IMG Delivery: The process of exchanging IMG metadata both in terms of large scale and atomic data transfers. IMG Sender: An IMG sender is a logical entity that sends IMG metadata to one or more IMG receivers. IMG Receiver: An IMG receiver is a logical entity that receives IMG metadata from an IMG sender. IMG Transceiver: An IMG transceiver combines an IMG receiver and sender. It may modify received IMG metadata or merge IMG metadata received from a several different IMG senders. IMG Operation: An atomic operation of an IMG transport protocol, used between IMG sender(s) and IMG receiver(s) for the delivery of IMG metadata and for the control of IMG sender(s)/receiver(s). IMG Transport Protocol: A protocol that transports IMG metadata from an IMG sender to IMG receiver(s). IMG Transport Session: An association between an IMG sender and one or more IMG receivers within the scope of an IMG transport protocol. An IMG transport session involves a time bound series of IMG transport protocol interactions that provide delivery of IMG metadata from the IMG sender to the IMG receiver(s). 3 Types of IMG on IPTV There are 5 types of IMG on IPTV that are considered as performed on premise that viewer wishes to watch certain types of programs. These types of IMG can be combined for more efficient IMG for example Ticker IMG can include Mini IMG or Text IMG. Taking recent trends in IPTV viewing habits into account, our aim is to make it easier for the viewer to select programs based on various individual viewing habits. We would like to develop an IMG that combines program recommendations, sorting, and retrieval by using the well-known protocols such as SAP, SIP, and SDP. 3.1 Mosaic IMG This Mosaic IMG offers multiple channels viewing moving pictures simultaneously at a screen as shown in Fig.1. Mosaic of 8+ channels can be selected with sound at a same screen. Other Interactive services can be inserted at a same screen. This Mosaic IMG can eliminate the difficulty and worry in program selection and make it easy for the viewer to find and watch desired programs from the many and varied programs available. CH in figure means several services such as live video channel, audio channel, Internet channel, telephone service channel, etc. ---------------------------------------------- | | | ----- ----- ----- ----- | | | | | | | | | | | | | CH1 | | CH2 | | CH3 | | CH4 | | | ----- ----- ----- ----- | | | | ----- ----- ----- ----- | | | | | | | | | | | | | CH5 | | CH6 | | CH7 | | CH8 | | | ----- ----- ----- ----- | | | ---------------------------------------------- Fig.1 Example of Mosaic IMG 3.2 Text IMG This Text IMG offers text- based multiple channels and program information at a screen as shown in Fig.2. Text IMG is in fact a table, where the TV channels are listed vertically, and the horizontal axis represents the time schedule for particular broadcast; on horizontal axis are quoted the particular shows too. We have chosen further, with remote control, one of the listed items. ---------------------------------------------- | | | 01:00 02:00 03:00 04:00 ....Time Zone | | CH1 ... | | CH2 | | CH3 | | CH4 | | CH5 | | CH6 | | CH7 | | CH8 | | ... | ---------------------------------------------- Fig.2 Example of Text IMG 3.3 BoxList IMG This BoxList IMG offers both the text IMG and the small moving live channel in small window size as shown in Fig.3 that allows channel information and random zapping. Other Interactive services can be inserted at a same screen. ---------------------------------------------- | 01:00 02:00 --------------------- | | CH1 ... | | | | CH2 | | | | CH3 | | | | CH4 | Live CH1 | | | CH5 | | | | CH6 | | | | CH7 | | | | CH8 --------------------- | | ... | ---------------------------------------------- Fig.3 Example of BoxList IMG 3.4 Mini IMG This Mini IMG offers the minimal information about the related current watching channel by viewing the text-only information as shown Fig.4. The Mini IMG has small overlap window on live channel screen that allows overseeing channel and program information and random channel zapping. In such situation, it becomes easy to select a program that one would like to watch live selected channel and the scheduling information of other channels. Mini IMG displays semi- transparently over live video/audio channel service. ---------------------------------------------- | | | | | | | Live CH1 | | | | | | | |--------------------------------------------- | | 12:00 13:00 14:00 | | CH1 .... | ---------------------------------------------- Fig.4 Example of Mini IMG 3.5 Ticker IMG This Ticker IMG offers the directory search to find the desired services by tree navigation method as shown Fig.5. The Ticker IMG supports the personalized program guide using e-commerce techniques and new concepts in interactive television. Ticker IMG is the hierarchical IMG of all services for IPTV and also displays semi-transparently over live video/audio channel service. ---------------------------------------------- | | | CH1 | | CH2 | | TV --------------CH3 | | RADIO CH4 Live CH1 | | VOD CH5 | | GAME CH6 | | News&Info CH7 | | Communication CH8 | | | ---------------------------------------------- Fig.5 Example of Ticker IMG 4 Requirements of IMG for IPTV These requirements provide flexibility in selecting/designing IMG transport protocol suited to independent or dependent various services such as video, audio, data services, video related-data services, video related-VoIP services, etc. REQ IPTV-1: Carrying different services of TPS in the IMG MUST be allowed REQ IPTV-2: Delivery mechanisms SHOULD support many different applications services to keep the system interoperable with existing applications. REQ IPTV-3: IMG receivers MUST be allowed to communicate with any services simultaneously or enable IMG receivers with intermittent access to network resources connectivity to receive and adequately maintain sufficient IMG metadata. This document assumes that IMG senders are continually connected for the duration of services or intermittently connected. REQ IPTV-4: The IMG delivery mechanisms MUST allow the combination of several types of IMG. This is for the purpose of extending functionality (e.g. several or one protocol(s) to provide all the needed operations). Applications can select an appropriate operation set to fulfill their purpose. REQ IPTV-5: The IMG system MUST be flexible in choosing both sender and receiver-driven delivery schemes. Sender-driven delivery occurs when initial IMG metadata are delivered. And the receiver-driven delivery occurs when customers request the specific services such as VoIP, Internet services. REQ IPTV-6: The IMG system MUST allow delivery of personalized IMG. The IMG system must be able to deal with any variety of viewing habits and with their tendency to change according to their preferences (type of contents, media description, appropriate age group, etc.) and IMG configuration. For example, configuration of Mosaic IMG can be reallocated according to viewerĘs preference such as sports, news, drama, etc. These preferences could consist of filtering rules. When receiving these messages, the IMG sender might respond appropriate messages carrying a subset of IMG metadata which matches the IMG receiver's preferences. For multicast and unicast cases where the IMG sender does not provide customized IMG metadata, the IMG receiver could receive all IMG metadata transmitted (on its joined channels). However, it may select and filter the IMG metadata to get customized IMG metadata by its preferences, and thus drop unwanted metadata immediately upon reception. Personalized IMG might be achieved by changing the IMG descriptions sent and IMG receivers and/or changing the delivery properties (channels used). Thus, customization, as with any feature which affects scalability, should be carefully designed for the intended application, and it may not be possible that a one-size- fits-all solution for customization would meet the scalability requirements for all applications and deployment cases. REQ IPTV-7: IMG metadata MUST be interoperable over any IMG transport protocol, such that an application receiving the same metadata over any one (or more) of several network connections and/or IMG transport protocols will interpret the metadata in exactly the same way. REQ IPTV-8: IMG delivery MUST enable the carriage of any format of application-specific metadata. Thus, the system will support the description of many kinds of multimedia content, without the need for single homogenous metadata syntax for all uses (which would be infeasible anyway). This is essential for environments using IMG systems to support many kinds of multimedia content and to achieve wide applicability. 5 Security Considerations Security requirements of IMG for IPTV will be added to later versions of this I-D. 6 IANA Considerations There are no IANA considerations within this document. 7 Normative References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 8 Informative References [2] M. Handley and V. Jacobson, "SDP: session description protocol," RFC 2327, Internet Engineering Task Force, Apr. 1998. [3] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. [4] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session initiation protocol," RFC 3261, Internet Engineering Task Force, June 2002. [5] Y. Nomura, R. Walsh, J-P. Luoma," Requirements for Internet Media guides," Internet Draft draft-ietf-mmusic-img-req-07, Internet Engineering Task Force, June 2004. Work in progress. [6] Basic, R.; Mocinic, M., "User's requirements for electronic program guide (EPG) in interactive television (iTV)," Video/Image Processing and Multimedia Communications 4th EURASIP-IEEE Region 8 International Symposium on VIPromCom 16- 19 June 2002 [7] Tadashi, Masso Fujiwara, Hiroyuki Kaneta, "Development and features of a TV navigation system," Consumer Electronics, IEEE Transactions on Volume 49, Issue 4, Nov. 2003 [8] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, "A framework for the usage of Internet media guides," Internet Draft draft-ietf-mmusic-img-framework-07, Internet Engineering Task Force, June 2004. Work in progress. [9] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee, "Hypertext transfer protocol HTTP/1.1," RFC 2616, Internet Engineering Task Force, June 1999. [10] A. B. Roach, "Session initiation protocol (sip)-specific event notification," RFC 3265, Internet Engineering Task Force, June 2002. 9 Authors' Addresses Dae-Gun Kim KT. 17, Woomyeon-dong, Seocho-gu, Seoul, 137-792 Korea Email: dkim@kt.co.kr Lark-Kwon Choi KT. 17, Woomyeon-dong, Seocho-gu, Seoul, 137-792 Korea Email: biorock@kt.co.kr Sang-soo Lee KT. 17, Woomyeon-dong, Seocho-gu, Seoul, 137-792 Korea Email: ssllee@kt.co.kr Jin-Han Kim KT. 17, Woomyeon-dong, Seocho-gu, Seoul, 137-792 Korea Email: jinhan@kt.co.kr 10 Full Copyright Statement Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Document: draft-kim-mmusic-iptv-req-00.txt Expiration Date: December 2005 Requirements for Internet Media Guides on IPTV July 2005