\documentclass[11pt]{article}
\usepackage{times}
\usepackage{graphics}
\usepackage{ifthen}
\usepackage{i-d}
%\usepackage{rfc}
\usepackage{html}
\usepackage{txtpsfig}
\usepackage{tight}
\usepackage[dvips]{changebar}

\title{A Framework for Internet Program Guide}
\author{Nomura/Schulzrinne}
\shorttitle{pgframework}
\filename{draft-nomura-mmusic-pguide-framework-00}
\wg{}
\expires{April 2003}
\address{Fujitsu/Columbia U.}
\pubdate{\today}
\input{../defs}
 
\begin{document}
\maketitle
\begin{abstract}
This memo specifies a framework for Internet Program Guide. A program
guide is a set of meta-data describing the features of multimedia
content to subscribe, manage and exchange content.  To discuss the
protocol and program guide format, we present a network architectures,
protocol model and program guide data model using some scenarios.
\end{abstract}    

\section{Introduction}

This document presents a framework for Internet Program Guide
\cite{draft-nomura-mmusic-pguide-requirements} to support the
standardization of protocols and formats, which is facilitate the
multimedia content management and exchange.

Program guides allow users to initiate streaming media sessions,
schedule delivery of downloadable or multicast content or listen to
live multicast sessions. Program guide is a set of meta-data
describing the features of multimedia content that is used on many
network platforms and network devices.

The program guides are applicable to various applications and network
environments. Thus, it is necessary to overview network architectures,
protocol models, and data models from various aspects such as
scenarios, goals and implementations to classify technical issues and
engineering tradeoffs. This document does not make choices, and does
not select any particular approach to support Internet Program Guide.

\section{Terminology}

The key words {\MUST}, {\MUSTNOT}, {\REQUIRED}, {\SHALL}, {\SHALLNOT}, 
{\SHOULD}, {\SHOULDNOT}, {\RECOMMENDED},  {\MAY}, and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 \cite{rfc2119}.

User Agent Server (UAS) : A User Agent Server is a logical entity that
sends program guides to A User Agent Client.

User Agent Client (UAC) : A User Agent Client is a logical entity that
receives program guide from a UAS.

User Agent (UA): A User Agent is a logical entity including both a UAS
and UAC.

Program Guide (PG): A Program Guide is a set of meta-data describing
multimedia content. For example, meta-data may consist of the URI,
title, air time, bandwidth needed, file size, text summary, genre, and
access restrictions.

\section{Program Guide Network Model}
\subsection{Devices Using the Program Guide}

We assume that any Internet host can be a source of content and thus
meta data.  Some of the content sources and sinks may only be
connected to the Internet sporadically. Also, a single human user may
use many different devices to access meta data, including
bandwidth-constrained mobile devices. Thus, we envision that program
guides can be sent and received by, among others, by cellular phones,
PDA (Personal Digital Assistant), personal computer, streaming video
server, set-top box, video camera, and PVR (Personal Video Recorder).

\subsection{Network Architectures}

This section distinguishes different types of program guide networks
in order to classify the architecture.

A program guide may be closed information between a particular UAS and
USC, since the PG describes private information, which is not intended
to disclose to other parties. Figure 1 depicts an example of the
network consists of just the UAS and UAC.

On the other hand, some PG is distributed to a lot of UACs
\cite{Luom0205:IP-CC}, because the PG doesn't have any restrictions. This
kind of PG may be distributed from a UAS to UACs, or relayed by the
UAS to USC sessions.

Figure 2 and 3 shows an example of the PG distribution network. In
Figure 3, there are two hosts behave as a UAs.

The relayed network architecture similar to content distribution
network architecture \cite{draft-ietf-cdi-architecture}. In some case,
the PGs are carried over the content network (e.g.  content
distribution network, satellite network, or Peer-to-Peer network).

A UAC can receive not a only single PG from a single UAS but also
multiple PGs from multiple UASs.

