CA2071416A1 - Video store and forward apparatus and method - Google Patents

Abstract

VIDEO STORE AND FORWARD APPARATUS AND METHOD

Abstract of the Disclosure A store and forward module is provided for use in a video-on-demand system. The video-on-demand system includes an information database. Connection to the database is via a broadband network. The store and forward module includes a data interface for receiving information from a database at a high-speed transmission rate, typically 150Mb/s. The data interface is connected to a data FIFO buffer for storing the received information. The information is transferred to a RAM buffer partitioned into parts A and B. Information is stored in one of A or B
parts whilst being read from the other. Client buffers connected to the RAM buffer store information from the RAM
buffer for transmission to clients at a second transmission rate which is much lower than the first transmission rate, typically 1.5Mb/s. A processor connected to the data buffer, RAM buffer, and client buffer controls the buffers in reponse to commands from a VOD service driver.

- i -

Description

~ 2071~

VIDEO STORE AND FORWARD APPARATUS AND METHOD
This invention relates to providing video service on demand and is partlcularly concerned with an apparatus and method for storing video received at one rate of transmission and forwarding video at a second rate lower than the first for delivery to subscribers.
~ackaround of the Invention To conserve bandwidth in the transmission of video signals, standards have been devised for compression of video signal using digital coding schemes. A standard for use in video conferencing, H.261 (and companion standards H.221, H.242, H.230, and H.320) in CCITT, is also known as Video Codec for Audio-Visual Services at Npx64 kb/s~. A
standard for coding moving pictures at around 1.5 Mb/s is currently under ratification known as MPEG in ISO~IEC (work item 1 for JTCI/SC29/WG11). The proposed standard provides a compression factor ranging from 30 to about 100 to 1.
The development of broadband networks together with above standards makes the offering of video-on-demand (VOD) services practicable.
Summary of the Invention An object of the present invention is to provide an improved video store and forward apparatus and method.
In accordance with one aspect of the present invention there i5 provided a store and forward module for a video-on-demand system, including a service driver, said module comprising data interface means for receiving information from a database at a first transmission rate, data buffer means connected to the data information means for storing the received information, RAM buffer means connected to the data buffer means for storing the buffered received information, said RAM buffer means including first and second parts, client buffer means connected to the RAM
buffer means for storing information from the RAM buffer means for transmission to a client at a second transmission rate which is much lower than the first transmission rate, and processor means connected to the data buffer means, RAM

~ ~ 2 0 7 ~

buffer means and client buffer means for controlling said buffer means and responsive to commands from the service driver.
In accordance with another aspect of the present invention there is provided a store and forward module, including a data buffer as a RAM buffer, and a client buffer, for a video-on-demand system including a service driver, a method comprising the steps of initializing the system by placing all clients in an idle state, determining lo if a response is required by the service driver and, if true, responding, otherwise determining if a command is available from the service driver and, if true, executing the command, otherwise determining if the data buffer requires emptying and, if true, transferring an amount of data from the data buffer to the RAM buffer, and determining if the client buffer requires more data and, if true, transferring an amount of data from the RAM memory to the client buffer, otherwise, repeating the step of determining if a response is required by the service driver.
An advantage of the present invention is allowing multiple clients access to a single database by transferring information from the database at a much greater rate than the rate at which information is provided to the clients.
~rief DescriDtion of the Drawinas The present invention will be further understood from the following description with reference to the drawings in which:
Fig. 1 illustrates in a functional block diagram a video-on-demand arrangement utilizing the present invention;
Fig. 2 illustrates in a functional block diagram a store and forward module in accordance with an embodiment of the present invention;
Fig. 3 illustrates a state diagram for the store and forward module of Fig. 1, representing the process of ~7~

