Apparatus And Method For Simulcast Over A Variable Bandwidth Channel

Abstract

The present principles provide a method for a personalized mobile broadcast service operator (Service provider) to send content in the form of files with different compression formats in a variable bandwidth channel to one or more users who have access to the same service. Operators providing mobile broadcasts have the option of using residual bandwidth to provide these services. In such services, depending on the amount of bandwidth available for a mobile broadcast, a scheduler can choose to broadcast file content with higher compressed parameters thereby reducing the network footprint of the content file during lower bandwidth situations. A lower compressed format of the same content could then be potentially scheduled to broadcast at a later time when more bandwidth becomes available eventually replacing the highly compressed copy which was received earlier on the client.

Description

BACKGROUND

[0001] 1. Technical Field

[0002] The following principles of the present invention relate to data transmission. More particularly, they relate to the transmission of simulcast data over a variable bandwidth channel.

[0003] 2. Description of Related Art

[0004] Content services are provided by a spectrum of different suppliers. For example, residential digital video services may include digital television, Video on Demand (VOD), Internet video streaming, etc., each service typically providing audio-video data displayable at different encoded levels.

[0005] Content data is transmitted in a bitstream, or a continuous sequence of binary bits used to digitally represent compressed multimedia, e.g., video, audio, data. The bitstream is transmitted over a transmission channel. When content data is sent as a continuous bitstream, a client device buffers this stream and offers a real time playback of the same.

[0006] Mobile broadcast networks are challenging environments in which to deliver audio/video content. The bandwidth available over a connection at any particular instant varies with both time and location. This variation in bandwidth causes entire packets containing substantial audio/video content to be lost. In addition, the latency through the network, causing the video that is ultimately displayed to `jitter` or lose clarity at the client. These factors may be tolerable for file transfer traffic where jitter does not matter since high level protocols correct for errors and losses.

[0007] In streaming real time live content live broadcast networks, methods already exist where transmission of audio-video content varies as a function of available network bandwidth. Depending on the bandwidth available, the head end or transmitter side of the service is able to either buffer data to send them at a different time or at real time, using an encoder to vary the content stream's compression parameters so that it can be transmitted at current available bandwidth.

[0008] Operators providing live televised services, stream in real-time, a lower quality version of a televised broadcast feed to its mobile customers. For example mobile operators like Verizon and Sprint provide live TV services, e.g., VCast Live TV, MobiTV, etc., at a reduced resolution and bitrates to mobile handsets using their services.

SUMMARY

[0009] According to an aspect of the present principles, the method for providing data over a network of devices includes establishing a bandwidth value for providing a data over a communication channel, providing the bandwidth value to a client device over the communication channel, and providing a predetermined version of the data over the communication channel to the client device in response to a comparison of the established bandwidth value with a bandwidth threshold. Providing data may include transmitting data via a wireless connection or providing data via a wired connection.

[0010] According to another aspect, the bandwidth can be established by estimating the available bandwidth, or could be established by setting an initial value of the bandwidth.

[0011] A bandwidth threshold is set based on the established threshold, and according to one implementation, the bandwidth threshold can be set as one half the established bandwidth value.

[0012] In accordance with another aspect, a low compression version of the data is transmitted when the bandwidth is higher than the bandwidth threshold, and a high compression version of the data is transmitted when the bandwidth is lower than the bandwidth threshold.

[0013] According to another implementation, the apparatus includes a head end scheduler configured to establish a bandwidth value for transmitting data over a communication channel, transmit the established bandwidth value to a client device, and transmit a predetermined version of the data in response to a comparison between the established bandwidth value and a bandwidth threshold.

[0014] According to a further implementation, the present principles are embodied in a computer program product having a computer useable medium having computer readable program code embodied thereon for use in communicating data over a communication channel. The computer program product includes program code for establishing a bandwidth value for transmitting the data over the communication channel, program code for transmitting the established bandwidth value to a client device over the communication channel, and program code for transmitting a predetermined version of the data over the communication channel to the client device in response to a comparison between the established bandwidth value and a bandwidth threshold.

[0015] Other aspects and features of the present principles will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the present principles, for which reference should be made to the appended claims. It should be further understood that the drawings are not necessarily drawn to scale and that, unless otherwise indicated, they are merely intended to conceptually illustrate the structures and procedures described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In the drawings wherein like reference numerals denote similar components throughout the views:

[0017] FIG. 1 is block diagram of a typical broadcast network adapted for mobile broadcast;

[0018] FIG. 2 is a block diagram of an exemplary personalized content broadcast system;

[0019] FIG. 3a is a block diagram of the method according to an implementation of the present principles;

[0020] FIG. 3b is a flow diagram of the method according to an implementation of the present principles; and

[0021] FIG. 4 is a flow diagram of the method according to another implementation of the present principles.

DETAILED DESCRIPTION

