Internet Draft Lark-Kwon Choi Document: draft-lkchoi-mmusic-iptvdbs-req-00.txt Dae-Gun Kim 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 Requirement of service provider for the Data Broadcasting Service over the internet protocol television 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 of service provider for the Data Broadcasting Service (DBS) framework about multicasting with unicasting transmission method over the internet protocol television (IPTV). Also, network and DBS receiver requirements are presented. These requirements are designed to guide development of DBS transport protocol for efficient interactive multimedia applications in Moving Picture Expert Group 2 Transmission Stream (MPEG2-TS) over internet protocol (IP) with the Session Description Protocol (SDP). Table of Contents 1. Introduction ...............................................2 1.1 Background and Motivation ..................................2 1.2 Scope of This Document......................................3 2. Conventions.................................................4 3. Terminology.................................................4 4. Use Cases Requiring DBS in IPTV.............................5 4.1 Program Linked Use Cases....................................5 4.2 Program Supplementary Use Cases.............................5 4.3 Program Independent Use Cases...............................6 5. Requirements................................................6 5.1 General Requirements........................................6 5.1.1 Independence of DBS Data Transmission.......................6 5.1.2 DBS Interactivity of Multiple Accesses......................6 5.2 Multicasting with Unicasting Transmission Requirements......7 5.3 Network Requirements........................................8 5.3.1 Bandwidth...................................................9 5.3.2 Reliability.................................................9 5.3.3 Congestion Control..........................................9 5.4 Receiver Requirements.......................................9 5.5 Media Format Requirements..................................10 6. Security Considerations....................................10 7. IANA Considerations........................................11 8. Normative References.......................................11 9. Informative References.....................................11 10. Authors's Address..........................................12 11. Full Copyright Statement...................................12 1. Introduction 1.1 Background and Motivation As explodes the high-speed IP networks and as progresses convergence between IP-based communication and broadcasting area, demands for the bidirectional interactive high quality services are increase. With this requests, TPS (Triple Play Service) appears to satisfy the customer expectation. Recently IP based broadcasting service such as Internet Protocol television (IPTV) becomes an important key service with interactive data broadcasting services (DBS). DBS is originated from the text titles with program guide in the analog broadcasting environments. Nowadays, with combination of digital technology, DBS includes multi-channel multimedia data service relating to the Video/ Audio program, multiparty real time communication, e-commerce providing specific information, and on demand service appropriate to the personal taste. Especially, with the equipment of the return path for the interconnection network service, user wants not only high-quality multi-channel service but also new ways to interact with content providers and other customers. Now, there are several DBS providers such as satellite, cable, and IPTV service provider using satellite, cable, and IP network respectively. Unfortunately, due to the limit of the bandwidth of uplink as return path in satellite and cable network, there are some difficulties for the dynamic and seamless DBS. Meanwhile, thanks to the broadband convergence network such as FTTH supporting enough bandwidth, IPTV is able to provide bidirectional interactive DBS vividly. Standard for the interactive DBS is in progress actively in many organizations. For example, there is DVB-MHP for the satellite data service, OCAP for the cable network which is nominated by CableLabs and ACAP for the terrestrial data service which is proposed by ATSC. However, because there is no explicit standard for the DBS over IPTV, a lot of Telco prepare its interactive DBS with different format and standard. This causes incompatible service model and platform. Therefore, it is necessary to establish IP-based optimal DBS standard including efficient transmission standard to support various powerful interactive service in IPTV. IPTV has affinity to adopt multicasting transmission of satellite and cable data broadcasting system and furthermore integrate it with unicasting transmission to provide bi-directional interactive services. IP multicasting with unicasting transmission requirements must be presented to reduce current waste of bandwidth and to magnify incomplete data service for the perfect service. Also for the reliable delivery of the Video, Audio and data contents, it is essential to establish service requirements of bandwidth and congestion control in network view. Finally, DBS receiver supports a lot of program supplementary services in one channel without channel change by joining several multicasting channels including supplementary data channel simultaneously. Besides, DBS receiver have to recognize the data renewal to synchronize with the DBS database server. DBS data should be supported in various media format for the delivery of substantial contents. 1.2 Scope of this document This document defines requirements of DBS must satisfy in order to transmit interactive multimedia data to customers in IPTV without seamless. Since IP network can support the enough bandwidth to adapt the multicast and unicast simultaneously, DBS is efficiently usable to practical service applications according to the service provider's scenario. In considering various service scenarios in DBS over IPTV, this document points several use cases requiring DBS in IPTV. Then including some advantages of previous multicasting or unicasting transmission mechanism, this paper explained how the combination of multicasting and unicasting transmission method contributes to DBS applications diversely in IPTV. Following this, this document proposes general requirements of DBS and multicasting with unicasting transmission requirements. Next, MPEG2 over IP requirements will be provided with points of bandwidth, network reliability and congestion control. Finally, receiver requirements to be supported in STB, compatibility of media format are discussed with security considerations. 2. Convention 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. 3. Terminology 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), data broadcasting service (DBS), Internet, and so forth. 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. Data Broadcasting Service (DBS): DBS is a generic term to describe the data broadcasting service to transmit information and interactive data including multimedia. DBS data: A set of data to provide DBS. DBS data describes the feature of multimedia content used in DBS. DBS System: A set of system consisting of several data entities such as data generation, data delivery, data transmission and data return server. DBS Provider (sender): A DBS provider is a logical entity that provides (sends) DBS to one or more DBS receivers. DBS Receiver (subscriber): A DBS receiver is a logical entity that receives (subscribes) DBS from a DBS provider. DBS interactivity: interactive connection for bi-directional communication between DBS data or entities. DBS Transport Protocol: A Protocol that transports DBS data from a DBS provider (sender) to DBS receiver. DBS network: A network that DBS data is transmitted from DBS provider to the DBS receiver. DBS database server: A database server that has DBS data in DBS provider system. 4. Use Cases requiring DBS in IPTV DBS in IPTV is able to support very wide range of uses cases for enabling exciting and informative contents and multimedia delivery. The following few sections define three types of use cases and describe each application to provide an understanding of the scope and type in DBS over IP network 4.1 Program linked use cases Program linked service in DBS is the delivery of specific data related to the Video/Audio contents over multicasting or unicasting IP network. Object Carouselled metadata transfer method is a base level of carrying data service. A sender of program linked service synchronizes the link data for the specific information with some part of video streaming according to the time schedule or certain region of image before the service. There are lots of uses cases in program linked data services. For example, in drama or sports program, the receiver gets the last or present synopsis of the program and character's feature. In addition, live event such as music concert or sport ticket service is possible with a special TV program. Also, in economic or political contents, user can join the program with poll, ARS, and quiz on the spot via the screen. Sometimes, customer may buy same necklace of heroine viewing the movie in linked commerce service. These use cases screen skin can be organized in accordance with the service scenario of the provider. 4.2 Program supplementary use cases Program supplementary data service is on the spot information transmission when the customer requires certain information such as news, weather, stock and situation of the traffic viewing the Video/Audio channel in IPTV. Although supplementary data is not related to the Video/Audio channel contents directly, it is useful and convenient to catch out the quick and summary data with enjoying other program simultaneously. Generally, in cable or satellite, supplementary service cannot support various supplementary data in one channel (as usual, 1 or 2 kinds services are possible) because of the narrow bandwidth. So, when the user wants to receive other information in one channel, he or she must change the channel to get other information. While, in IP network, due to the enough bandwidth such as FTTH using optical communication system, many kinds of supplementary data can be provided in one channel. So far, there are not obvious standard in DBS over IP, a lot of service provider use different methods or protocols to develop DBS in IPTV. In this point, the standardization of DBS in IPTV is necessary. 4.3 Program independent use cases DBS in IPTV supports not only Video/Audio channel connected service but also program independent service. In different with channel connected service, program independent service is oriented from the data communication for the delivery of wide range of information likewise internet. Service provider re-organizes and refines the source material of the internet to adapt it into the TV screen with convenience. Program independent use cases basically include informative contents delivery such as news, weather, stock, horoscope, travel guide and traffic according to the user's region or situation. Besides, there are many use cases supporting real time multiparty communication session. For example, distance learning participants can receive the lecture and interact with the tutor using messenger or video communication in IPTV. Also, network multiplayer game and karaoke can be provided using the unicasting and multicasting protocol for the multiparty players. Finally, T-banking and T-commerce service is possible with relation to the on-line bank or credit card. 5. Requirements 5.1 General Requirements 5.1.1 Independence of DBS data transmission REQ GEN-1: Various delivery mechanisms of DBS data in the IPTV MUST be allowed. This leads to flexibility in selecting DBS transmission method of multicasting and unicasting according to the situation of service provider. REQ GEN-2: DBS SHOULD support many different data transmission formats according to the service scenario of service provider. This provides adaptability in designing DBS transport protocol suited to various service scenarios. 5.1.2 DBS interactivity of multiple accesses REQ GEN-3: DBS providers MUST be allowed to communicate with any number of DBS receivers interactively and simultaneously. REQ GEN-4: DBS subscriber MAY be permitted to access with any other DBS subscriber in multiparty communication sessions. This might guide the flexibility and stability for the DBS transport protocol as increase the number of the subscriber and service in multiple interactivity communication sessions. This also provides expansion of new DBS for the connection with existing data service applications. 5.2 Multicasting with Unicasting Transmission Requirements This section describes multicasting with unicasting transmission requirements based on the assumption that data transmission method of DBS can be modified a little according to the service scenario and network situation. Also, in the point of data delivery properties, it is assumed that large number of data and subscriber are scalable. Generally, previous data broadcasting services are transmitted in a terrestrial, cable or satellite broadcasting TV with unidirectional delivery being able to provide various media services to many receivers. Recently, although bidirectional DBS delivery is possible, due to the limited bandwidth of uplink, many service providers prefer multicasting transmission method. In IPTV, DBS can be delivered with IP interconnection for efficient bidirectional data communication using multicasting and unicasting transmission together due to its enough bandwidth. REQ-MUL-1: IPTV DBS transmission method SHOULD be able to support multicasting and unicasting together according to its service planning. This might lead to the transport protocol flexibility to develop transmission method efficiency in considering of IP network characteristics. When high simultaneity is expected with or without random user request, multicasting method is more effective. On the other hand, when the user requests service randomly with interactive connection or the chance of simultaneity between user requests is low, unicasting method can reduce the traffic congestion and provide more diverse DBS. Figure-1 helps the understanding of multicasting with unicasting transmission. < IP media platform > < Service > ---- ----------------------------- ----------------- | PP | --> | Multicast Video/ Audio | --> | Channel service | ---- | Broadcasting System | ----------------- ----------------------------- ---- ----------------------------- -------------------- | | --> | Data Broadcasting System | --> | | | | ----------------------------- | | | DP | | Program linked, | | | ----------------------------- | supplementary, | | |<--> | Data Return Server |<--> | independent DBS | ---- ----------------------------- | | ---- ----------------------------- | | | CP |<--> |Unicast Broadcasting Server |<--> | | ---- ----------------------------- -------------------- Figure 1. example of DBS flow diagram PP, DP and CP is program provider, data provider and contents provider respectively. As represented in the figure-1, unidirectional arrows represent multicasting and bidirectional arrow means unicasting transmission between and . According to the service scenario, as describe in the DBS use cases, multicast and unicasting can be adjusted each DBS. Data Return Server receives user's service request and find proper data in database server. Then Unicast Broadcasting Server sends the requested data to the receiver. REQ-MUL-2: DBS system is RECOMMENDed to classify two multicast group with In-Band Group for the Video/ Audio program including program linked data application and Out-of-Band Group for SI Service Information) data. Because the SI data in DBS of IPTV contains metadata of every content including the information of transport stream and service with events, if these are placed in the In-Band, it is very redundant to waste bandwidth of every connection. Therefore, separated multicast group to transmit SI data is more efficacious. REQ-MUL-3: DBS system is REQUIRED to control and monitor IGMP (Internet Group Management Protocol) Multicast group join with IP network specific parameter such as IP address and port. In different with the terrestrial, satellite and cable operation, IP network needs IP-specific network parameter to distinguish and join diverse multicast group. Also, DBS system should recognize the state of IGMP join to receive MPEG2 TS or change to another connection. 5.3 Network Requirements 5.3.1 Bandwidth REQ-NET-1: DBS network MUST recognize prerequisite bandwidth of each DBS data application to ensure total necessary bandwidth of DBS including Video/ Audio streaming contents in IPTV. This points the indispensable total bandwidth of DBS in IPTV to support seamless data transmission. REQ-NET-2: DBS network is RECOMMENDed to use of priority regeneration of DBS data stream to allocate enough bandwidth about requested service for the quick reflection of user's service order. 5.3.2 Reliability REQ-NET-3: DBS transport protocol MUST support reliable data transmission in IP interconnection. REQ-NET-4: DBS network is RECOMMENDed to use of QoS(Quality of Service) and FEC(Forward Error Correction) for low packet loss and low delay with packet correction. REQ-Net-5: DBS network is RECOMMENDed to monitor packet loss to ensure the error rate is within acceptable limit. 5.3.3 Congestion control REQ-NET-6: DBS using internet protocol network MUST provide internet-friendly congestion control for adaptation of service to the IPTV. REQ-NET-7: DBS system SHOULD control the lifetime of application data when its lifetime is over or changed according to the service user request. This might lessen the congestion of network because the service providers don't have to send update information periodically and invalidate unnecessary data without additional notifications. 5.4 Receiver Requirements REQ-REC-1: DBS receiver MUST interact with the DBS sender bi- directionally to support multicasting and unicasting transmission. REQ-REC-2: DBS receiver is RECOMMENDed to join several multicasting channels simultaneously to support various program supplementary data services in one channel without channel change. In receiver, by linking up one channel out of many selective Video/ Audio program channels and joining continuously metadata multicasting channel at the same time, the service provider organize both various program supplementary data broadcasting services and Video/Audio program in one screen concurrently. REQ-REC-3: DBS receiver is RECOMMENDed to use multicasting transmission to get metadata for the DBS with Video/ Audio contents streaming including linked data and to take advantage of unicasting transmission to acquire more specific information. This enhances the service quality by offering plentiful information and quick access for the updated data. Also, it can decrease the congestion of the network by allocating appropriate bandwidth to each data application and utilizing multicasting and unicasting selectively according to the DBS use cases. REQ-REC-4: DBS receiver SHOULD be informed of DBS data change to keep synchronization with the data of DBS database server and update DBS data. Since new DBS data can be added as time elapses, the DBS database server change unavailable data to new one and update its service by renewing former data to vivid one. Also, DBS provider and receiver interact with each other to check present synchronization of data and to maintain up-to-date data in DBS. 5.5 Media format Requirements REQ-MED-1: DBS data MUST be supported in any media format to enable the DBS system provide many kinds of multimedia contents without media format conversion. This might lead basic environments for the flexibility to design wide and rich service scenario according to the service provider. 6. Security Considerations Data broadcasting service observes the DBS transport protocol to deliver DBS data from the DBS provider to one or more DBS receivers. The DBS data need to be protected against unauthorized altering or deletion in its delivery. REQ-SEC-1: DBS data MUST be possible to authenticate to protect its information on the way. REQ-SEC-2: DBS data SHOULD be possible to deliver confidentially to the individual users or group with data encryption. Security of DBS data can be obtained by using security solution such as Digital Right Management (DRM) or CAS (Conditional Access System). The originator can authenticate the DBS data before sending or reinforce the security of network. REQ-SEC-3: It MUST be possible to authorize user access to DBS data differently according to the authorization level. REQ-SEC-4: It MAY be possible for DBS provider to request certain authorization to the DBS receiver to check the access level or right. DBS data may be protected at different levels according to the importance. Some DBS data freely accessible while crucial data may require authorization. 7. IANA Considerations There are no IANA considerations within this document. 8. Normative References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 9. 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] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ [5] 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. [6] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000. [7] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3.", RFC 3376, October 2002. [8] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. [9] Chunglae Cho; Intak Han; Yongil Jun; Hyeongho Lee "Improvement of channel zapping time in IPTV services using the adjacent groups join- leave method", Advanced Communication Technology, 2004. The 6th International Conference on Volume 2, 2004 Page(s):971-975 [10] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [11] M. Westerlund, "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004. [12] A. B. Roach, "Session initiation protocol (sip)-specific event notification," RFC 3265, Internet Engineering Task Force, June 2002 10. Authors's Address Lark-Kwon Choi KT. 17, Woomyeon-dong, Seocho-gu, Seoul, 137-792 Korea Email: biorock@kt.co.kr Dae-Gun Kim KT. 17, Woomyeon-dong, Seocho-gu, Seoul, 137-792 Korea Email: dkim@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 11. 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-lkchoi-mmusic-iptvdbs-req-00.txt Expiration Date: December 2005