Patent Application
20110228716
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 mobile devices. Mobile multimedia broadcast services allow users to view TV programming, as well as receive mobile editions of news, entertainment, sports, business, and other programming, using their cell phone or other wireless mobile device configured to receive the mobile broadcast transmissions. The bandwidth and capabilities of mobile multimedia broadcast technologies is expected to lead to an expanding user base and an expansion of applications and uses for such systems.
The various embodiments provide methods and systems for combining and transmitting multiple service components in a single media stream within a MediaFLO® multimedia broadcast system. The embodiments enable a single MediaFLO® mediaFLO logical channel (MLC) with a limited number of media streams to carry more service components and therefore allow the media broadcast system to more efficiently use MLCs. A first embodiment of the invention fits multiple service components into the same media stream by multiplexing packets for transmission. On the receiving end, the mobile device can separate the packets within each media stream and assign them to the different service components based upon the flow ID and routing type assigned to each packet. One advantage of this embodiment is that it may be implemented in the existing protocol stack architecture of MediaFLO by relying on the routing type and flow ID values already in use. However, in this embodiment the mobile device may only differentiate different service components within the same media stream if the service components are of different routing types.
A further embodiment may incorporate a new layer in the protocol stack architecture to allow service components of the same type to be multiplexed within the same MLC stream. In this embodiment, the mobile device may differentiate service components of the same routing type based on a component ID contained in a header created by the new protocol layer.
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, personal television devices, personal data assistants (PDA's), palm-top computers, wireless electronic mail receivers (e.g., the Blackberry® and Treo® devices), multimedia Internet enabled cellular telephones (e.g., the Blackberry Storm®), Global Positioning System (GPS) receivers, wireless gaming controllers, and similar personal electronic devices which include a programmable processor and memory and mobile multimedia broadcast receiver circuitry for receiving and processing mobile multimedia 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. Examples of a broadcast message are mobile television service broadcast signals, including content broadcasts (content flow) and overhead flows.
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. Among such services is the MediaFLO® technology that is implemented in FLO TV® by Qualcomm, Incorporated (San Diego, Calif.).
Mobile multimedia broadcast services like MediaFLO® enable mobile receiver devices to be self-contained by broadcasting information about the programs and content that will be broadcast in the future via overhead portions of broadcast transmissions dedicated to carrying information about content flows (referred to herein as an “overhead flow,” “information flow” or “content description flow”), in addition to the broadcast transmissions that carry the content (referred to herein as “content flow”). This information about the content, or “metadata,” enables mobile devices to discover how and when to receive selected content. Mobile devices can also process this metadata to provide users with a program guide, which enables users to select a particular content flow for reception. The program guide enables users to see what programming and content is available, when, and on what “channel” or flow.
A MediaFLO® broadcast network transmits content on a plurality of different “flows,” thereby enabling several different programs to be broadcast simultaneously. MediaFLO® modulates data packets in an orthogonal frequency domain multiplex (OFDM) waveform, carrying the plurality of flows within the same radio frequency band, including the data structures and overhead information that enable receiver devices to select and receive any of the channels or flows. For example, a FLO-based programming lineup that utilizes 30 frames-per-second (fps) QVGA (a Quarter Video Graphics Array or 240×320 pixels) with stereo audio includes 14 real-time streaming video channels of wide-area content (e.g., national content) and 5 real-time streaming video channels of local market-specific content. Individual flows are identified by a flow identifier (flow ID). Information within the content description flow enables receiver devices to determine the particular flow ID to access in order to receive a particular content flow. Content flows will typically include a number of types of data streams, which are referred to as “service components,” including service components carrying video, audio, and sometimes closed captioning. In some cases and implementations, one content flow may include multiple audio streams, such as to provide different language audio programs, and multiple closed captioning streams, such as to support closed captioning in different languages.
Each content flow is carried on one media logical channel (MLC) of the physical layer with the data provided to upper protocol layers which process the data to access a selected content flow and the information flows. MLCs of the physical layer may be carried on one or more sub-carriers of the broadcast signal on certain time slots. In a MediaFLO® broadcast system which uses orthogonal frequency-division multiplexing (OFDM), the broadcast signal may be divided into a large number of orthogonal sub-carriers. OFDM communication technologies and the concept of OFDM sub-carriers are well known in the communication arts.
To provide a power-efficient broadcast system, MediaFLO® receiver devices are organized in terms of an upper layer protocol that works in conjunction with a physical layer protocol. In the upper layer protocol, system information maps content flow (also referred to as media flows) to particular MLCs that are known to the physical layer. Information mapping the flow ID used in the upper layer protocol to particular MLCs may be in the overhead information broadcast by the mobile multimedia broadcast network. Thus, when a user elects to view a particular program and makes the selection on a program guide user interface, the receiver device uses the information received in the overhead flows to determine which MLC(s) to receive and decode.
In order to provide a dynamic and flexible system, broadcasters may dynamically allocate sub-carriers and time slots to MLCs to provide the necessary bandwidth for particular programs and content. Broadcasters then transmit the information mapping sub-carriers and time slots to MLCs in the overhead flows. Since such information is relatively simple and limited, the overhead flows typically consume a minimal portion of the broadcast signal. For example, in MediaFLO, the overhead information service (OIS) is included within the first approximately 10 milliseconds of each one-second superframe.
In a MediaFLO® broadcast network, each MLC can contain up to three streams of data. In practice, one of these streams is limited in data capacity and is therefore used only for carrying overhead information, which leaves two streams for carrying payload data. The media flows of the upper layer protocol are mapped one to one with these physical layer streams. Similarly, a single service component is carried in a single media flow. Therefore, each MLC can only carry two service components. Again, service components include a particular type of service data being broadcast, such as video, audio, and subtitles. Services with more than two components, such as a video with audio and subtitles or video with separate subtitles in different languages, would therefore require use of more than one MLC.
The various embodiments provide methods and systems for transmitting multiple service components in a single MLC stream of a MediaFLO® broadcast transmission, thereby increasing the number of service components that can be carried simultaneously. The embodiments enable a single MLC to carry more service components and allow the media broadcast system to use MLCs efficiently. The benefits of efficiently utilizing the bandwidth in MLC streams includes simplifying MLC allocation to content flows services, and increasing the amount and types of information that may be broadcast within the current broadcast architecture since the total number of MLCs is limited by the available frequency spectrum.
In a first embodiment the transmission and reception of data through MLCs is modified to enable two or more different types of service components to be transmitted at the same time in the same MLC stream. In this embodiment, data packets from the different service components on the same MLC stream are recognized by receiver devices based upon their different routing type information (which is a data field in the data packet header which identifies the type of data—video, audio, text, etc.—included in the packet). This embodiment enables broadcasters to fit multiple service components into the same MLC stream. On the receiving end, a mobile device can separate the data packets from one MLC stream and assign them to the different service components within their corresponding services based upon the flow ID and routing type data included in each packet header. One advantage of this embodiment is that it may be implemented in the existing protocol stack architecture of MediaFLO® by relying on the routing type and flow ID values already included in broadcast data packets. Thus, this embodiment may be implemented within existing broadcast networks and receiver devices, with just a simple software upgrade to add the functionality described in more detail below.
However, the first embodiment only enables multiplexing of different types of data (i.e., different routing types) in the same MLC stream. In some implementations, this limitation may be undesirable, such as when broadcasters wish to transmit multiple languages of either audio or subtitles for the same content flow. For example, it might be desirable to broadcast a single program with Japanese, Chinese, and Korean audio tracks as well as English, Spanish and Thai subtitles. Since the Japanese, Chinese, and Korean audio tracks would have the same routing type (i.e., audio), and the English, Spanish and Thai subtitles would have the same routing type, the first embodiment may require more MLC streams to carry all of this content simultaneously.
An improvement in a second embodiment adds a new logic layer to the MediaFLO® protocol stack to identify different service components that may be included within the same MLC stream based on a component identifier added to the packet header. This embodiment allows service components of the same type to be multiplexed within the same MLC stream. In this embodiment, data packet headers include a component ID field that a component layer in receiver devices can use to properly route service components to their appropriate application. An overhead flow data field may also be used to inform receiver devices when multiple different service components are being broadcast on a particular MLC stream. This embodiment requires a modification to the MediaFLO® architecture to add the service component layer to both broadcaster and receiver device protocol stacks. However, it adds greater flexibility for maximizing the use of the bandwidth available in the broadcast signal without having to increase the number of MLCs.
The various embodiments may be implemented within a MediaFLO® broadcast system which is illustrated in
The content manager server 106 may combine the scheduled broadcast time and address with the other information regarding the content (such as the associated MLCs for each content flow) to generate content packet descriptions (CPDs) which will be broadcast in one or more information flows. When content is scheduled for broadcast, the content manager server 106 may provide the content packages to the content broadcast system 104 in an internal network dataflow 202, along with the content package descriptions in an internal network dataflow 204.
The content flows 202 and information flows 204 are processed by the content broadcast system 104 to allocate the data packets to the MLCs and generate the multiplex broadcast waveform which is broadcast by the network transmitters 102 as broadcast transmissions 113.
In order to fit the broadcast content within the available bandwidth, the broadcast system allocates each of the various content flows into MLCs which are defined in the multiplex broadcast signal. In order to enable receiver devices to determine the MLC corresponding to particular content flow numbers, the broadcast signal also includes an overhead information service (OIS) flow of overhead data, as well as other overhead flows, which provides receiver devices with the control information required to receive selected broadcast content flows. The content flows, information flows and OIS are encoded within the multiplex broadcast signal that may include several different content flows (CF) 206 which are data packets carrying the broadcast content, one or more information flows (IF) 208 which include data packets carrying the content packet descriptions, and the OIS flow 209 which provides information that the receiver device needs to receive the content and information flows 206, 208. Receiver devices 110 receive the broadcast transmissions and are able to separately process content flow 206 and the content description flow 208 using the information provided in the OIS 209 and other overhead flows.
The portions of the broadcast signal carrying the content and information flows may be passed by the MAC layer 304 to a stream layer 306 which is the data interface to the transport layer 310 (which is defined by TIA 1120) in the receiver device. The FLO air interface 308 may also include a control layer 307 for controlling the various operations of the air interface. Broadcast data received in the transport layer 310 may be processed by a media adaptation layer 312 (defined by TIA 1130) which functions to deliver data packets to the appropriate upper layer modules that can make use of the data, such as the system information module 314, real-time applications 316, file-based applications 318, and IP data cast applications 320.
As mentioned above, in a first embodiment, the routing type field is used to enable differentiating of different service components within a single MLC stream by imposing the requirement that only service components of different routing types can be included in the same MLC stream. Thus, in this embodiment, data packets belonging to different service components sharing one MLC stream will be of different media types. As illustrated in
As
An example embodiment method 400 for multiplexing several service components into a single media flow from the broadcast end is illustrated in
In step 404, the service components carried over the same MLC stream are logically grouped into a content flow and assigned the same flow ID in the flow record of the system information.
The identified service components are then processed in the normal manner for broadcast, including dividing the service component data into many discrete data packets in step 406. These data packets may be combined with a media adaptation layer header in step 408. The data packets' media adaptation layer header includes the flow ID, a media type field (which specifies the type of data included in the packet based upon the system information routing type), a media common header, and a media specific header. Media adaptation layer headers include sync layer headers (illustrated in
With the data packets assembled, data packets from the selected two or more service components of different routing types may be assembled into the same MLC stream in step 410, and broadcast in step 411.
An embodiment method 500 for processing data packets received from MLC streams which have been multiplexed as described above is illustrated in
While receiver devices may detect the presence of multiplexed service components on an MLC stream by detecting different media type values in the packet headers, information may be included in MediaFLO® system information to alert mobile devices that certain MLC streams are multiplexed. In this embodiment, mobile devices may not test the media type value of all data packets unless the received system information indicates that a particular MLC is multiplexed.
The embodiments described above with reference to
Another embodiment can overcome the restriction on media types of multiplexed service components by adding a new architecture layer for handling service components according to a service component header added to the data packets. In this embodiment, the service component header information can enable multiple different service components of the same media type to be broadcast on the same MLC stream and properly routed to the appropriate service component processing module in receiver devices.
A protocol stack diagram of this embodiment is illustrated in
Example characteristics for the component identifier within the component packet header are illustrated in
Component information may be included in the system information as illustrated in the data schema 600 illustrated in
An example method 700 for broadcasting multiple service components within a single MLC stream according to the another embodiment is illustrated in
The identified service components are then processed for broadcast, including dividing the service component data into many discrete data packets in step 406. These data packets may be combined with a flow multiplexing layer header in step 708. The flow multiplexing layer header can include the component ID assigned to the data packet's service component or an equivalent data element. The data packets are then multiplexed in step 410, and broadcast in step 411.
An embodiment method 800 for processing data packets received from MLC streams which have been multiplexed and labeled with a component header as described above is illustrated
The processing of received data packets in a mobile device may be performed by a receiver circuit coupled to a processor or in a receiver circuit that includes processor logic configured to perform the operations described above with reference to
Typical mobile devices 110 suitable for use with the various embodiments will likely have in common the components illustrated in
The processor 901 may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (e.g., applications) to perform a variety of functions, including the functions of the various embodiments described herein. In some mobile devices, multiple processors 901 may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. In some mobile devices, the various embodiments operations described above may be performed by a processor that is included within the MediaFLO® mobile multimedia broadcast receiver 908. Typically, software applications may be stored in the internal memory 902 before they are accessed and loaded into the processor 901. In some mobile devices, the processor 901 may include internal memory sufficient to store the application software instructions. In some mobile devices, the secure memory may be in a separate memory chip coupled to the processor 901. In many mobile devices 110, the internal memory 902 may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to all memory accessible by the processor 901, including internal memory 902, removable memory plugged into the mobile device, and memory within the processor 901 itself.
A number of the embodiments described above may also be implemented with any of a variety of commercially available remote server devices, such as the server 1000 illustrated in
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 steps of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of steps in the foregoing embodiments may be performed in any order. Words such as “thereafter,” “then,” “next,” etc., are not intended to limit the order of the steps; these words are simply used to guide the reader through the description of the methods. Further, 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 various illustrative logical blocks, modules, circuits, and algorithm steps 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 steps 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.
The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments 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 steps or methods may be performed by circuitry that is specific to a given function.
In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof If implemented in software, the functions may be stored on as one or more instructions or code on a tangible processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module executed which may reside on a tangible, non-transitory processor-readable storage medium. A tangible, non-transitory processor-readable storage medium may be any available storage media that may be accessed by a computer. By way of example, and not limitation, such tangible, non-transitory processor-readable storage 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 carry or store desired program code in the form of instructions or data structures and that may be accessed by a processor. Optical disk storage includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and blu-ray disc. Combinations of the above should also be included within the scope of tangible, non-transitory processor-readable storage media. Additionally, the operations of a method or algorithm residing as one or any combination or set of codes and/or instructions on a tangible, non-transitory processor-readable storage medium may be incorporated into a computer program product.
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.