initialization for a particular Client K, loading data, and following a PLAY-PAUSE-PLAY sequence of commands;
Figs. 4a and 4b illustrate the steps taken in implementing the process of Fig. 3 for a single client;
Figs. 5a and 5b illustrate the steps taken in implementing the process of Fig. 3 for multiple clientsi Fig. 6 illustrates in a flow chart the operation of the store and forward module of Fig. 2;
Fig. 7 illustrates in state and transition diagram the step of transmitting responses of Fig. 6;
Fig. 8 illustrates in state and transition diagram the step of receiving command from VOD driver of Fig. 6;
Fig. 9 illustrates in state and transition diagram the step of receiving on HS databus of Fig. 6; and Fig. 10 illustrates in state and transition diagram the step of putting data into Client FIFO of Fig.
6.
Similar references are used in different figures to denote similar components.
Detailed DescriDtion Referring to Fig. 1, there is illustrated, in a block diagram, a video-on-demand (VOD) arrangement utilizing the present invention. The arrangement includes subscribers' equipment 10a and 10b coupled to a database 12 via a communications network 14. The subscribers~
equipments 10 are connected via a local access loop 16 to a central office (CO) 18. The CO 18 is connected, via a broadband network 20, to a second central office (~o) 22.
The broadband network 20 may be any network having a bandwidth much greater than DS1, for example, ATM, B-ISDN, DS3. Within the CO 18 resides a store and forward module 24 and a VOD service driver software module (VOD driver) 26. The subscribers~ equipments 10a and 10b include decoders 27a and 27b, TV receivers 28a and 28b, and command5 interfaces 29a and 29b, respectively.
n operation, a subscriber, for example subscriber ~a', requests VOD service via the command module 29a. The

2~7~

request is conveyed to the VOD driver 26 via the local access loop 16. On receipt of the request, the store and forward module 24 signals the database 12, via the broadband network 20 and CO 22, to download the requested video information. The video information, which is stored within the database 12 in compressed form, is sent across the broadband network 20 at a rate exceeding its compressed rate by several orders of magnitude. This allows the database to service a multitude of such requests virtually simultaneously. The store and forward module 24 stores the audio and video information at the incoming rate and forwards it to the subscribers~ equipment 10a at its normal compressed rate, for example 1.5 Mb/s for MPEG compressed video information. The received signal is decoded by the decoder 27a for viewing on the TV receiver 28a. The command interface 29a allows subscriber ~a~ to control the viewing of the requested video in a manner analogous with the functions of a video tape or disk player, such as stop, play, rewind, fast forward, reverse search, and forward search. These commands are returned to the VOD driver 26 through a command channel.
Referring to Fig. 2, there is illustrated, in a functional bloc~ diagram, the store and forward module of -: Fig. 1 in accordance with an embodiment of the present invention. The store and forward module 24 includes a high speed input channel 30 connected to a data interface 32 and a control interface 34. A processor 36 is connected to the control interface 34 via a control line 35 for exchanging control signals that initiate and control the downloading of video information from the database 12 of Fig. 1.
The control interface 34 includes a command FIFO
33 that the VOD driver 26 fills, as well as a response/status buffer 37 that the VOD driver 26 can poll.
The store and forward module also includes a high-speed databus FIFO 38 connected via a high-speed databus 39 to the data interface 32, a RAM buffer 40 and a plurality of client FIFOs 42a through 42n, connected to channel 2~7~

