Patent Application
20080285579
The invention relates to providing non-real-time services in a best-effort manner in a digital broadcast communications network.
Digital broadband broadcast networks enable end users to receive digital content including video, audio, data, and so forth. Using a mobile terminal, a user may receive digital content over a wireless digital broadcast network.
The capacity of a wireless transmission channel, e.g., in a digital broadcasting system, can be divided between different services by using time-division multiplexing (TDM). In such a situation, each service reserves one slot from a TDM frame resulting in a fixed bit rate. The bit rate is determined by the size of the slot and the frame interval. Some services can have a variable bit rate. One example of such services is a real-time video service.
An issue arises because the TDM capacity should be reserved according to the maximum bit rate of the video service to guarantee that the stream will fit into the reserved slot. However, most of the time the reserved slots and/or the transmission frames are not completely filled resulting in wasted transmission capacity.
A potential solution to the unused capacity issue is to use the unused capacity from the real time services for one ore more non-real time services, such as, a file carousel. However, this leads to another problem.
Typically, broadcasting networks have a signaling method that indicates to receivers when the services, either real time or non-real time, are being broadcast (i.e., are “on the air”). One example of such signaling is the Electronic Service Guide (ESG) in IP Datacast (IPDC) over DVB-H network.
In a file carousel, where files are sent repeatedly on the same channel, the start and end times for each file can be calculated from the constant bit rate of the channel and the sizes of the files. These start and end times are then signaled in the ESG such that the receiver does not have to stay on all the time, but can save power and switch on just before the desired file is transmitted.
Another issue arises when the unused capacity from the real time services is utilized in a file carousel. That is, it is impossible to calculate when a particular file is on the air. This is caused by the fact that the bit rate is no longer constant, but changes in an unpredictable (random) manner.
More efficient ways of digitally broadcasting best-effort services would advance the art.
The following presents a simplified summary in order to provide a basic understanding of some aspects of the invention. The summary is not an extensive overview of the invention. It is neither intended to identify key or critical elements of the invention nor to delineate the scope of the invention. The following summary merely presents some concepts of the invention in a simplified form as a prelude to the more detailed description below.
In accordance with an embodiment, a best-effort service is divided into packets for best-effort digital broadcast transmission. The packets are encapsulated with an encapsulation protocol that uses a packet order defining field. The encapsulated packets are inserted into an unused portion of a slot of a digital broadcast transmission frame. Then, the encapsulated packets are repeatedly inserted into the unused portion of the slot of the digital broadcast transmission frame in a packet-carousel fashion. And the transmission frame is digitally broadcast. In accordance with an embodiment, a digital broadcast transmission is received. Encapsulated packets that have been repeatedly broadcast in a packet-carousel fashion are accessed from a best-effort portion of a digital broadcast transmission frame slot. And a best-effort service is composed from the encapsulated packets by combining the encapsulated packets in an order based on a packet order defining field of the encapsulated packets.
A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein:
In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope and spirit of the present invention.
Digital content may be created and/or provided by digital content sources 104 and may include video signals, audio signals, data, and so forth. Digital content sources 104 may provide content to digital broadcast transmitter 103 in the form of digital packets, e.g., Internet Protocol (IP) packets. A group of related IP packets sharing a certain unique IP address or other source identifier is sometimes described as an IP stream. Digital broadcast transmitter 103 may receive, process, and forward for transmission multiple IP streams from multiple digital content sources 104. The processed digital content may then be passed to digital broadcast tower 105 (or other physical transmission component) for wireless transmission. Ultimately, mobile terminals or devices 112 may selectively receive and consume digital content originating from digital content sources 104.
As shown in
Computer executable instructions and data used by processor 128 and other components within mobile device 112 may be stored in a computer readable memory 134. The memory may be implemented with any combination of read only memory modules or random access memory modules, optionally including both volatile and nonvolatile memory. Software 140 may be stored within memory 134 and/or storage to provide instructions to processor 128 for enabling mobile device 112 to perform various functions. Alternatively, some or all of mobile device 112 computer executable instructions may be embodied in hardware or firmware (not shown).
Mobile device 112 may be configured to receive, decode and process digital broadband broadcast transmissions that are based, for example, on the Digital Video Broadcast (DVB) standard, such as DVB-H or DVB-T through a specific DVB receiver 141. The mobile device may also be provided with other types of receivers for digital broadband broadcast transmissions. Additionally, receiver device 112 may also be configured to receive, decode and process transmissions through FM/AM Radio receiver 142, WLAN transceiver 143, and telecommunications transceiver 144. In one aspect of the invention, mobile device 112 may receive radio data stream (RDS) messages.
In an example of the DVB standard, one DVB 10 Mbit/s transmission may have 200, 50 kbit/s audio program channels or 50, 200 kbit/s video (TV) program channels. The mobile device 112 may be configured to receive, decode, and process transmission based on the Digital Video Broadcast-Handheld (DVB-H) standard or other DVB standards, such as DVB-Satellite for Handheld (DVB-SH), or DVB-Terrestrial (DVB-T). Similarly, other digital transmission formats may alternatively be used to deliver content and information of availability of supplemental services, such as ATSC (Advanced Television Systems Committee), NTSC (National Television System Committee), ISDB-T (Integrated Services Digital Broadcasting-Terrestrial), DAB (Digital Audio Broadcasting), DMB (Digital Multimedia Broadcasting), FLO (Forward Link Only) or DIRECTV. Additionally, the digital transmission may be time sliced, such as in DVB-H technology. Time-slicing may reduce the average power consumption of a mobile terminal and may enable smooth and seamless handover. Time-slicing entails sending data in bursts using a higher instantaneous bit rate as compared to the bit rate required if the data were transmitted using a traditional streaming mechanism. In this case, the mobile device 112 may have one or more buffer memories for storing the decoded time sliced transmission before presentation.
In addition, an electronic service guide may be used to provide program or service related information. Generally, an Electronic Service Guide (ESG) enables a terminal to communicate what services are available to end users and how the services may be accessed. The ESG includes independently existing pieces of ESG fragments. Traditionally, ESG fragments include XML and/or binary documents, but more recently they have encompassed a vast array of items, such as for example, a SDP (Session Description Protocol) description, textual file, or an image. The ESG fragments describe one or several aspects of currently available (or future) service or broadcast program. Such aspects may include for example: free text description, schedule, geographical availability, price, purchase method, genre, and supplementary information such as preview images or clips. Audio, video and other types of data including the ESG fragments may be transmitted through a variety of types of networks according to many different protocols. For example, data can be transmitted through a collection of networks usually referred to as the “Internet” using protocols of the Internet protocol suite, such as Internet Protocol (IP) and User Datagram Protocol (UDP). Data is often transmitted through the Internet addressed to a single user. It can, however, be addressed to a group of users, commonly known as multicasting. In the case in which the data is addressed to all users it is called broadcasting.
One way of broadcasting data is to use an IP datacasting (IPDC) network. IPDC is a combination of digital broadcast and Internet Protocol. Through such an IP-based broadcasting network, one or more service providers can supply different types of IP services including on-line newspapers, radio, and television. These IP services are organized into one or more media streams in the form of audio, video and/or other types of data. To determine when and where these streams occur, users refer to an electronic service guide (ESG). One type of DVB is Digital Video Broadcasting-Handheld (DVB-H). The DVB-H is designed to deliver 10 Mbps of data to a battery-powered terminal device.
DVB transport streams deliver compressed audio and video and data to a user via third party delivery networks. Moving Picture Expert Group (MPEG) has defined a technology by which encoded video, audio, and data within a single program or service is multiplexed, with other programs, into a transport stream (TS). The TS is a packetized data stream, with fixed length packets, including a header. The individual elements of a service, audio and video, are each carried within packets having a packet identification (PID) that may be unique for the service or to the components of the service. To enable a receiver device to locate the different programs and elements of a particular program within the TS, Program Specific Information (PSI) and Service Information (SI), which are embedded into the TS, are supplied. PSI/SI enables a receiver device to correctly process the data contained within the TS.
As stated above, the ESG fragments may be transported by IPDC over a network, such as for example, DVB-H to destination devices. DVB-H network may be used to transmit for example audio, video, and data streams. The destination device then determines the ordering of the ESG fragments and assembles them into useful information.
In a typical communication system, a cell may define a geographical area that may be covered by a transmitter or group of transmitters. The cell may be of any size and may have neighboring cells.
Communication between network components may be accomplished via the Open Systems Interconnection (OSI) standard. The OSI framework of the process for communication between different network components may be structured as seven layers or categories as described by the OSI reference model.
Aspects of the invention are directed to a method where, for each real time service reserving one slot, there may be a dedicated non-real time service, which may comprise, for example, one or more files, hereafter referred to as a “best-effort service.” The unused capacity of the slot is filled with this best-effort service. In this way, underutilization of the unused capacity may be minimized.
A best effort service refers to a network service in which the network does not provide any guarantees that data is delivered or that a user is given a guaranteed quality of service level or a certain priority. In a best effort network, users obtain best effort service, meaning that they obtain unspecified variable bit rate and delivery time, depending on the current traffic load.
Examples of best-effort services include, but are not limited to: content that remains the same, such as: movies, television series provided as video clips and/or image-files (e.g. .iso,.bin etc.), software downloads and updates, images, books; and content that changes, such as: teletext services (content changing), news, audio/video clips, and magazines.
In accordance with one or more embodiments, a file is transmitted in a carouselling fashion repeatedly in the same slot. The file may be split into small packets, encapsulated with a protocol that allocates an ascending, or descending, counter for each packet or uses some other field for defining the order of packets. Hence, the packets can be received in any order. Examples of such protocols include, but are not limited to: IPv6, File Delivery over Unidirectional Transport (FLUTE), BitTorrent, and the like. Therefore, the receiver can start, at any time, accessing the slots where the desired ‘best-effort service’ is mapped and can receive available packets. Due to the encapsulation protocol used for encapsulating the ‘best-effort service’, the receiver is able to compose the complete ‘best-effort service’ from the packets, which may be collected in any order.
In accordance with the definition in RFC 2460, the Fragment header is used by an IPv6 source to send a packet larger than would fit in the path Maximum Transmission Unit (MTU) to the packet's destination. In accordance with an aspect of the invention, this would mean that the MTU would vary depending on the data available within a particular slot and would be detected by the encapsulator and/or modulator, which are discussed below.
The next header field is an 8-bit selector that identifies an initial header type of a fragmentable part of the original packet (defined below). The next header field may use the same values as the IPv4 Protocol field [RFC-1700 et seq.].
The reserved 8-bit field may be initialized to zero for transmission and may be ignored on reception.
The fragment offset field may be a 13-bit unsigned integer. This field may represent an offset, in 8-octet units, of the data following this header relative to the start of the fragmentable part of the original packet.
The reserved 2-bit field may be initialized to zero for transmission and may be ignored on reception.
The M flag field may be used to indicate whether there are more fragments. For example, a value of 1 may be used to specify that there are more fragments, and a value of 0 may be used to specify that this is the last fragment.
A 32-bit Identification field may be generated by the source node for each packet to be fragmented. The value of the identification field should be different that that of other fragmented packets sent recently with the same source address and destination address. If a routing header is present, the destination address of concern is that of the final destination. In this context, “recently” means within a maximum likely lifetime of a packet, including transit time from source to destination and time spent awaiting reassembly with other fragments of the same packet. However, a source node does not need to know the maximum packet lifetime. Rather, it may be assumed to be sufficient to maintain the identification value as a simple, 32-bit, “wrap-around” counter, incremented each time a packet is fragmented. A single counter may be maintained for the node, or multiple counters, e.g., one for each of the node's possible source addresses, or one for each active (source address, destination address) combination, may be maintained.
In order to send a packet that is too large to fit in the MTU of the path to its destination, a source node may divide the packet into fragments and send each fragment separately such that the packet may be reassembled, via the received fragments, at the receiver.
Similar signalling may be used with other protocols in order to enable the carouseling of different fragments in multiple different locations and enabling a receiver to collect fragments when desired by the end user and/or allowed by the terminal configuration.
By such signalling, each fragment may be distinguished from other fragments and may be received at any time and in any order. As such, the start of the file access does not have to be synchronized to the start of the file. This results in short random access delay, which, in turn, allows files to be sent in parallel in the same frame or super frame, as is shown in
In
In other embodiments, there may be more than one file using the same slot. Or more than one files may use a particular slot in alternate frames. For example, file 1 may use slot 1 in odd-numbered frames (e.g., frames 1, 3, 5, etc.) and file 2 may use slot 1 in even-numbered frames (e.g., frames 2, 4, 6, etc.). Instead of one slot per frame, several slots may be used to transmit a particular file.
In other embodiments, the carouselling time per file per slot may be scheduled based on available capacity within each slot. To indicate when a file has been completely sent, there may be some feedback signalling from the modulator to the service system (or IP Encapsulator (IPE)). Also, the time consumed for carouselling a particular set of fragments of one file may be based on the service start and stop times, in a way that is similar to the case of mobileTV services and the like. Service start and stop times may be provided via an Electronic Service Guide (ESG).
In other embodiments, different service classes may be set for the best effort services. Different levels of ‘availability’ in the best effort slots can be defined for the services announced within an ESG. Some of the services could have higher class, indicating that a service is available more often within the best effort slots than the other services. A best-effort- service-class of this type could be signalled as one of the service description parameters within the ESG.
The de-multiplexer (DEMUX) block distributes the received data packets into different buffers based on the physical channel associated with each packet. Finally, the modulator fills the physical layer transmission slots of each physical channel. At first, each slot is filled with the data of the ‘regular’ services. In case the slots are not completely filled, the rest of the slot of a particular physical channel is filled with the data available in the best-effort buffer associated with the same physical channel.
Such categories may be, for example, Best Effort Service Classes (BESC) A, B and C. Based on the category, a network may allocate a different number of slots where service is available when there is spare network capacity available.
The slots for the best effort services may be allocated based on Best Effort Service Class (BESC), while the slot allocation for other services may be based on various parameters such as service bit-rate and used modulation.
In the Terminal side, an end user may optimize the download time and power consumption by setting a user-configurable mode that defines how often a receiver will inspect the allocated slots.
A configuration interface may be provided separately for each best effort service, or it may be common for all such services. Excessive mode means that receiver inspects all slots allocated for the best effort services. Normal mode inspects a bit less than excessive mode, and budget mode inspects a minimal amount of slots. The inspection criteria may be based, e.g., on the resulting extra power consumption attributable to reception of the best effort services. For example, in the excessive mode, it could mean that the receiver is on constantly until a desired service is downloaded.
Aspects of the invention may be used in any communication system, including, but not limited to digital broadcasting systems, where best effort services, e.g., non-real time file down load, are used to fill the unused capacity resulting from the bit rate variation of the real time services, such as, video streams.
One or more aspects of the invention may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skill in the art, the functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), application specific integrated circuits (ASIC) and the like.
Embodiments of the invention include any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. While embodiments have been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques. Thus, the spirit and scope of the invention should be construed broadly as set forth in the appended claims.
