(e.g., busy/free), and characteristics (e.g., data rates,
`duration).
`The metadata concept is ideal for interactive mul-
`timedia applications in which many objects can be in-
`volved in a single presentation. For example, a movie
`might involve the coordination of audio and video
`streams, a classroom video might involve the simulta-
`neous presentation of audio, video, graphics and text.
`The metadata server maintains the relationships be-
`tween these diverse objects and informs the client of
`their presence whenever a query is made. In the con-
`text of a VOD server, the system must store different
`movie attributes. For movies, application—specific at-
`tributes include entities such as actor, producer, title,
`shot, and scene
`
`2.2 Distributed Resource Server
`
`Resource attributes include the parametric loads on
`individual storage subsystems and subnetworks; and
`the number of users currently accessing the VOD sys-
`tem. Maintaining a record of the parametric loading
`and system usage time is the responsibility of the re-
`source server via a state table. Since resource allo-
`
`cation decisions are based on this information, it is
`important that it be kept up to date.
`In information delivery systems, where the primary
`function ofthe database is data retrieval, the resource
`and metadata servers must keep track of available
`movies and resources to provide their delivery. When
`resources are overloaded or not available, the meta-
`data server must find alternative sources of informa-
`
`if available, or inform the user of their non-
`tion,
`availability. These functions should operate transpar-
`ently to the user.
`In order to manage its resources, the resource server
`must collect periodic input from the managed systems.
`These can include event reports as well as periodic an-
`swers to queries from the various data servers. The
`resource server also needs to keep track of changes to
`the system configuration which can include resource
`relocation, failure, and the announcement of new re-
`sources.
`
`It is envisioned that many interactive multimedia
`services will require their users to pay for offered ser-
`vices. User data is maintained in a separate database
`and is updated whenever a user accesses the system.
`This can be used in the generation of accurate and
`automatic billing mechanisms.
`The main attraction of using metadata and resource
`servers are their flexibility. When resource updates
`occur (resource removal, relocation, and new resource
`generation), only the entries in the database need to
`
`be updated for the change to be visible to the entire
`user community. Finally, the metadata server itself
`can be replicated, providing for an additional level of
`performance.
`
`2.3 Service Scaling via the Resource
`Server
`
`Using the metadata and resource server models pro-
`vides us with a simple scheme that is quite powerful.
`As it uses database entries to maintain the relation-
`
`ships between objects, the metadata can be easily ex-
`tended to support different media formats by object
`redirection. This is particularly appealing when sup-
`porting heterogeneous terminal devices with different
`display and presentation devices.
`
`session
`qualiy
`
`region ol consiam _,,4j region or sealed or _.
`nominal service
`:
`degraded service
`I
`
`
`
`number of sessions
`
`Figure 2: Quality vs. Number of Sessions in a VOD
`system
`
`The resource server can also be used to provide
`graceful degradation of service when the system over-
`loads. For example, multimedia storage servers have
`a limited capacity for supporting concurrent sessions.
`When this capacity is exceeded,
`the session quality
`can degrade abruptly (i.e., response time for interac-
`tion and bandwidth for data transmission). However,
`knowing these limits enables the resource server to ei-
`ther ensure graceful degradation or to find alternate
`sources of replicated data and I/O bandwidth. This
`concept of graceful degradation is illustrated in Fig.
`2.
`
`3 Resource Management for a Client-
`Server VOD Architecture
`
`We now describe our proposed scheme for manag-
`ing metadata and resources for a VOD system. We
`base our discussion around an application supporting
`interaction and retrieval on a database of motion pic-
`tures. A model for a distributed VOD architecture is
`
`illustrated in Fig. 3.
`
`13
`
`SONY |~'.XH H '1 101/— Page 5
`SONY EXHIBIT 1017- Page 5
`
`

`
`
`
`Figure 3: VOD Architectural Model
`
`to video databases (VDBs) via a
`Clients connect
`network. The databases can be distributed. A meta-
`
`data server (possibly distributedz) called the Query
`Database (QDB) provides interactive database access
`functionality for the application-specific data. A re-
`source server maintains the availability of different re-
`sources in the system. When a user at a client wishes
`
`to View a movie, a query is made first to the QDB for
`interpretation of the user browsing operations. The
`resource server maintains tables about the availabil-
`
`ity of movies for playout. The delivery of the movie
`data to the user begins after the user has browsed the
`selections, issued a command to “play” a movie, and
`has been given permission to do so from the resource
`server.
`In the remaining subsections we examine the
`connection establishment and maintenance functions
`necessary to support these processes.
`
`3.1 Connection Establishment
`
`The connection establishment phase begins when
`the user decides on the movie to view. During this
`phase, the user’s machine (client) has knowledge ob-
`tained from the QDB describing the the location of the
`VDB containing the desired movie. This information
`is transparent to the user.
`VVhen a specific movie is requested for playout, a
`client process sends a request to the resource server
`for the establishment of a connection. The connection
`supports real—time video delivery and playout.3 The
`session between the client and the server lasts the en-
`
`tire playout duration of the movie. The client’s request
`is a simple signal indicating the “name” of the movie
`to be displayed. The server checks its local state—table
`to make sure that it will not be overloading the system,
`and can support movie playout for the entire duration
`of the feature presentation. To do this, the server must
`
`2In our prototype implementation, we use a centralized
`metadata server. However, the video databases are distributed.
`3We do not assume a large storage capacity at the client
`station. Alternate architectures, in which the movie is trans-
`ferred to the users site completely before playout begins, are
`not considered here.
`
`14
`
`maintain the number of users connected at any given
`time. Alternatively, this information can be part of
`the QDB, in which case, the QDB makes sure that the
`database being accessed has enough residual capacity
`to support the new connection. If the connection can-
`not be supported, the server sends back a “connection
`refused” message.
`If the connection can be supported, the server then
`proceeds to examine the characteristics of the required
`movie from the VDB. Depending on these characteris-
`tics, the server then starts a Quality of Service (QOS)
`negotiation procedure.
`If the negotiation completes
`successfully, and mutually acceptable QOS parameters
`are agreed upon, then the connection setup phase be-
`gins. Otherwise the connection is terminated and the
`resources are freed up. During the QOS negotiation
`phase, resources are reserved for the new connection
`and will be released only if the connection setup fails.
`This ensures that there are no deadlocks at the server.
`
`the
`Once the QOS parameters are established,
`client sends a. “connection established” message. On
`the receipt of this message the server increments its
`state description to account for the new user. It also
`initiates a new process to handle the transfer of video
`data.
`
`The functions that are required at the client and
`server machines for connection setup are summarized
`in Tables 1 and 2.
`
`3.2 Connection Management
`
`The connection maintenance mechanism manages
`the connection during the entire playout duration of
`a movie.
`It ensures adherence to the QOS parame-
`ters negotiated during connection establishment. The
`connection management mechanism is also responsible
`for continuous media flow control and user temporal
`access control (TAC) operations such as play, stop,
`pause, forward, and rewind.
`
`During the connection setup phase, a dedicated
`connection is set up between the network station and
`the VDB.‘ Flow control can be facilitated by an out-
`of-band feedback circuit.5 Connection management
`processes are set up simultaneously at the time of con-
`nection establishment. They are aware of the QOS pa-
`rameters negotiated at the time of connection setup
`and enforce this behavior from the system. User
`TAC inputs which include typical VCR-like controls
`are translated and sent as control signals to both the
`server and the playout mechanism. Controls such as
`
`‘UDP for our implementation.
`STCP for our implementation.
`
`SONY |~'.XH H '1 101/— Page 6
`SONY EXHIBIT 1017- Page 6