[0022] FIG. 1 shows a typical broadcast network system 100 adapted for mobile broadcast. The original content signal 102 is sent through a content transcoder 108 which compresses the audio-video content fit for transmission (110) over a mobile network 111 to a mobile client 112. In an on-demand device (e.g., Verizon Vcast service), users are allowed to stream multimedia files to their respective devices. In these services, the server sends out a transcoded version of the content, with the bandwidth of the transcoded version determined so as to not exceed the bandwidth offered to the user over a unicast channel when it is requested by the user. With networked streaming of video or other multimedia, the instantaneous bandwidth of the compressed video at any point in time is limited to the available network bandwidth, within the bounds of a buffer at the client, in order to maintain continuous video playback. If the instantaneous bandwidth exceeds the available bandwidth, playback at the client is disrupted.

[0023] When compressed multimedia is transmitted as files, rather than streamed, the bandwidth of the compressed multimedia does not need to be matched to the network bandwidth. The transmission time for the multimedia file does not need to correspond to the duration of the content of the multimedia file.

[0024] On-demand services consume bandwidth for each individual user, which is usually a very costly operation since it does not scale very well for large number of subscribers to the service. Although these practices bring down the bandwidth consumption, in most cases it need not necessarily be optimal for network and client device operations.

[0025] FIG. 2 shows a block diagram of a personalized broadcast video system 200, which provides simple user interface for personalization, while efficiently using network bandwidth and minimizing receiver battery device usage. The system 200 includes a head end 200, a broadcast network 210 and a receiver 240. The head end includes an input clip 202, a scheduler 204, an electronic service guide (ESG) generator 206 and a FLUTE server 208. The receiver includes a FLUTE receiver 212, and ESG parser 214, a content selection control 218, a user profile 216, a content storage device 220, and an audio/video player 222.

[0026] The user profile 216 on the receiver device 240 indicates the interests of the user. Individual clips 202 to be broadcast are associated with flexible metadata tags, such as keywords, are sent to the ESG generator 206 through the scheduler 204. When content, particularly video programs, is broadcast, the receiver device 240 selects individual programs to record based upon calculating a score corresponding to the program. The score is calculated for a particular piece of content using the ESG content keywords and the user's profile, which indicates a user's level of interest in particular keywords. The user's profile 216 can adapt based upon the user's viewing activity.

[0027] In an opportunistic bandwidth environment (i.e., Variable Bit Rate), the output channel bandwidth is not constant. This affects all the broadcast timing calculations for each content file done by the scheduler 204. Hence, to provide a reliable schedule of broadcast, the scheduler 204 needs to schedule broadcast of content files in a timely manner, based on available bandwidth and its own estimates of available bandwidth.

[0028] The scheduler 204 periodically outputs a schedule for content file broadcasts. This schedule is in the form of an ESG is communicated to a client device. In a unidirectional broadcast environment, the receiver 240 depends heavily on the schedule and meta-data information it gets for selective reception of the content. It is important that the client receive the schedule in advance of the actual broadcast time. The schedule broadcast by the server 208 contains meta-data information such as broadcast times for each content. The broadcast timing information is important to the client, since a client can use this information to selectively switch on and off its receiver components based on the broadcast times of different content, and hence make selective reception of content viable. Also, since the client is switching its receiver components on only when needed, there is efficient user of the client's power resources.

[0029] The scheduler 204 has a transmission monitor system (not shown) which controls the transmission of content files according to the schedule. The transmission monitor system updates the scheduler 204 with transmission status of each clip and variations in output channel speed.

[0030] According to the present invention, users of broadcast content services, such as those using the above-described systems, may receive content with varying compression formats depending on the bandwidth at the time the content was scheduled to be broadcast. In such systems, the content files are also scheduled to be re-broadcast as decided by the scheduler. If during the re-broadcast the amount of bandwidth is sufficiently high, then the scheduler may choose to broadcast a higher quality format of the content file.

[0031] By way of example, consider an audiovisual content Clip A is transcoded into two different compression formats, ClipA_lowComp and ClipA_highComp, with higher and lower bandwidth usages, respectively. The operator provides a number of live television services that generally use up most of the available bandwidth.

[0032] Referring to the exemplary implementation shown in FIG. 3a, there is shown the method 275 according to an implementation of the present principles. Initially, the bandwidth of a communication channel is established (280). Those of skill in the art will recognize that there are many different methods for establishing the bandwidth of a communication channel. It is to be understood that the present principles can be applied using any suitable method for establishing the bandwidth of the channel. Once established, the bandwidth information is transmitted (282) to the client device over the communication channel. At this point, a version of the data is transmitted (284) over the communication channel in response to a comparison between the established bandwidth and a bandwidth threshold.

[0033] FIG. 3b shows the method 300 according to an implementation of the present principles. Initially, the scheduler 204 processes its database of content files and decides to output a schedule based on current estimates of bandwidth (302). The schedule is then transmitted (304) to a client device 240. The client device now has an estimate of the times when each content file is going to be broadcast. Based on this information, the client can optimize its receiver routines.

[0034] Before the broadcast of each file, the scheduler 204 of the service can be configured with an initial value of the bandwidth, or can be configured to make an estimate of the available bandwidth (302).

