Patent Application
20120207075
Wireless communication technologies have seen explosive growth over the past few years. This growth has been fueled by wireless services providing freedom of movement to the mobile public, and cutting the tether to hardwired communication systems. As a result of service enhancements, the popularity of wireless services is expected to continue to grow rapidly. A recent addition to wireless communication services has been the ability to broadcast television and other content to receiver devices. Mobile forward-link-only broadcast services allow users to view multimedia programming, such as television shows, as well as receive mobile editions of news, entertainment, sports, business, and other broadcast programming, using mobile receiver devices configured to receive the mobile broadcast transmissions. The growth of multimedia broadcast services represents an attractive communication platform for delivering a wide variety of content in various formats.
Various embodiments may provide systems, devices, and methods for utilizing a broadcast based File Delivery Framework (FDF) to deliver datagram packets (e.g., data packets according to User Datagram Protocol (UDP), AppleTalk, NetBIOS, etc.), to applications running on receiver devices. Specifically, various embodiments may provide mechanisms and systems for efficiently delivering datagram packets to receiver device applications by embedding the datagram packets within files, which may carry datagram packets from a variety of sources, and delivering the files over a broadcast system to receiver devices using the FDF service of a broadcast communication network. In particular, the datagram packets may be UDP packets which may be provided by receiver devices to applications running on the devices which expect UDP packets as data inputs. Datagram packets from different content sources may be embedded in a single file for efficient broadcast and reception. Such bundling of different datagram packets (e.g., UDP packets) within conglomerate files for broadcast may be organized according to the type of information or application (e.g., grouping news source UDP packets within a conglomerate news file for broadcast), or according to demographics (e.g., grouping UDP packets for applications of interest to children in a conglomerate file for broadcast), for example. Files and datagram packets for broadcast and/or reception may be advertised in advance by the broadcast network by broadcasting a Broadcast Schedule Message (BSM). BSMs may be transmitted in advance to inform receiver devices of the files and datagram packets that will be broadcast at a specified time in the future. The various embodiments utilize the built in redundancy, error correction and reliability mechanisms provided by the FDF service to deliver datagram packets in a more timely, coherent and effective manner. Receiver devices may use the advertised broadcast times to selectively receive files and access their included datagram packets corresponding to application requests. Applications requesting particular types of datagram packets (e.g., those UDP packets meant for the requesting application) may then receive and utilize the datagram packets as they are received by the receiver devices.
Various embodiments may include a method for delivering UDP packets to a receiver device over a broadcast communication network, which includes receiving in a server of the broadcast communication network UDP packets for transport from a content provider, generating in the server files containing the received UDP packets, the generated files having a file name and containing information regarding the UDP packets contained in the files and communication requirements, scheduling the generated files for transmission via a file data flow within a broadcast transmission, generating a broadcast scheduling message indicating when files will be broadcast within a broadcast scheduling period, information regarding those files, and a scheduled broadcast time window for each file, broadcasting the generated broadcast scheduling message via the broadcast network, and broadcasting the generated files via the file data flow of the broadcast network in accordance with the scheduled broadcast time windows included within the broadcast scheduling message. In an embodiment, the method may further include receiving from an application operating within the receiver device a request to capture UDP packets, the request specifying one or more reception criteria, receiving the broadcast scheduling message in the receiver device, identifying for reception a file containing UDP packets matching the reception criteria based on information in the received broadcast scheduling message, identifying from the broadcast scheduling message the scheduled broadcast time window when a file matching the reception criteria will be broadcast, activating a receiver circuitry of the receiver device at the identified scheduled broadcast time window for the identified file, receiving in the receiver device the identified file from the broadcast transmissions, extracting the requested UDP packets from the received file, and passing the extracted UDP packets to the requesting application operating within the receiver device. In a further embodiment the method may also include storing version identifying information in memory in the receiver device, the version identifying information indicating a version of the received identified file, monitoring the broadcast scheduling message for new versions of the identified file, and receiving in the receiver device an updated version of the identified file from the broadcast network when the broadcast scheduling message indicates that a new or updated version of the identified file is being broadcast. In a further embodiment the file capture request may be received by the receiver device in the form of commands to capture a file containing the requested UDP packets once or as a command to capture all instances of the file. In a further embodiment the generated broadcast scheduling message may further identify a time when the broadcast scheduling message will be updated, and the method may further include broadcasting the broadcast scheduling message multiple times within the broadcast scheduling period, deactivating receiver circuitry in the receiver device after the broadcast scheduling message has been received, determining when the current time equals the time the broadcast scheduling message will be updated, reactivating the receiver circuitry in the receiver device when the current time equals the time the broadcast scheduling message will be updated, and receiving an updated broadcast scheduling message. In a further embodiment, the generated files may be scheduled for broadcast based upon a relative urgency identified by a file ingestion system. In a further embodiment the files may be generated to contain UDP packets from content providers targeting users having similar demographics, or to contain UDP packets from content providers providing similar services, such as news services. In a further embodiment the application operating within the receiver device may receive the UDP packets without being exposed to the delivery method used to deliver the UDP packets to the receiver device. In a further embodiment the broadcast communication network UDP packets for transport from a content provider may include receiving in the server UDP packets from a plurality of content providers, and generating files containing the received UDP packets in the server may include generating a single file containing UDP packets received from at least two different content providers. In a further embodiment extracting the requested UDP packets from the received file may include extracting UDP packets from a plurality of content providers from the received file, and passing the extracted UDP packets to the requesting application may include passing selected extracted UDP packets to a plurality of requesting applications.
Further embodiments may include a broadcast communication system including a broadcaster network and receiver devices which includes means for performing functions of the embodiment methods described above.
Further embodiments may include a server having memory and a processor configured to perform the operations of the embodiment methods described above that are accomplished within a broadcaster. Further embodiments may include a server having means for performing functions of the embodiment methods described above that are accomplished within a broadcaster. Further embodiments may include a non-transitory computer readable storage medium on which is stored server-executable software instructions configured to cause a server within a broadcaster network to perform the operations of the embodiment methods described above that are accomplished within a broadcaster.
Further embodiments may include receiver devices including broadcast receiver circuitry and a processor configured to perform the operations of the embodiment methods described above that are accomplished within a receiver device. Further embodiments may include a receiver device having means for performing functions of the embodiment methods described above that are accomplished within a receiver device. Further embodiments may include a non-transitory processor readable storage medium on which is stored processor-executable software instructions configured to cause a processor within a receiver device to perform the operations of the embodiment methods described above that are accomplished within a receiver device.
The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the features of the invention.
The various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any implementation described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other implementations.
The terms “mobile device” and “receiver device” are used interchangeably herein to refer to any one or all of cellular telephones, smartphones, personal or mobile multi-media players, personal data assistants (PDA's), laptop computers, tablet computers, smartbooks, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, and similar personal electronic devices which may include a programmable processor and memory and forward-link-only (FLO) mobile TV broadcast receiver circuitry for receiving and processing FLO broadcast transmissions.
The word “broadcast” is used herein to mean the transmission of data (information packets) so that it can be received by a large number of receiving devices simultaneously, and includes multicast. Examples of broadcast messages are mobile television service broadcast signals, including content broadcasts (content flow) and overhead information broadcasts (overhead flow) such as metadata messages.
A number of different mobile broadcast television services and broadcast standards are available or contemplated in the future, all of which may implement and benefit from the various embodiments. Such services and standards include, e.g., Open Mobile Alliance Mobile Broadcast Services Enabler Suite (OMA BCAST), Digital Video Broadcast IP Datacasting (DVB-IPDC), Digital Video Broadcasting-Handheld (DVB-H), Digital Video Broadcasting-Satellite services to Handhelds (DVB-SH), Digital Video Broadcasting-Handheld 2 (DVB-H2), Advanced Television Systems Committee-Mobile/Handheld (ATSC-M/H), and China Multimedia Mobile Broadcasting (CMMB). Each of these broadcast formats involves a broadcast communication channel. For ease of reference, the various embodiments may be described with reference to a FLO broadcast systems. However, references to FLO terminology and technical details are for illustrative purposes only and are not intended to limit the scope of the claims to FLO technology or any a particular FLO communication system unless specifically recited in the claim language.
Generally, applications running on receiver devices (device applications) may receive data updates through a “point-to-point” communication system. Point-to-point communication systems typically use a request/response method of communication, whereby device applications connect to a well known server, request data, download the requested data, and use the downloaded data to present users with updated information and/or services. This request/response method of communication is inefficient and consumes a significant amount of the available bandwidth. This is especially true when a large number of devices request the same information at the same time—a common scenario for devices running popular and/or high-demand applications requiring regular updates, such as news, traffic, and weather applications.
An alternative to the point-to-point system described above is a broadcast-based communication system. In broadcast systems (e.g. FLO TV or other broadcast systems), data is transmitted so that it may be received by a large number of receiving devices simultaneously. Unlike point-to-point systems, receiver devices in broadcast communication networks do not connect to a server and/or expressly request data. Rather, in broadcast systems, data is periodically transmitted over the network for reception by all receivers, and individual receiver devices either continuously listen for the data or periodically “wake up” at scheduled times to selectively receive the data being broadcast. Thus, broadcast networks generally only transmit data and do not have a direct return communication link from the receiver device to the broadcast server. These and other characteristics provide broadcast networks with some advantages as well as some disadvantages compared to point-to-point systems.
One of the numerous advantages of using a broadcast system is that device applications receiving data updates over broadcast do not incur as much cost (in terms of time, efficiency, bandwidth, battery consumption, etc.) as they would in a point-to-point system, because the receiver devices do not have to expressly request information. Another advantage is that broadcast systems are more efficient at delivering data to popular, high-use and high-demand applications. This is partially because it is cheaper and more efficient to broadcast high-demand data to a large number of recipients at the same time, rather than to each device individually. By broadcasting the same content widely, broadcast systems can deliver content to receiver devices much faster using much less bandwidth that is possible if the content is transmitted to one receiver device at a time, as in unicast systems. For these and other reasons, using a broadcast system to deliver data useful to multiple receivers can yield improvements in system efficiency, such as measured in terms of cost-per-bit, and can improve the receiver battery life of receiver devices.
Broadcast systems also have a number of limitations compared to point-to-point systems. As mentioned above, receiver devices must either continuously listen for data or periodically “wake up” to receive data. Continuously listening for data is inefficient, consuming a lot of battery power that may lead to short battery life and impact the user experience. On the other hand, by periodically “waking up” to receive information the receiver device risks data loss, as the device may not be “awake” when the desired information is broadcast. Further, since broadcast systems only transmit and do not have a direct return link, broadcasters have no way of knowing whether the receiver devices have correctly received the data. Thus, data loss and data integrity are common problems when transmitting data over a broadcast network.
To alleviate problems associated with data integrity, numerous protocols exist for grouping information into self contained “packets” and transmitting the individual packets over the broadcast network. Such transmission packets may contain error correction codes that allow receiver devices to detect and correct erroneous and/or corrupt data within received packets. These protocols also help improve system performance by grouping and transmitting data in chunks, so that the loss of one packet will not affect a receiving device's ability receive and decode future packets. A receiver can just ignore the contents of an entire packet and correctly decode the next received coherent packet.
One such protocol for broadcasting/transmitting information is the User Datagram Protocol or Universal Datagram Protocol (UDP). With UDP, applications can send messages (i.e., datagrams), to other hosts on an Internet Protocol (IP) network (or other networks) without requiring prior communication links to set up special transmission channels or data paths. However, UDP uses a simple transmission model without any implicit hand-shaking for guaranteeing packet reliability or ordering. Thus, UDP provides an “unreliable service,” as the transmitted datagrams may arrive out of order, appear duplicated, or go missing without notice. That is, while each individual UDP packet may contain error correction codes for correction of data contained within each individual packet, UDP packets may not include information regarding other UDP packets. Accordingly, most systems using UDP to transmit or receive data must assume that error checking and correction is either not necessary or performed locally by the receiving device. Also, UDP packets typically contain a relatively small amount of information. This means that each UDP packet is transmitted within only a small amount of time. Such short transmission times can be easily missed by mobile receiver devices due to the device's mobile nature (e.g., when a mobile phone travels into a tunnel) and battery conservation features (e.g., the device waking up a few microseconds late).
Other protocols for broadcasting/transmitting information in the form of datagrams include AppleTalk and NetBIOS, which share many of the same characteristics of UDP packets described above. For ease of reference, the various embodiments and examples are described with reference to UDP datagrams. However, references to the UDP terminology and technical details are for illustrative purposes only and are not intended to limit the scope of the claims to a particular type of datagram, unless specifically recited in the claims.
The various embodiments overcome the above mentioned limitations by utilizing a broadcast based File Delivery Framework (FDF) service to deliver datagram (e.g., UDP) packets to applications running on receiver devices. Specifically, the various embodiments provide mechanisms and systems for efficiently delivering datagram packets to receiver devices by embedding the datagram packets within files, and delivering the files using the FDF service of a broadcast system. The various embodiments utilize the built in broadcast scheduling, redundancy, error correction and reliability mechanisms provided by the FDF service to deliver datagram packets in a timely, reliable, coherent and effective manner.
The various embodiments provide mechanisms and systems for efficiently delivering datagram packets by embedding the datagram packets within files, and delivering the files over a broadcast system to receiver devices using the FDF service. Files for broadcast and reception in accordance with the various embodiments may be logically identified as belonging to a directory in a file system. In order to make use of this file system abstraction for the broadcast of files containing datagram packets, the broadcast system broadcasts information to receiver devices regarding the files that will be broadcast, and when the files are scheduled for broadcast. This broadcast schedule notification may be accomplished by broadcasting Broadcast Schedule Messages (BSMs) which include information to inform receiver devices of file broadcast schedules, along with the identity of the datagram packets that will be included in those files. Receiver devices receiving BSMs can use them to determine whether and when to receive file transmissions from the FDF service in order to download datagram packets relevant to applications running on the receiver devices.
Each BSM may include file content and broadcast schedule information such as: the association of files being broadcast with various services or applications (e.g., a service ID or a file name on an application specific directory); identification of whether a file being broadcast is a new, updated or repeated file (e.g., a file ID or version number); the broadcast transport stream where the file can be received (e.g., a flow ID, an IP flow identified by an IP address and UDP port number); the time at which the file will be broadcast (e.g., a delivery window); when the delivery schedule information (e.g., the BSM) may be updated with new information; whether the file contains datagram (e.g., UDP) packets; the types of datagram packets contained, if any; and information (e.g., a look-up table) associating applications with individual datagram packets and/or datagram packet groups and blobs that will be included in each broadcast file.
The BSM may be carried as part of an overhead transport stream (e.g., a flow ID, an IP address and UDP port number) that provides the delivery schedule information for files broadcast on a given frequency (e.g., channel 55), on a portion of the transmit spectrum in that frequency (e.g., a FLO local vs. wide multiplex), and/or for a transport technology (e.g., FLO or ATSC). The availability of these overhead flows, the channel, flow or frequency used for such transmissions, the portion of the signal or super-frames where the BSMs are broadcast, and the transport technology used for transmitting BSMs may be discovered via a bootstrap overhead flow (e.g., IAF in FLO).
A receiver device configured according to the various embodiments may make use of the information within BSM messages to select particular files for reception from among the different file broadcasts advertised in BSMs. Receiver devices may select files for reception based on the service or application to which the file or included datagram packets are associated. Thus, receiver devices may select files for reception based upon an identifier or applicability information included in the BSM without considering the files contents. Alternatively or additionally, receiver devices may select files for reception based upon datagram identifiers or application applicability information included in the BSMs regarding the datagram packets contained within the files. A receiver device may also make use of the BSM message to select files for reception based on whether the file is new or an update to a previously received file. The BSM may also support aliasing of application/service IDs and transporting bundles of files.
The various embodiments may include a file ingestion system (FIS) within or in communication with the broadcast network which may provide an interface that content providers can use to notify the broadcast system of new files (e.g. data files, files containing datagram packets) to broadcast. Content providers may use the file ingestion system to specify the broadcast transport requirements for files, such as the timeliness requirements (e.g., latency tolerance) and robustness requirements (e.g., level of FEC or number of retransmissions). The file ingestion system may use the transport requirements specified by content providers at the time of new file ingestion, and attempt to pack a new file into the broadcast transmission stream along with already accepted files scheduled for transmissions. File ingestion may be considered to have failed if this packing is not successful (i.e., the new file could not be fit within the transmission stream with files already scheduled for transmission).
Once a new file has been processed by the file ingestion system, the file ingestion system may generate a BSM that may advertise only a fraction of the successfully scheduled files over a broadcast schedule period, allowing receiver devices to plan reception of file broadcasts over the advertise broadcast schedule period, while allowing new file ingestions to be accommodated with modifications to the schedule information for files already accepted for transmission but whose delivery schedules have not yet been advertised via a BSM. Based on the existing schedule information, the broadcast system may control updates to the BSM and the transmission of files per advertised BSMs.
At any given time, the BSM may advertise only a portion of the broadcast schedule information. There is an inherent a trade-off between content freshness, which is maximized by limiting the amount of broadcast schedule addressed in each BSM, and power consumption (which reduces battery life) by receivers, which is minimized by maximizing the amount of broadcast schedule addressed in each BSM. Allowing BSMs to change frequently, enables broadcasters to broadcast files with shorter notice and to accommodate changes in file delivery priorities and schedules. However, receiver devices must power up to receive the BSM transmissions more often, thus consuming more battery power, when the BSM may change frequently. Thus, broadcasters may compromise in the generation of BSMs between frequently updating BSMs to enable to file broadcast schedule flexibility, and limiting the time between changes to the BSM in order to enhance the user experience.
The file ingestion system for a file broadcast system may also support ingestion of attributes associated with files, as well as formatting of the file attributes so they may be carried via an overhead message (e.g., a BSM). Such file attributes may allow receiver devices to select files for reception and download, such as by using filtering criteria to select files based on their file attributes.
The file ingestion system may also allow ingestion of multiple files at a time. Accepting multiple files together may enable files to be bundled together for transmission as a single file (or a few large files) for forward error correction efficiency. Alternatively, multiple files may be successfully scheduled for transmission if they are not bundled.
A broadcast network providing file transport services (e.g., an FDF service) may be resource bound. Therefore, it is desirable that the manner in which resources are dedicated to file transport be efficient and address different requirements associated with the different deployed file delivery applications. This is may be accomplished by organizing resources into file delivery “pipes,” which is a construct to capture the resource allocation for file transport and the multiplexing of different files on a given pipe. Different strategies may be used for defining multiple file delivery pipes on a network and scheduling files across such different pipes. Utilizing such a file delivery pipe construct, a file ingestion system may be made aware of file delivery pipes defined in the broadcast system. So informed, the file ingestion system may schedule files across such transmission resources in a manner that addresses application-specific delivery requirements specified for each of the files. Classes of applications may be mapped to specific pipes, e.g., small files with low latency requirements may be broadcast on dedicated pipes. The file ingestion system may also split transmission of large files into disjoint broadcast windows to allow short file transmissions. In an embodiment, the file ingestion system may schedule multiple concurrent file transmissions on the same pipe via different flows.
In the various embodiments, a broadcast-side application may create datagram (e.g., UDP) packets containing data for delivery to a corresponding application on receiver devices. The datagram packets may be bundled together into one or more files which are transmitted by the broadcast system over a file transport network (e.g., a FDF service). That is, in the various embodiments, a broadcast system may transport (i.e., broadcast in the form suitable for reception by suitably configured receiver devices) files containing datagram packets to particular applications or services that may be implemented on receiver devices.
In the various embodiments, the broadcast-side application or service submitting datagram packets for transport may submit a large number of datagram packets to a file ingestion system for assembly into one or more files for transport. Datagram packets from one or more applications may be multiplexed into one or more files. The corresponding application or service on the receiver device may only be compatible with, or interested in, a sub-set of the datagram packets contained in any given file among the files being broadcast. In this case, the broadcast-side application or service may supply application or service applicability metadata regarding the datagram packets and/or the assembled files to the file delivery service of a broadcast system, enabling the system to construct BSM or similar overhead file (e.g., a catalog file) that includes this identifying metadata. The BSM overhead file may list all the files that will be broadcast within a broadcast period, along with identification or applicability information for the datagram packets within each file. Such datagram packet identifying metadata may include application-specific attributes, such as the name or identifier of applications or services which can or should receive the datagram packets.
On the receiver device, the BSM overhead file may be received and the corresponding application operating on the device may use the information in this overhead file to select files and datagram packets for reception. The applications operating on the device may make this selection based on application-specific logic and available attributes.
An application operating on the receiver device may also request reception of selected files described in the BSM from the file delivery service in the broadcast system by indicating to a file delivery service module application or service file names, an identifier for a desired file, datagram packet types or application types, or specific datagram packets or datagram packet groups/blobs. The file delivery service module on the receiver device may determine from the BSM when, and on which, channel/flow/broadcast resource the indicated files containing the desired datagram packets are to be broadcast. This information allows the receiver device processor to “wake-up” the receiver circuitry only if the broadcast is likely to contain datagram packets requested by or compatible with device applications. The information in the BSM also enables receiver device processors to pinpoint the exact time frame within which the receiver needs to be on and listening for data, thereby conserving significant battery, processing, and networking resources.
An application or service on the sender side using the file delivery service (e.g., an FDF service) of a broadcast system may provide the application-specific attributes associated with the files and/or datagram packets at the time when the files are submitted to the file ingestion system for transport. Such application-specific attributes may be transported to receiver devices via the BSM. The device application may request a datagram packet capture from the receiver file delivery service module by indicating a regular expression within the applications-specific parameters which characterizes the file and/or datagram packets of interest so that such parameters may be used as file selection filtering criteria. The receiver device file delivery service module may use such filtering criteria to identify from the BSM the day/time, flow ID, etc. to receive only the desired files, or files containing the desired datagram packets.
The various embodiments may be implemented within a variety of mobile multi-media broadcast systems, an example of which is illustrated in
In addition to the normal content delivery system, the mobile broadcast network 1 may also include a file ingestion system (FIS) server 31 for receiving, storing, scheduling and formatting files for broadcast via the mobile broadcast network 1. The file ingestion system server 31 may receive files for broadcast from a file content provider 9, either via a direct network connection or an indirect network connection, such as the Internet 7. The file ingestion system server 31 may also receive files for broadcast from a file constructor 5, either via a direct network connection or an indirectly (e.g. via the Internet 7). The content provider 9 may also submit content in the form of datagram (e.g., UDP) packets to the file constructor 5. In this case, the file constructor 5 may package the datagram packets received from the content provider 9 into files, and submit the packaged files to the file ingestion system server 31.
In addition to the mobile multimedia broadcast network 1, receiver devices 10 will typically also be configured to communicate via a unicast network 11, such as a cellular telephone network. A typical cellular telephone network includes a plurality of cellular base stations 12 coupled to a network operations center 14, which operates to connect voice and data calls between receiver devices 10 and other network destinations, such as via telephone land lines (e.g., a POTS network, not shown) and the Internet 7. Communications between receiver devices 10 and the unicast network 11 are accomplished via two-way wireless communication links 13, such as G-3, CDMA, TDMA, and other cellular telephone communication technologies. To facilitate Internet data communications, the unicast network 11 alone will typically include one or more servers 16 coupled to or within the network operations center 14 that provide a connection to the Internet 7. In a further embodiment, the unicast network 11 may be a wireless wide area network such as WiFi, WiMAX, etc. Mobile receiver devices 10 may communicate with the broadcast network 1 via the unicast network 11, such as via an IP data call to a broadcast network server by way of the Internet 7, for purposes of subscribing to broadcast services and reporting user viewing patterns.
In a typical multimedia mobile broadcast system, information may be transmitted in wireless signals organized into a plurality of superframes. Each superframe comprises signals within a frequency band and within set time boundaries that encode a plurality of data packets that communicate the broadcast content along with overhead information used by receiver devices 10 to receive selected content. For example, in the FLO broadcast system, broadcast transmissions are organized into one-second superframes spanning a frequency band (for example 716 MHz to 722 MHz). FLO broadcast signals may be sent on other frequency bands and multiple signals may be sent simultaneously by using multiple distinct frequency bands. Each superframe includes a portion dedicated to the overhead flow and a portion that carries multiple channels associated with content flows. Information within the overhead flow and other overhead streams (e.g., a control channel) informs receiver devices of where within the superframe that particular content flow can be obtained, as well as how many packets are associated with the streams of that content flow.
While
As an illustration of various embodiments,
In assembling files to be transmitted, the file constructor 5 may create the files using a file system analogy, where a file path name in an application-specific directory structure uniquely identifies a file for a set of applications. The file constructor 5 may also insert identifiers into the file to be transmitted identifying the source and location of individual datagram packets within the file. As described above, within a server in the headend of the broadcast system the file ingestion system (FIS) 31 may be provided to receive files for transport, schedule the files for delivery opportunities in the broadcast schedule, and store successfully scheduled files in memory for later transport over the file transport network 41 of the broadcast network. The file ingestion system 31 may specify additional attributes regarding the files, such as a filename, parameters descriptive of the file (e.g., genre, file type, etc.), parameters descriptive of the file contents (e.g. source and location of individual datagram packets, identity, application or file types of the datagram packets included in the file, etc.), and other information associated the content of files for transport. The file ingestion system 31 may also specify parameters describing each file's broadcast delivery requirements. In various embodiments, the file ingestion system 31 may assign a unique identifier to files (e.g., a fileID) which can be used for versioning purposes and for bundling submitted files into combined packages for efficient application of forward error correction (FEC) codes. For example, file identifiers can be use to uniquely identify each file, identify the version of the identified file, and provide a sequence order for the file or packets. The file ingestion system may also apply forward error correction codes to ingested files to improve their broadcast transport reliability.
In an embodiment, the file ingestion system 31 may schedule broadcast delivery opportunities for newly received files for transport. As part of this process, the file ingestion system 31 may determine a transmission schedule based on various parameters. For instance, in an embodiment, the file ingestion system may create a transmission schedule as a function of the file sizes and available resources. In another embodiment, transmission schedules may also take into consideration a priority assigned to the files, or the datagram packets contained within the files, by the content providers. The scheduling of the file broadcast times may be accomplished algorithmically to determine start times for transmission such that the broadcast delivery requirements for the newly received files and the previously ingested files are met. The file ingestion system 31 may store successfully scheduled files for later transport over the file transport network 41. The file ingestion system 31 may, at the appropriate time, dispatch scheduled files to the broadcast network according to the file schedule information previously determined by the file ingestion system 31.
In scheduling files for transmission, the file ingestion system 31 may be aware of the transmission resources, such as file delivery pipes defined in the file transport network 41 for the broadcast of files. Using the information regarding the availability of file delivery pipes, the file ingestion system 31 may schedule files across the various transmission resources so as to address the application-specific delivery requirements defined by the file content providers. In some embodiments, the file ingestion system 31 may be configured to use specific pipes for certain classes of applications. For instance, small files with low latency requirements may be broadcast on dedicated transmission pipes. Alternatively, the file ingestion system 31 may split transmissions of large files into disjoint broadcast windows to allow short file transmissions with reduced delay. The file ingestion system 31 may also schedule multiple concurrent transmissions of the same type via different transmission pipes.
On the receiver device, such as a FLO receiver device, a file delivery service module 44 may be implemented within software to provide file capture services for the device applications 45, 46. The file delivery service module 44 may receive requests for datagram packets (e.g., UDP packets identified by type, identifier, etc.) from the device applications 45, 46, and use delivery information and scheduling in the BSM to capture the files carrying the requested datagram packets (or requested types of data packets) and store them in memory.
As part of the file delivery framework 40, a series of BSMs may be broadcast in an overhead message flow that is available in the broadcast transport network. As discussed above, the BSMs may provide information that enables receiver devices to associate files being broadcast, and the datagram packets contained within the files, with a particular service or application (e.g., a service ID or filename on an application-specific directory). The BSMs may also include file ID or version information on files being broadcast, information on the transport stream where the files can be received (e.g., a flow ID, an IP flow identified by an IP address, and a UDP port number), information on when the file will be broadcast (e.g., a delivery window), information on when the delivery schedule will be updated with new information (i.e., when a new version of the BSM will be transmitted), information on whether the file contains datagram packets, datagram packet IDs, and/or information (e.g., a look-up table) associating applications with either individual datagram packets or datagram packet groups and blobs.
Thus, in various embodiments, the FDF 40 enables application data providers 42, 43 to provide data in the form of datagram packets, such as UDP packets, for transport via the file transport network 41 to receiver devices that selectively receive the files containing those datagram packets requested by device applications 45, 46. The delivery of datagram packets via the file transport network 41 provides many benefits over existing systems, such as improved reliability, battery consumption, and efficiency. The improved reliability is due, in part, to the error correction and transmission properties of the FDF. Battery consumption is improved because the receiver devices can determine, from the BSM, when to “wake up” from a low power state to listen for the desired transmissions. Thus, the receiver devices do not need to wake up periodically, as they know exactly when the desired information is to be broadcast. Further, the receiver devices only “wake up” if they are interested in a particular set of datagram packets being broadcast. Otherwise the receiver devices can remain in a low-power consumption state, thereby significantly improving battery consumption.
Another advantage of delivering datagram packets via the file transport network 41 is that the communication system's overall efficiency may be greatly improved. This is in part due to the inherent efficiencies of the FDF described above. For example, by embedding the datagram packets within files, the forward error correction encoding can be implemented within the FDF for an entire set of datagram packets, as opposed to forward error encoding each datagram packet individually.
In various embodiments, efficiency may further be improved by selectively bundling datagram packets from different source-applications when there is a high probability that a receiver device will be interested in more than one of the sources, i.e., more than one of the datagram packets included within a broadcast file. For example, in one embodiment, UDP datagram packets from similar source applications (e.g., NY Times, Washington Post, etc.) may be bundled together into one or more files. In another embodiment, UDP datagram packets from source-applications targeted to a particular user demographic (e.g. 21-30 year-old males) may be bundled together into one or more files. The logical grouping of UDP datagram packets within files based on anticipated device-application usage, demographics, and/or usage probabilities allows for the creation of files that are likely to contain datagram packets requested by more than one of a device's applications. This results in receiver devices having to “wake-up” less often because information likely to be requested by multiple applications running on a single device are more likely to be contained in a single broadcast file. Since receiver devices must generally receive the entire broadcast file before they can extract the datagram packets requested by applications, the receiver devices incur little or no additional cost when receiving datagram packets for multiple device-applications in the same file. Also, the logical grouping of datagram packets within files based on related device-applications allows for the creation of broadcast files that are likely to contain datagram packets requested by many different receiver devices. For example, while a few users may elect to view the New York Times on their receiver device, many more users are likely to view at least one newspaper publication on their receiver devices. So, bundling newspaper related UDP datagram packets into one or more files may be more efficient in terms of bandwidth utilization than distributing such packets across many different broadcast files.
The file header 51 may include information regarding the file itself (e.g. file length, transmission format), as well as the contents of the file (e.g., sources and locations of datagram packets). The file header 51 may also include additional information that allows the efficient application of forward error correction (FEC) codes. The file header 51 may contain information, such as a lookup-table that cross-references the content sources with IDs 52 located within a file. In some embodiments, the lookup-table may be used to locate the datagram packets originating from specific content sources and/or headend applications. The lookup-table may also allow the file to deliver datagram packets generated from multiple sources to multiple applications on receiver devices. In an embodiment, information about the content sources is conveyed in the form of a character string. In various embodiments, the file header 51 may include the number and location of the datagram packets associated with a particular source. In various embodiments, the file header 51 may also include a unique identification (e.g., a fileID), which can be used for versioning purposes and/or for identifying files bundled together into combined packages for transport via the file transport network 41.
As mentioned above, files transported via the file transport network 41 may be bundled together into combined packages for more efficient transmission and application of forward error correction (FEC) codes.
Each file 50 may be scheduled to be broadcast within a particular broadcast window (BW), such as the illustrated example of broadcast window BWfID
Files that will be broadcast along with their broadcast window and transmission metadata may be described in BSMs 60a, 60b which may be carried by a broadcast schedule flow 60. The broadcast schedule flow (BSF) 60 may be an overhead flow separate from the content flows including the file delivery pipes 62, or may be a portion (e.g., time, frequency or symbol) of a broadcast channel known by receiver devices to carry the BSMs 60a, 60b. In order to enable receiver devices to timely activate their receiver circuitry to receive selected files, the BSM 60a, 60b carrying information regarding files is transmitted in advance of when the files are to be transmitted. In order to enable reliable reception of the BSM, the same BSM may be repeatedly broadcast on a frequent basis, such as every superframe, every second, or every few seconds. Since multiple files may be available and scheduled for over the air transmission, and the schedule may change as new files are submitted for transmission, only a fraction of the scheduled files may be described in a given BSM 60a, 60b. The information included within a given BSM 60a, 60b may thus describe a series of files that will be broadcast within a broadcast schedule period (BSP), which defines the amount of advertised file broadcast schedules included in a BSM. This is illustrated in
It should be noted that
The portions of the broadcast signal carrying the content and information flows may be passed by the MAC layer 704 to a stream layer 706, which is the data interface to the transport layer 710 (which is defined by TIA 1120) in the receiver device. The FLO air interface 708 may also include a control layer 707 for controlling the various operations of the air interface. Broadcast data received in the transport layer 710 may be processed and delivered to the appropriate upper layer modules that can make use of the data, such as the system information module 714, real-time applications 716, file-based applications 718, datagram based applications 720, and IP data cast applications 722.
Software modules of a receiver device 10 may be organized in a software architecture 890 similar to that illustrated in
Overhead data streams may be passed to an overhead data acquisition module 898, which may function to process overhead data packets and direct received metadata and overhead data to appropriate modules within the device system architecture 890. A Service SI acquisition module 897 may acquire the Service SI data from the overhead data streams, and forward this information to the file delivery system module 44 and overhead data acquisition module 898. From received Service SI data, the file delivery system module 44 may determine flow IDs for file data flows carrying datagram packets. From received Service SI data, the overhead data acquisition module 898 may determine signaling flows carrying datagram packets.
An example method 900 for sending datagram packets through the file transport framework is illustrated in
The file constructor may send the constructed files to a file ingestion system, which schedules the generated files for transmission in block 915. In block 920 the file ingestion system may store the received files in a local database and generate BSMs that identify the scheduled files, the datagram packets contained within the scheduled files, and timing information that indicates a time window and/or time range in which the scheduled files are to be broadcast. In block 925, the broadcast system broadcasts the generaged BSMs, such as on a frequent basis (e.g., every superframe, second or few seconds). In block 930, the broadcast system broadcasts the files containing the datagram packets in the time window/range identified in the BSMs.
An example method 1000 for receiving datagram packets transmitted through the file transport framework is illustrated in
The various embodiment methods for receiving and processing interactivity event signaling messages may be performed by the multimedia broadcast receiver 1106 and portions of the processor 1101 and memory 1102. Alternatively dedicated modules within or coupled to the multimedia broadcast receiver 1106 may perform the embodiment methods.
The various embodiments may be implemented on the broadcast side on any of a variety of commercially available server devices, such as the server 2000 illustrated in
The processors 1101, 2001 may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described below. In some mobile receiver devices, multiple processors 2001 may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory 1102, 2002, 2003 before they are accessed and loaded into the processor 1101, 2001. The processor 1101, 2001 may include internal memory sufficient to store the application software instructions.
The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the operations in the foregoing embodiments may be performed in any order. Words such as “then,” “next,” etc. are not intended to limit the order of the operations; these words are simply used to guide the reader through the description of the methods. Although process flow diagrams may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.
The various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
Embodiments implemented in computer software may be implemented in software, firmware, middleware, microcode, hardware description languages, or any combination thereof. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module which may reside on a computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. A non-transitory processor-readable storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such non-transitory processor-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer or processor. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.
When implemented in hardware, the functionality may be implemented within circuitry of a wireless signal processing circuit that may be suitable for use in a wireless receiver or mobile device. Such a wireless signal processing circuit may include circuits for accomplishing the signal measuring and calculating operations described in the various embodiments.
The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.
Any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.
The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.
This application claims the benefit of priority to U.S. Provisional Application No. 61/443,566, entitled “Multicast data delivery mechanism using packet bundling or file delivery framework” filed Feb. 16, 2011, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61443566 | Feb 2011 | US |