interfaces 44a through 44n, respectively. While connection is shown between the VOD driver 26 and the processor 36, interchange of command and status can be via the broadband network 20. Output from the high-speed databus input FIFO
38 is buffered in single buffer 46 prior to being connected, via a bus 47, to the RAM 40. The RAM buffer 40 can be connected to any one of the client FIFOS 42a through 42n via a plurality of buffers 48a through 48n, respectively, whilst being isolated from the data FIFO 38.
The processor 36 controls the high-speed databus and client FIFOS 38 and 42a-42n, the buffers 46 and 48a-48n and the RAM 40 in response to commands from the VOD driver 26 which are placed in the command FIFO 33. The RAM 40 is partitioned into two halves A and B, each of which is further subdivided into n segments 50a-50n to support subscribers 1 through n inclusive.
Connections between the processor and the various other elements generally reflect control signalling. In effect, processor 36 never manipulates data coming from the HS channel 30 directly. This is because of the high speed required between the HS databus 37 and the RAM 40 as well as the high speed required between the RAM 40 and the client FIFOs 42. Rather than doing any data manipulations, the processor establishes appropriate paths between 2s components. That is, the following are established:
In receiving data from the HS FIFO 38, processor 36 provides addressing to the RAM 40, provides read signalling to the HS
FIFO 38, enable signalling to the buffer 46 as well as write signalling to the RAM
40. All other elements are left in a quiescent state.
In putting data into the client FIFO 42 (video and audio), processor 36 provides addressing to the RAM 40 as well as read signalling, enable signalling one of buffers 48a to 48n, as well as write 2 ~

- slgnalling to the appropriate client EIFO
42. All other elements are left in a quiescent state.
In operation, the processor 36 implements the central control functions and coordinates all the store and forward module maln subsystems, i.e., transfers out of the high-speed databus FIFO (HS FIFO 38), transfers into the RAM buffer and transfers into the client FIFOs 42a through 42n. All operations are mainly controlled through commands received from the VOD service driver 26. The commands describe state transitions through which the VOD driver 26 is going and, which the processor 36 must also mimic. An example of such state transitions is given in Fig. 3 that shows the process of initialization, loading and going through PLAY-PAUSE-PLAY actions.
The VOD service driver software 26 states and transitions are illustrated for a particular subscriber "Client KN. A QUIT command 60 results in a Client K IDLE
state 62. A movie selection 64 by the particular subscriber requires an initialize buffer for Client K state 66. A PLAY command 68 from the Client K results in a PLAYING state 70. During the playing state 70, the VOD
driver collects status information on RAM buffer 40 fullness for Client K and replenishes data when empty (either part A or part B as appropriate). A PAUSE command 72 from the Client K causes a PAUSED state. A RESUME
command from the Client K returns the system to the PLAYING
state 70.
Figs. 4 and 5 illustrate two examples of typical steps through which the system would go in handling PLAY-RESUME-PLAY for one client and then two clients. In these figures the time scale is not linear and reflects transitions from one event to another to compress the scale to show only the important events.
Referring to Fig. 4, following a RESET Client K, marker A, every component of Client K is put in an IDLE
state, marker Al. A command is received, marker B, that -- 2 0 7 ~

tells the processor 36 that data will be coming over the HS
databus 39 and must be placed in RAM buffer 40, to fill buffer A/Client 1 50a/A. Parameters are included to supply information regarding quantity of bytes transmitted and segmentation of the data according to units used by the VOD
service (INTRA frame sizes, PREDICTED frame sizes and associated AUDIO sizes). The command is acknowledged, marker C, and the system then monitors the HS FIFO 38 levels to ensure that data is taken out before it overflows. A method for doing this simply is through the monitoring of the half-full level. When this level exceeds half-full, an amount of data equivalent to one-half of that FIFO~s size is taken out at a rate that exceeds the incoming rate sufficiently to do other tasks. The process continues until all the specified data has been received, marker D. After this, a response is sent back to the VOD
driver 26, marker E. The process is then repeated for Buffer B/Client 1 50a/B and its completion is indicated by marker F.
The processor will then receive, at some point, a command to play Buffer A/Client 1, marker G. After acknowledgment, a small quantity of data is placed in the FIFO of Client 1, marker H. The fullness level of the client FIFO 42a is monitored in a manner similar to that used for the HS FIFO 38, except for ensuring that there is no underflow (FIFO level goes empty). When the level goes below half-full, an amount of data equivalent to one-half of that FIFO's size is written into the FIFO. Every time a quantity of data is placed into the client FIFO 42a, status information is returned to the VOD driver 26 through the status buffer 37. When the last of data is taken out of Buffer A 50a/A and placed into the client FIFO 42a, marker I, that information is returned to and detected by the VOD
driver 26, as indicated by marker I1. The VOD driver 26 ~5 then in turn issues a command to fill Buffer A/Client 1 50a/A while Buffer B/Client 1 50a/B is being played out.
The process between markers J and K follows a pattern -~ 2~7~

