kim-mmusic-iptv-req-00.txt

Internet DRAFT - draft-kim-mmusic-iptv-req

draft-kim-mmusic-iptv-req

Last Version:	draft-kim-mmusic-iptv-req-00.txt	Tracker Entry
Date:	`15-Jul-2005`
Disposition:	expired

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.

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.

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 (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