[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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.

<Contens>        < 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 <IP media platform>
  and <Service>. 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

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/