similar to the one that happened between markers C and D, -: except that it is interspersed with transfers of amounts of data into the client FIFO 42a, as indicated by markers Jl and J2. Multi-client operation proceeds in a manner similar to that illustrated in Fig. 4 with an example shown in Fig. 5.
In Fig. 5, the transition diagram begins at marker F as everything before that point is as illustrated in Fig.
4. That is, Client 1 buffer A and B have been filled and lo the PLAY command was issued. An amount of data is placed in Client 1 FIFO 42a, as indicated by marker H. A little later, marker I, a command is received to fill Buffer A/Client 2 50b/A. The process used for Client 1 is now repeated for Client 2 as represented by markers I to L, thus filling both Client 2, Buffers A and B 50b. Following this, a command is received, marker M, to play Buffer A/Client 50b/A, that results in an amount of data being placed into client 2 FIFO 42b. Then there follows a series of transfers to each client FIFO 42a and 42b as they each empty at the regular rate of transmission, markers N
through Q. At some point, each client will change from one buffer to another, and then the process of replenishing the data will follow a process similar to the one described in Fig. 4 between markers J and K.
The parameters that allow this system to work are based on the following premises:
~a) The following relation exists between the data rates of the HS databus incoming, the client FIFO
outgoing and the RAM buffer:
f RAN buffer 40 >f HS databus 37 >>f client FIFO 42 Typical values for these rates are the following:
f~AM buffer = 32 MBytes/s fHS databus = 20 MBytes/s fClient FIFO = 192 kBytes/s*
*(equiv. to a DS-l data rate expressed in kB/s) ., . ,. ,, ,.. , -':

~ 2~7~

(b) Timing relationships between service calls to each component:
~HS d~tabus>~Client FIFO>>~Send response or ~Receive C~qD

Typical values for service call.s to each component are the following:
S databu~i = 50 msec.
~Client ~IFO = 7 msec.
'ISend resp~n~e = a few microseconds ~Recelve CMD = order of ten microseconds Referring to Fig. 6, there is illustrated in a flow chart, the operation of the store and forward module of Fig. 2.
Once initialized, state 80, the system continuously runs in a loop, as illustrated in Fig. 6.
This loop visits all main components of the system to verify servicing needs - sending responses to the VOD
driver 26, state 82, receiving and validating commands from the VOD driver, state 84, servicing the HS FIFO 38, state 86 and servicing the client FIFO 42a-n, state 88. Once initialized, state 80, an initial response is sent to signal the VOD driver 26 that the system is alive, all clients are placed in an IDLE state, and a command is requested. After this, the system loops around continuously until a command is received. The initial command to be received must be a "RESET Client Kn that resets the specified client in an IDLE state. This is done for every client.
At state 82, the system checks to see if a response is required, and if true, then proceeds with response, otherwise goes into next state 84.
At state 84, the system determines if a command is available from the VOD driver command FIFO 49, if true, then proceeds to validate the command and proceeds accordingly, otherwise goes into next state 86.

. , - 2 ~ 7 ~

