Internet DRAFT - draft-lkchoi-mmusic-iptvdbs-req
draft-lkchoi-mmusic-iptvdbs-req
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