[0035] According to one implementation, the bandwidth thresholds can be established as being half of the initial value or estimated value of the bandwidth. If at the beginning, the bandwidth threshold is at a high value, BW_HIGH, the scheduler 204 would choose to broadcast ClipA_lowComp which is of lower compression and hence higher quality but with more bandwidth usage. If during some time elapse, the bandwidth allocated to the service changes, the schedule would be affected. The scheduler would normally detect this through its transmission control module. For example, if the bandwidth of the channel now fell to a lower threshold value, BW_LOW, the scheduler detects that change in the bandwidth, which now affects the schedule of its content file broadcasts. This is the example shown in FIG. 3.

[0036] The scheduler 204, instead of re-scheduling all of its content files, will now choose to broadcast ClipA_highComp (308), which is highly compressed version of the content file whose quality and bandwidth usage may be lower but acceptable to the user. If the bandwidth at a later point of time increases to a value BW_HIGH, and content file Clip A is scheduled for a re-broadcast, then this time around the scheduler changes the threshold in the decision block 306 and would choose to broadcast Clip A_lowComp (310) and the client on receiving this content could potentially detect this as a higher quality version of a previous file and choose to replace the lower quality content file, ClipA_highComp.

[0037] The scheduler 204 chooses the version of the file to be broadcast so that it would still maintain the timeliness of its schedule. The client, hence, sees no change in the schedule although there was a change in the bandwidth that was allocated to the service. In this manner, the client device sees a seamless operation of the service.

[0038] FIG. 3 shows the example where the threshold determination of decision block 306 is BW_LOW. Those of ordinary skill will recognize that changing the threshold from BW_LOW to BW_HIGH will reverse the "yes" and "no" decisions of the shown implementation. This is shown, by way of example, in the flowchart of FIG. 4. Here, the steps 402, 404, 406 all correspond to the same steps 302, 304, 306, respectively. When the bandwidth threshold is above BW_HIGH, (otherwise, a "no" determination), the A_highComp clip is transmitted 408. When the bandwidth threshold is below BW_HIGH, the A_lowComp clip is transmitted 410.

[0039] It is to be understood that the present principles may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Preferably, the present principles may be implemented as a combination of hardware and software. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage device. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPU), a random access memory (RAM), and input/output (I/O) interface(s). The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may either be part of the microinstruction code or part of the application program (or a combination thereof) that is executed via the operating system. In addition, various other peripheral devices may be connected to the computer platform such as an additional data storage device and a printing device.

[0040] It is to be further understood that, because some of the constituent system components and method steps depicted in the accompanying Figures are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present principles is programmed. Given the teachings herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present principles.

Claims

1. A method for providing data over a network comprising the steps of: establishing a bandwidth value for providing a data over a communication channel; providing the bandwidth value to a client device over the communication channel; providing a version of the data over the communication channel to the client device in response to a comparison of the bandwidth value with a threshold.

2. The method of claim 1, wherein the establishing comprises estimating (302) the available bandwidth in the communication channel.

3. The method of claim 1, wherein said establishing comprises setting an initial value for the bandwidth.

4. The method of claim 1, further comprising setting the threshold based on the established bandwidth value.

5. The method of claim 4, wherein the threshold is set as one half the established bandwidth value.

6. The method of claim 4, wherein the providing further comprises transmitting a low compression version of the data when the bandwidth value is higher than the threshold.

7. The method of claim 4, wherein the providing further comprises transmitting a high compression version of the data when the bandwidth value is lower than the threshold.

8. An apparatus comprising: a head end scheduler configured to establish a bandwidth value for providing data over a communication channel, provide the bandwidth value to a client device, and provide a version of the data in response to a comparison between the bandwidth value and a threshold

9. The apparatus of claim 8, wherein the scheduler is configured with an initial bandwidth value.

10. The apparatus of claim 8, wherein the scheduler is configured to estimate the bandwidth of the communication channel to establish the bandwidth value.

11. The apparatus of claim 8, wherein the scheduler establishes the threshold based on half the bandwidth value.

12. The apparatus of claim 11, wherein the scheduler provides a low compression version of the data when the bandwidth value is higher than the threshold.

13. The apparatus of claim 11, wherein the scheduler provides a high compression version of the data when the bandwidth value is lower than the threshold.

14. An apparatus comprising: program code for establishing a bandwidth value for providing data over a communication channel; program code for providing the bandwidth value to a client device over the communication channel; and program code for providing a version of the data over the communication channel to the client device in response to a comparison between the established bandwidth value and a threshold.

15. The apparatus of claim 14, further comprising program code for setting the threshold based on the established bandwidth.

16. The apparatus of claim 14, wherein the program code for establishing a bandwidth value further comprises program code for estimating the available bandwidth of the communication channel.

17. The apparatus of claim 15, further comprising program code for setting the threshold as one half the established bandwidth.

18. The apparatus of claim 15, further comprising program code for providing a low compression version of the data when the bandwidth is higher than the threshold.

19. The apparatus of claim 15, further comprising program code for providing a high compression version of the data when the bandwidth is lower than the threshold.