At state 86, the system determines if the HS
databus FIFO 38 needs servicing, and if true, then proceeds to move an amount of data from the HS databus FIFO 38 to the RAM buffer 40, otherwise goes into next state 88.
At state 88, the system determines if client FIFOs need servicing, and if true, moves an amount of data from the appropriate portion 50a-n A or B of the RAM buffer 40 to the client(s) FIFO 42a-n, otherwise goes to back to state 82.
Details for each state of Fig. 6 are provided in Figs. 7-10.
Figs. 7-10 provide state and transition diagrams that describe how each component reacts to various commands and stimuli.
Fig. 7 shows the various responses and how each one is generated. There are five:
ACK-RDY: indicating that the system has been initialized or that the command received was valid.
NACK: indicating that the command received was not valid.
RDY-HS: indicating that the appropriate buffer is ready to receive data over the HS
databus 37.
RCVD-HS: indicating that data received over the HS databus 37 was complete.
STATUS: information provided to the VOD driver 26.
As for every flow diagram (except Fig. 6), the processor 36 enters this flow from the top if a client needs servicing. In this case, a response must be transmitted, then the processor moves from state to state in the flow diagram. Then, the processor terminates on the last state ~XMIT IDLE" which is the same as the entry state. In this case, if this component becomes IDLE, it then goes to the next step as shown in Fig. 6.

207~

The control behaviour of the processor 36 is done in a time-sliced fashion which allocates an amount of time for, possibly, servicing the HS FIFO 38 if a bit stream is transiting over that channel, an amount of time for, possibly, servicing the client FIFO and, an amount of time for, possibly, servicing the commands from the VOD driver 26. The use of the word upossibly~ reflects the fact that not all actions may be present simultaneously, yet all combinations are possible, and hence, in the worst case, the system must be able to react to all. The present embodiment uses a control structure based on time-slicing and polling mechanisms, however, an interrupt driven mechanism may be used as an alternative.
Fig. 8 illustrates states and transitions of the process that validates the commands received from the VOD
Driver 26. Again, if there is no command, then the processor goes to the next step shown in Fig. 6. If a command is available, the client to whom it belongs is determined, e.g. client K. The command is validated and, if correct, an appropriate action is taken. This process terminates on UReceive CMD IDLEn.
Fig. 9 illustrates the states and transitions of the process for reception over the HS databus. If a command were received that directed the processor 36 to fill RAM suffer A (or B) for a certain Client K, 50k, then the processor would move from state UReceive IDLEU to "Verify HS databus statusU. There, the HS FIFO 38 level is monitored relative to its half-full level and actions are taken accordingly. The process terminates on UReceive IDLEU.
Fig. 10 illustrates the states and transitions of the process of putting data into Client K FIFO 42k. The processor moves from the IDLE state to USelect a Client in PLAY modeU if at least one client needs servicing. At this turn, only one client will be serviced. The remaining clients that need servicing will be taken one after the other during the following runs around the major loop of 2~7~

Fig. 6. secause of the half-full monitoring mechanism, the only constraint in this manner of operation is that the total time to service all clients does not exceed the time to empty out half of any one of the client FIFOs, i.e.

IF: ~Send response = S
~Receive and procel3s C~D = R
'~Receive one-half HS DataBus FIFO = D
~PIL~ one-half Client FI~O = C
~Any other activity of main loop = Z

Number of clients = N
THEN:
~E2~PTY ON~ HALP Cl,IE:NT ~IFO >N * (S + R + D + C + Z) AS shown in the Fig. 10, if a client FIFO 42 needs servicing, then after identifying the client, the process puts new data into the FIFO and updates parameters that have to do with the current position in the buffer and whether this is effected by any flag that may have been set (i.e. PAUSE or STOP, or one-shot sequence). The process then returns to IDLE, thereby sending the processor onto the next step in the main loop, which corresponds to Fig. 7.
In the present embodiment, typical FIFO sizes are ~ 2s shown in Table 1 and the command formats are shown in Table 2.
FIFO and RAM sizes ~Ye~ Size CMD FIFO 256/client HS databus FIFO 4096 Client FIFO~s 1024/client RAM 2 MBytes/client Table 1 2~7~

CMD Eormats CMD TyDe Action 5 RESET Client K Resets only Client K
elements. Requested by system.

QUIT Client K Resets all parameters for Client K. Requested by client.

