Patent Application
20100138870
The present invention generally relates to communications systems and, more particularly, to wireless systems, e.g., terrestrial broadcast, cellular, Wireless-Fidelity (Wi-Fi), satellite, etc.
Today, mobile devices are everywhere—from MP3 players to personal digital assistants to cellular telephones to mobile televisions (TVs). Unfortunately, a mobile device typically has limitations on computational resources and/or power. In this regard, an Internet Protocol (IP) Datacast over Digital Video Broadcasting-Handheld (DVB-H) system is an end-to-end broadcast system for delivery of any type of file and service using IP-based mechanisms that is optimized for such devices. For example, see ETSI EN 302 304 V1.1.1 (2004-11) “Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H)”; ETSI EN 300 468 V1.7.1 (2006-05) “Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems”; ETSI TS 102 472 V1.1.1 (2006-06) “Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols”; and ETSI TS 102 471 V1.1.1 (2006-04) “Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG)”. An example of an IP Datacast over DVB-H system as known in the art is shown in
The above-described IP Datacasts are used to provide content-based services by distributing files such as an electronic service guide (ESG) and content files. In the context of
With respect to file-based content, head-end 10 of
Turning briefly to
As noted above, a receiver may have power limitations, e.g., battery life. In addition, a receiver in a broadcast network may only be receiving particular, or selected, file-based content at particular times. At other times, the receiver—while being fully powered up—is not processing any other content transmitted by the broadcast network. As such, it would be beneficial if the FLUTE sender (e.g., FLUTE sender 20 of head-end 10 of
Unidirectional broadcast networks (e.g., as shown in
In order to make a Push-Video On Demand (VOD) kind of service that works over broadcast networks, the sender has to satisfy the maximum number of receivers in getting their preferred content. In addition, the content providers and operators will also have their own priorities for transmission. An “operator” (also referred to as a service provider) is an entity that defines a broadcast service and provisions the contents for the service; a “content provider” is an entity that creates the content for a particular service or set of services.
Therefore, and in accordance with the principles of the invention, a head-end determines a transmission order for content files as a function of a dynamic priority value, which is determined in accordance with at least a dissimilarity measure between the content files; and transmits the contents files in accordance with the determined transmission order.
In an illustrative embodiment of the invention, the content files can be any sort of audio/video clips like, sports video, music video, news clip, movie sound track etc., and “clip meta data” is associated with each clip. The head-end includes a scheduler that determines a transmission order for content files as a function of a dynamic priority value, which is determined in accordance with at least a dissimilarity measure between the content files; wherein the dissimilarity measure of the content files is further determined as a function of the clip meta data associated with each clip. Schedule timing information and meta data information is transmitted over a broadcast network along with the clips so that receivers can do selective reception of their preferred clips, saving battery power and storage.
In view of the above, and as will be apparent from reading the detailed description, other embodiments and features are also possible and fall within the principles of the invention.
Other than the inventive concept, the elements shown in the figures are well known and will not be described in detail. For example, other than the inventive concept, familiarity with Discrete Multitone (DMT) transmission (also referred to as Orthogonal Frequency Division Multiplexing (OFDM) or Coded Orthogonal Frequency Division Multiplexing (COFDM)) is assumed and not described herein. Also, familiarity with television broadcasting, receivers and video encoding is assumed and is not described in detail herein. For example, other than the inventive concept, familiarity with current and proposed recommendations for TV standards such as NTSC (National Television Systems Committee), PAL (Phase Alternation Lines), SECAM (SEquential Couleur Avec Memoire) and ATSC (Advanced Television Systems Committee) (ATSC), Chinese Digital Television System (GB) 20600-2006 and DVB-H is assumed. Likewise, other than the inventive concept, other transmission concepts such as eight-level vestigial sideband (8-VSB), Quadrature Amplitude Modulation (QAM), and receiver components such as a radio-frequency (RF) front-end (such as a low noise block, tuners, down converters, etc.), demodulators, correlators, leak integrators and squarers is assumed. Further, other than the inventive concept, familiarity with protocols such as the File Delivery over Unidirectional Transport (FLUTE) protocol, Asynchronous Layered Coding (ALC) protocol, Internet protocol (IP) and Internet Protocol Encapsulator (IPE), is assumed and not described herein. Similarly, other than the inventive concept, formatting and encoding methods (such as Moving Picture Expert Group (MPEG)-2 Systems Standard (ISO/IEC 13818-1)) for generating transport bit streams are well-known and not described herein. Familiarity with Pull-VOD and Push-VOD services are also assumed. In a Pull-VOD service the user requests a particular video clip and the server sends it to that particular user. In a Push-VOD service, the user's preferred video gets pushed into the receiver without the user actively requesting the video. It should also be noted that the inventive concept may be implemented using conventional programming techniques, which, as such, will not be described herein. Finally, like-numbers on the figures represent similar elements.
Before describing the inventive concept,
As described earlier, in order to make a Push-VOD kind of service that works over broadcast networks, the sender has to satisfy the maximum number of receivers in getting their preferred content. In addition, the content providers and operators will also have their own priorities for transmission. An “operator” (also referred to as a service provider) is an entity that defines a broadcast service and provisions the contents for the service; a “content provider” is an entity that creates the content for a particular service or set of services.
In view of the above, we have observed a number of issues with regard to provisioning and scheduling content for transmission in a Push-VOD service. For example, the content database can change over a period of time and the operator preference can also change with the addition of new clips. As such, as new clips get added, priority based scheduling of clip transmission cannot just be performed since this can indefinitely block a less preferred clip from ever getting scheduled for broadcast.
In addition, the predictability of the schedule is another important factor. The schedule can change at any point of time due to the addition and removal of clips or even with a variation of priorities. However, in a unidirectional network environment the receiver terminal heavily depends on the schedule for timely reception of its preferred content. If the schedule is not predictable, the receiver has to stay on always and this unnecessarily wastes power. Moreover in a unidirectional network the receiver has no means to inform the sender about lost files. Hence, the predictability of the schedule is highly important for receiver operation.
Also, preference settings in a receiver can vary according to the personal interests of the user, location of the receiver, time of reception, etc. For example, in multimedia clip broadcast, it has been observed that viewers would naturally prefer to get new clips than getting a highly preferred clip over and over again. However, in a broadcast Push-VOD service there is no reverse channel that can immediately take into account preference settings. In this regard, any scheduling should address such issues when updating transmission schedules for multimedia clips.
In view of the above, a scheduler is described in accordance with the principles of the invention that enables a Push-VOD service to address the above-described issues. Therefore, and in accordance with the principles of the invention, a head-end determines a transmission order for content files as a function of a dynamic priority value, which is determined in accordance with at least a dissimilarity measure between the content files; and transmits the contents files in accordance with the determined transmission order.
In an illustrative embodiment of the invention, the content files can be any sort of audio/video clips like, sports video, music video, news clip, movie sound track etc., and “clip meta data” is associated with each clip. The head-end includes a scheduler that determines a transmission order for content files as a function of a dynamic priority value, which is determined in accordance with at least a dissimilarity measure between the content files; wherein the dissimilarity measure of the content files is further determined as a function of the clip meta data associated with each clip. Schedule timing information and meta data information is transmitted over a broadcast network along with the clips so that receivers can do selective reception of their preferred clips, saving battery power and storage.
Turning now to
An illustrative embodiment of a head-end, or server, 150 in accordance with the principles of the invention is shown in
Head-end 150 comprises ESG generator 215, FLUTE sender 220, IP encapsulator 225, DVB-H modulator 230, content database 235 and scheduler 240. ESG generator 215, FLUTE sender 220, IP encapsulator 225 and DVB-H modulator 230 are similar to the corresponding components shown in
As shown in
In accordance with the principles of the invention, scheduler 240 parses the content metadata associated with the clips stored in content database 235 for determining a transmission order for the multimedia content files. In this regard, scheduler 240 controls the transmission order, via control signal 242, to FLUTE sender 220. In addition, scheduler 240 provides additional scheduling information, via signal 241, to ESG generator 215 for use in forming the ESG transmitted to the receivers. This additional scheduling information is referred to herein as “scheduling metadata”. In particular, in addition to the content metadata associated with each clip, scheduler 240 adds scheduling metadata as shown in
With regard to content metadata 210, Content ID 211 is a unique numerical identifier for identifying each clip in content database 235. The Priority 212 is a numerical value representing a priority level for the identified clip. Description 213 is, e.g., the name of the TV program, a synopsis, actors, director, etc., as well as the scheduled time, date, duration and channel for broadcast. Finally, the Keywords 214 is a list of alpha-numeric words representing one or more keywords briefly describing the content in the identified clip.
With regard to scheduling metadata 200, the Dynamic Priority 201 is a numerical value representing the actual priority level for broadcasting or transmitting the identified clip. The Sent Count 202 is a numerical value representing the number of times the identified clip as been broadcast, or transmitted. The Waiting Time 203 is a numerical value representing the number of seconds that have elapsed since the identified clip was last broadcast. Finally, the Keywords 204 is a list of alpha-numeric words representing one or more keywords briefly describing the content in the identified clip. As noted above, keywords can be located in either scheduling metadata 200 or content metadata 210. In the former, Keywords 204 is determined by scheduler 240 parsing description 213. In the latter, Keyword 214 is set by an operator as a part of the content metadata 210.
Attention now should be directed to the flow chart of
In step 315, scheduler 240 checks if its time to generate the schedule, which is determined by the scheduling frequency, fS, 316. If its not time to generate a schedule, then scheduler 240 checks if content database 235 has been updated in step 325 (e.g., via signal 239 of
Once scheduler 240 determines in step 315 that it is time to generate a schedule, then execution proceeds to step 320, where scheduler 240 determines or updates values for scheduling metadata 200 for each identified clip and generates a schedule. First, if necessary, scheduler 240 parses description 213 to determine keywords for the Keywords 204 field of scheduling metadata 200. Alternatively, scheduler 240 uses Keywords 214 if present. Then, scheduler 240 determines a value representative of the actual priority for the identified clip (Content ID 211) and stores this value in Dynamic Priority 201 (described further below). Scheduler 240 also updates the value of Sent Count 202 to represent the number of times the identified clip has been sent; and updates the value of Waiting Time 203 to represent the number of seconds that have elapsed since the identified clip was last broadcast. Once the scheduling metadata for each identified clip has been determined, scheduler 240 generates the schedule for use by ESG generator 215 (via signal 241) and FLUTE sender 220 (via signal 242). Execution continues with step 325. It should also be noted that, for simplicity, other termination and/or error conditions are not shown in the flow charts described herein.
In order to avoid unnecessary implementation complexities both on the receiver side and sender side, the scheduler 240 is illustratively designed as a non-preemptive scheduler. This means that each video clip or any other content file does not get split into small chunks and transmission does not get spread over different time slots. In other words, once content transmission is started, the transmission does not get interrupted by scheduler 240 until the end in order to transmit another clip. This helps to minimize the time required for the completion of reception at the terminal. However, the inventive concept is not so limited and applies to a preemptive scheduler as well.
As noted above, scheduler 240 generates a schedule. In accordance with the principles of the invention, an illustrative schedule 400 is shown in
Referring now to
It can be seen from flow chart of
Wt=last broadcast time of clip(i)−t, (1)
which is simply the difference between the current time and the last broadcast time for that clip. However, if the value of the current duration, Di, is not equal to zero, then, in step 465, this duration is added to the waiting time, Wt, for each clip (also shown as waiting time 203 shown in
Wt=Wt+D
i, (2)
where Di represents the duration of the previously scheduled clip (or the time duration of the static part of the schedule).
In step 475, scheduler 240 determines the dissimilarity of clips not yet scheduled for transmission. In this regard, it should be noted that in realizing a Push-VOD kind of application over broadcast there is a lack of a feedback channel. There is no reverse channel for the end users to inform their preference to the sender. In a Push-VOD kind of application, there is typically a wide variety of users (receivers) whose priorities will be different from each other. A scheduler that doesn't take into account this particular issue is not ideal for a Push-VOD kind of application. For example, an enthusiast soccer fan is never going to like the Push-VOD application if he has to wait till the end of the next 10 clips of news and music video transmission in order to get the soccer world cup highlight.
In order to take into account the possibility of a wide variety of viewer preference, and in accordance with the principles of the invention, scheduler 240 gives a weighting for the dissimilarity of each of the clips available for scheduling compared to the previously scheduled clip in step 475 of
Illustratively, in step 475, scheduler performs the following similarity measure between two clips, e.g., an unscheduled clip—denoted as clip X—and the last scheduled clip—denoted as clip Y.
where S(x,y) is the similarity measure between clip X and clip Y; Ns is the number of similar keywords in both clip X and clip Y; N(x) is the total number of keywords in clip X and N(y) is the total number of keywords in clip Y. In equation (3), the value of S(x,y) can vary between 0 and 1. A value of 1 represents totally similar clips and a value of 0 represents totally dissimilar clips. Hence, the dissimilarity measure becomes
Ds(x,y)=1−S(x,y). (4)
This dissimilarity measure, Ds(x, y), of each unscheduled clip is then used by scheduler 240 in determining the dynamic priority for a clip. In this process the operator/content provider specified keywords are weighted more than the keywords generated by the scheduler by parsing synopsis/summary fields.
It should be noted that the dissimilarity measure can not only be done to identify the most dissimilar clip when compared to the previous one, but can also be extended to find out the most dissimilar clip when compared to the previous history of transmission. This is accomplished by making the dissimilarity measure a moving average of past dissimilarities. As such, in addition to equations (3) and (4), scheduler 240 may also further refine the dissimilarity measure. In particular, assume clip X having duration Δt is scheduled at a time “t−Δt”. Then Ds of each clip at time “t” can also be calculated as:
Ds(t)=(1−α)*Ds(x,i)+α*Ds(t−Δt), (5)
where Ds(x,i) is the dissimilarity of clip (i) against clip X (from equations (3) and (4)), Ds(t−Δt) is the dissimilarity value of clip (i) taken at time t−Δt, i.e., in a previous scheduling interval; and α is a constant whose value can range between 0 to 1. The value of α is chosen in such a way that more weighting is given to dissimilarity against the most recently scheduled clip than to the previous history.
After determining dissimilarity values for each unscheduled clip, scheduler 240 determines the dynamic priority in step 480 for all unscheduled clips. Illustratively, the dynamic priority of each clip at time “t” is given by:
Dp(t)=KpP+KdDs(t)+KwWt−KsSc, (6)
where Dp(t) is the dynamic priority of the clip at time t; P is the operator/content provider given priority of the clip (e.g., priority 212 of
It should be noted that although dynamic priority was described in the context of equation (6), any one, two or three of the variables P, Ds(t), Wt and Sc can be used for determining dynamic priority. Indeed, additional parameters can also be defined besides these four for determining dynamic priority in accordance with the principles of the invention.
As noted above, illustratively, the sent count, Sc, is used in order to take into account in the scheduling process the number of times a clip has been transmitted. For example, in a video clip broadcast system, the viewers will always look for new clips. Typically, viewers will prefer a new clip over old ones and this is some times the case even if the old clips were highly rated by the operator or content provider. Hence the scheduler should take into account the number of times a clip has been transmitted and schedule the clip accordingly. The scheduler solves this problem by using Sc to count the number of times that particular clip has been sent. All new clips will have their sent count, Sc, value as zero. In determining the dynamic priority of a clip, the scheduler will reduce the priority in direct proportion to the sent count. In other words, the lower the sent count, the higher the rise in dynamic priority.
In this regard, since the scheduler gives preference to high priority content and special consideration towards newly added clips over old clips, there is a possibility that frequent addition of new clips may keep the low priority clips in the database indefinitely without ever getting sent. In order to compensate for this, the scheduler accounts for the aging of clips, via the parameter Wt in equation (6). As such, the dynamic priority of a clip increases as the waiting time increases.
It can also be observed from equation (6) that a raise in operator/content provider priority, P, of a clip leads to a direct raise in dynamic priority. Hence operator/content provider preferred clips will likely get scheduled early.
In step 485, scheduler 240 selects the clip having the highest, or maximum, dynamic priority, Dp(t) at time, t, for transmission and places this clip in the schedule. It should be noted that if a number of clips have equal dynamic priority, scheduler 240 can select one of the clips or perform a round robin schedule among equal dynamic priority clips. For example, if all dynamic priority measures of a set of clips results in the same value, the scheduler simply iterates through the set to create the schedule and thus makes sure that all of them get sent.
In step 490, the selected clip has its waiting time set to zero (e.g., waiting time 203 of
As noted above, predictability of the schedule is important. In a unidirectional broadcast environment, a receiver heavily depends on the schedule and meta data information it gets to do a selective reception of content. So it is very important that the receiver should receive the schedule in advance. Moreover if any schedule change happens on the server due to addition of new content or any other reason, the latest schedule needs to be sent to all receivers. The scheduler does this by sending a periodic schedule update, e.g., every T=1/fS seconds, where fS, is the earlier mentioned scheduling frequency. The periodic schedule update comprises, e.g., newly scheduled events and other meta data associated with the scheduled contents. Using this information the receiver can decide whether it needs to receive the content and when to tune in to get the content. Thus the terminals can save both power and storage space.
However, in practical systems, the frequency of the schedule update and instantaneous reception of the schedule update on the terminal is limited. In other words, once a schedule change happens on the server, it will take some time for the receivers to know about it. Let's consider this delay as the minimum schedule update interval on the terminal. In order to account for this minimum schedule update interval and the unpredictability due to this, and in accordance with the principles of the invention, the scheduler introduces another concept—splitting the schedule into static and dynamic parts as illustrated in
This is further illustrated in
On the next scheduling interval, scheduler 240 determines that clips B, C, D, E and F are available for transmission (clip A having been sent). In addition, scheduler 240 determines that a prior schedule (ESG 701) existed and determines the static part 401. As noted earlier, scheduler 240 is illustratively designed as a non-preemptive scheduler. This means that each video clip or any other content file does not get split into small chunks and transmission does not get spread over different time slots. Thus, although static part 401 is defined has having a duration of two minutes (which would fall in the middle of clip C), static part 401 is temporarily extended to include the entire clip C. In other words, the static part has minimum time duration of two minutes. As a result, clips B and C are scheduled for transmission as previously determined in ESG 701. However, as can be observed from
Finally, on the next scheduling interval, scheduler 240 determines that clips C, D, E, F and G are available for transmission (clip B having been sent). In addition, scheduler 240 determines that a prior schedule (ESG 702) existed and determines the static part 401. However, now the static part 401 is set back to two minutes, since the static part 401 only includes clip C. Thus, clip C is scheduled for transmission as previously determined in ESG 702. However, as can be observed from
In view of the above, the schedule produced by the scheduler at any point of time will have two parts. The static portion of the current schedule will have events that were present in the previous schedule in the corresponding time periods. The static portion of the schedule will also move forward on the time line as the schedule moves. In other words, if there is a static duration of 30 seconds, then the schedule made at time instant t will have a static portion ranging from time t to t+30 and the schedule made at t+1 second will have a static portion ranging from t+1 to t+31.
Whenever a reschedule happens, the new reschedule changes go to the dynamic part of the schedule, which starts from t+static duration, where t is the time instant of rescheduling. The static part of the new schedule is made by taking events corresponding to the time period t to t+static duration from the previous schedule. Even though a fixed duration can be configured for the static part (e.g., 30 seconds) the exact static part may change according to the duration of clips in the static part as illustrated above with respect to ESGs 701, 702 and 703 of
The static duration of the schedule can be tuned over a period of time. Ideally the static duration equals the minimum schedule update interval required by the terminal. The rescheduling interval can also get tuned if required, to accommodate any overhead in processing and transmission of a new schedule. Thus any reschedule changes will get sent to the terminals, meanwhile the terminal can depend on the static part which is unchanged.
Referring now to
Another illustrative embodiment of a receiver 900 in accordance with the principles of the invention is shown in
An illustrative flow chart for use in either receiver 100 or receiver 900 is shown in
It should also be noted that in an opportunistic bandwidth environment (e.g., variable bit rate (VBR)) the output channel bandwidth is not constant. This affects all the timing calculations done by the scheduler. In order to account for this, the scheduler can be equipped with a bandwidth feedback interface. As such, scheduler 240 monitors the output bandwidth for calculating the transmission duration of each clip (duration=size of the clip/bandwidth) which will determine the time at which the scheduler can schedule the next clip. This is illustrated in server 150′ of
As described above, the inventive concept addresses a number of problems in scheduling multimedia content files for transmission over a broadcast network. For example, the inventive concept enables the content database to change over a period of time, with, e.g., the addition and/or deletion of new clips. In addition, the operator preference associated with individual clips can also change over time. Further, the scheduler is applicable to either a CBR (Constant Bit Rate) output channel or a VBR (variable bit rate) output channel.
It should be noted that although the inventive concept was described in the context of a DVB-H system, the inventive concept is not so limited. In addition, although the inventive concept was described in the context of a particular number of elements in the scheduling metadata, the inventive concept is not so limited and additional, or less, fields may comprise the scheduling metadata. Also, although the scheduler was shown as a part of the server or head-end the invention is not so limited and the scheduler may be separate from the server for providing the scheduling information to an ESG and/or FLUE sender.
In view of the above, the foregoing merely illustrates the principles of the invention and it will thus be appreciated that those skilled in the art will be able to devise numerous alternative arrangements which, although not explicitly described herein, embody the principles of the invention and are within its spirit and scope. For example, although illustrated in the context of separate functional elements, these functional elements may be embodied in one, or more, integrated circuits (ICs). Similarly, although shown as separate elements, any or all of the elements (e.g., of
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2008/007546 | 6/17/2008 | WO | 00 | 1/29/2010 |
| Number | Date | Country | |
|---|---|---|---|
| 60963782 | Aug 2007 | US |