\begin{verbatim}

         +-------------+                +---------------+
         | PG Server   |                | PG Client     |
         |         UAS |--------------->| UAC           |
         +-------------+                +---------------+

      Figure 1. An example of peer-to-peer PG network


                                              +---------------+
                                           +---------------+  |
         +-------------+                +---------------+  |  |
         | PG Server   |                | PG Clients    |  |--+
         |         UAS |--------------->| UACs          |--+
         +-------------+                +---------------+

      Figure 2. An example of distribution network


      +------------+   +-----------+   +-----------+   +------------+
      |  PG Server |   | PG Host A |   | PG Host B |   |  PG Client |
      |            |-->|           |-->|           |-->|            |
      |            |   |           |   |           |   |            |
      +------------+   +-----------+   +-----------+   +------------+

             PG UAS --> PG UAC
                             PG UAS --> PG UAC
                                             PG UAS --> PG UAC

      Figure 3. An example of relayed network

\end{verbatim}

\section{Program Guide Protocol Model}

\subsection{Unicast Model}

A client needs to be able to access the PG when convenient. For
example, when sufficient network bandwidth or storage capacity is
available to the user, the user can retrieve the PG.

When the user doesn't want to keep track of the up-to-date PG but
wants to take it just several times when necessary, the unicast model
is appropriate.

If a cost-effective implementation is required or the resource for the
implementation is limited in a UAC, the UAC can use existing
request-response type protocols for a PG retrieval.

If the PG contains a large amount of data, a user may request the
subset of the original PG by a customized request mechanism over the
unicast model.

\subsection{Multicast Model}

A user may want to receive PGs without requesting every time. As an
example, if the PG source is fixed and the PG changes periodically, a
UAC prefers to obtain the PG by multicast session \cite{rfc2974} in
order to reduce the overhead of a request functionality.

It is clear that the multicast model provides scalable distributing
mechanism of PG. Since this model can reduce the number of retrieval
requests to the UAS, the UAS can benefit from this model.

The multicast model may be introduced into existing broadcast or
multicast networks such as satellite systems. Using existing broadcast
infrastructures, the introduction cost can be decreased.

\subsection{Un-managed Status vs. Managed Status}

In most cases, it is required that PG can be transferred continuously
to a UAC, because the PG will be changed by the time
elapsed. Regarding the status management between a UAS and UAC, there
are two options to deal with the PG status; un-managed and managed.

The un-managed model doesn't care the status in the other side of the
protocol.  In the model, the UAS and UAC may manage its own status,
but they don't maintain the status of the other side. For instance,
the UAC does not update the existing PG but keeps it until the UAC
receives new PG from the UAS because it doesn't care the UAS
status. Also, the UAS doesn't recognize the UAC status even if the UAC
didn't receive and update the PG.

This model makes managing functions in the UAC and UAS
simple. However, the model does not provide the up-to-date PG whenever
the UAC requires it.

In the managed model, a UA can watch or confirm the status on the
other side, and can also request to update or synchronize the status
when necessary. The model provides a reliable and accurate update
mechanism, which can be used to synchronize PG information between the
UAC and UAS.


\section{Program Guide Data Model}

A program guide consists of multiple programs
\cite{Foru0206:Metadata}, and a program may consist of sub--programs
named "segment". Thus, a program guide has a hierarchical structure.

PG is required to describe multimedia content such as a picture, music
and movie.  To describe such various content, the PG
data model uses comprehensive description tools, which is also
extensible for future new content. However, if content does not
contain much meta-data, PG may be described by simple tools, which is
a subset of the full set of description tools.

PG is used to find, obtain, manage and play content, and may be
modified by an user if necessary. For example, since location and
available time may vary from the distribution network environment, a
UA may modify such dynamic meta-data to fit the
network.

A program guide may contain a hyperlink to refer other PGs. The
hyperlink provides flexibility and scalability to describe PGs, and it
keeps managing the original PGs separated from other PGs.

A PG is provided by a single source or multiple sources. Some sources
want to manage distributing content and the PG from a root server. In
this case, some UAC can only access PGs from the root or its child
servers. Otherwise, the UAC can access the same PGs from different
UASs.

PG is independent of particular devices, network platforms and protocols. 

\bibliographystyle{ieeetr}
\bibliography{net02,string,iso,rfc,i-d}

\section{Author's Addresses}

\begin{flushleft}
Yuji Nomura\\
Fujitsu Laboratories Ltd.\\
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588\\
Japan\\
Email:  nom@flab.fujitsu.co.jp 
\end{flushleft}

\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue\\
New York, NY 10027\\ 
USA\\ 
Email:  schulzrinne@cs.columbia.edu 
\end{flushleft}
\input{copyright}
\end{document}