FILL Buffer A(or B)/Client K Requests the processor to be ready to receive data over 15 This is accompanied by a the databus channel and to parameter list giving store that data into the the number of half-second appropriate Buffer for segments transferred, the Client K using the quantity of data in each parameters for normal 20 segment separated into PLAY mode.
INTRAframe data,INTERframe data and AUDIO data.

GO Buffer A (or B)/Client K Requests the processor to start transferring data to Client K's FIFO from Buffer A (or B); when buffer A (or B) is empty, the processor will automatically change over to the other Buffer.
This is done until further notice.

PAUSE Client K Requests the processor to halt transmission at the beginning of the next INTRA.
'~

2~7~

CMD Type Action STOP Client K Requests the processor to halt transmlssion at the beginning of the next INTRA
and then play a previously stored compressed sequence representing a black picture; this Dblack sequenceN is played only once ~one-shot sequence).

FILL FAST SEARCH BUFFER A Available only during PLAY
15 (or B)/Client K (after receiving a GO.. ), this requests the processor This is accompanied by a to be ready to receive data parameter list giving the over the databus channel and number of INTRAs that are store that data into the 20 sent. appropriate Buffer for Client K using the buffer parameters for FAST SEARCH
mode.

25 GO FAST Buffer A Requests the processor to (or B)/Client K start transferring data to Client K's FIFO from Buffer A(or B); when Buffer A~or B) is empty, the processor will automatically change over to the other Buffer. This is done until further notice using buffer parameters for FAST SEARCH mode.
Table 2 - 2 ~

Numerous modifications, variations and adaptations may be made to the particular embodiments of the invention described above without departing from the scope of the 5 invention, which is defined in the clalms.

: 25

Claims (10)

WHAT IS CLAIMED IS:

1. A store and forward module for a video-on-demand system, including a service driver, said module comprising:
a) data interface means for receiving information from a database at a first transmission rate;
b) data buffer means connected to the data information means for storing the received information;
c) RAM buffer means connected to the data buffer means for storing the buffered received information, said RAM buffer means including first and second parts;
d) client buffer means connected to the RAM
buffer means for storing information from the RAM buffer means for transmission to a client at a second transmission rate which is much lower than the first transmission rate;
and e) processor means connected to the data buffer means, RAM buffer means and client buffer means for controlling said buffer means and responsive to commands from the service driver.

2. Apparatus as claimed in claim 1 further comprising:
command buffer means for storing commands from the service driver for action by the processor; and response/status buffer means for storing information from the processor for the service driver.

3. Apparatus as claimed in claim 1 further comprising a channel interface connected to the client buffer means for transmitting the information from the client buffer means to the client at the second transmission rate.

4. Apparatus as claimed in claim 1 wherein the RAM buffer means includes a plurality of segments, one segment for each of a plurality of clients, and the client buffer means includes a plurality of buffers, one buffer for each of the plurality of clients.

5. Apparatus as claimed in claim 1 wherein the data buffer means includes a FIFO buffer.

6. Apparatus as claimed in claim 1 wherein the client buffer means includes a FIFO buffer.

7. In a store and forward module, including a data buffer as a RAM buffer, and a client buffer, for a video-on-demand system including a service driver, a method comprising the steps of:
a) initializing the system by placing all clients in an idle state;
b) determining if a response is required by the service driver and, if true, responding, otherwise;
c) determining if a command is available from the service driver and, if true, executing the command, otherwise;
d) determining if the data buffer requires emptying and, if true, transferring an amount of data from the data buffer to the RAM buffer; and e) determining if the client buffer requires more data and, if true, transferring an amount of data from the RAM memory to the client buffer, otherwise, repeating step b).

8. The method as claimed in claim 7 wherein the step of responding includes the step of selecting a client response in dependence upon validity of the command and status of the system.

9. The method as claimed in claim 8 wherein the step of selecting a client response selects one of ACK-RDY, NACK, RDY-HS, RCVD-HS, and STATUS.

10. The method as claimed in claim 7 wherein the step of executing the command includes the steps of selecting a client, validating the command for the client and proceeding with the command.