Patent Application
20120216230
Communication networks, such as a digital broadband broadcast network, enable end users to receive digital content including video, audio, data, and so forth. Using an electronic device, a user may receive digital content over a communication network, such as a wireless digital broadcast network. An electronic device, such as a mobile device, may receive a program or service in a data or transport stream. The transport stream carries individual elements of the program or service such as the audio and video components of the program or service. In some systems, the electronic device locates the different components of a particular program or service in a data stream through Program Specific Information (PSI) or Service Information (SI) embedded in the data stream. However, PSI or SI signaling may be insufficient in some wireless communications systems, such as Digital Video Broadcasting—Handheld (DVB-H) systems. Use of PSI or SI signaling in such systems requires a large amount of bandwidth which is costly, decreases efficiency of the system, and may result in a sub-optimal end user experience
Digital content can be transmitted in a cell within a network. A cell may represent a geographical area that may be covered by a transmitter in a communication network. A network may have multiple cells and cells may be adjacent to other cells. When a device moves between cells, a handover procedure may be initiated. Performing a handover may allow for an electronic device to continue receiving services or programs from the communication network. The processing that occurs during a handover, such as the discovery of services in the neighboring cell, may decrease the efficiency of the system and may result in a sub-optimal end user experience.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
In some embodiments, apparatuses may perform, and methods may include, communicating through a network upper level signaling information (ULI) and layer 2 signaling information for a broadcast protocol in a real-time transport protocol (RTP) data stream. The broadcast protocol may be a Digital Video Broadcast Next Generation Handheld (DVB-NGH) protocol. The layer 2 signaling information may include local multiplex information (LMI) used for receiving DVB-NGH services within a local cell of the network, and other multiplex information (OMI) used for signal handoff when a receiver is tuning from one signal to another signal or moving from the local cell to an adjacent cell within the network.
In some embodiments, headers within an RTP data stream may include fields for identifying the upper level information, local multiplex information, and other multiplex information encapsulated in the RTP data stream. In one embodiment, the RTP header includes a payload type field that includes a value for uniquely identifying which type of signaling information (e.g., ULI, LMI, OMI) is contained in the RTP data stream. The RTP data stream may further include a payload data field for encapsulating the signaling information.
In various embodiments, an RTP header may include a timestamp field that includes a value indicating a time frame of when the encapsulated signaling data is valid. In further embodiments, the RTP header may include a sequence number field that includes a value uniquely identifying each of a plurality of sections of the type of signaling information indicated by the payload type field. In yet another variation, the RTP header may include a marker field that includes a value indicating that the payload data field includes the last section of one or more sections of the type of signaling information indicated in the payload type field.
Certain embodiments are illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which are 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 of the present invention.
As seen in
Although shown as a single network in
Devices 105-120 may be configured to interact with each other or other devices, such as content provider/server 130 or service provider 125. In one example, mobile device 110 may include client software 165 that is configured to coordinate the transmission and reception of information to and from content provider/server 130. In one arrangement, client software 165 may include application or server specific protocols for requesting and receiving content from content provider/server 130. For example, client software 165 may comprise a Web browser or mobile variants thereof and content provider/server 130 may comprise a web server. Billing services (not shown) may also be included to charge access or data fees for services rendered. In one arrangement where service provider 125 provides cellular and/or wireless network access, client software 165 may include instructions for access and communication through the cellular and/or wireless network. Client software 165 may be stored in computer-readable memory 160 such as read only, random access memory, writeable and rewriteable media and removable media in device 110 and may include instructions that cause one or more components—for example, processor 155, a transceiver, and a display—of device 110 to perform various functions and methods including those described herein.
A communication system may be comprised of a plurality of different cells.
Computer executable instructions and data used by processor 228 and other components of device 212 may be stored in a storage facility such as memory 234 and/or in hardware logic in an integrated circuit, ASIC, etc. Memory 234 may comprise any type or combination of read only memory (ROM) modules or random access memory (RAM) modules, including both volatile and nonvolatile memory such as disks. Software 240 may be stored within memory 234 to provide instructions to processor 228 such that when the instructions are executed, processor 228, device 212 and/or other components of device 212 are caused to perform various functions or methods such as those described herein. Software may include both applications and operating system software, and may include code segments, instructions, applets, pre-compiled code, compiled code, computer programs, program modules, engines, program logic, and combinations thereof. Computer executable instructions and data may further be stored on computer readable media including electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, DVD or other optical disk storage, magnetic cassettes, magnetic tape, magnetic storage and the like.
Device 212 or its various components may mobile and be configured to receive, decode and process various types of transmissions including digital broadband broadcast transmissions that are based, for example, on the Digital Video Broadcast (DVB) standard, such as DVB-NGH, DVB-H, DVB-T2, DVB-H+ (hybrid satellite/terrestrial architecture), or Digital Video Broadcasting—Multimedia Home Platform (DVB-MHP), through a specific broadcast transceiver 241. Other digital transmission formats may alternatively be used to deliver content and information regarding availability of supplemental services. Additionally or alternatively, device 212 may be configured to receive, decode and process transmissions through various transceivers, such as FM/AM Radio transceiver 242, wireless local area network (WLAN) transceiver 243, and telecommunications transceiver 244.
Although the above description of
Some digital video broadcasting protocols provide signaling information to allow for the discovery and reception of services and other data at an electronic device (e.g., device 212 of
Audio/Video (AV) content is another example of component transmission. For scalable video coding, a service may include an audio component, a base layer video component, and an enhancement layer video component. The base layer video component may have lower resolution than the enhancement layer video component. The AV components of each service might not be shared with other services, and may be sufficiently synchronous with each other to avoid problems at a receiver. Example embodiments permit transmission of multiple service components within the same PLP or different PLPs, as well as with different robustness levels for the components.
According to some digital video broadcasting protocols, components that make up a particular service like a content program or an interactive function are mapped to one or more PLPs. A physical layer, as used herein, generally refers to a portion of a network protocol that is configured to define hardware-specific operations for effecting the transmission or reception of electronic signals over a data network. The physical layer is configured to facilitate the transmission of raw bits from a source to a destination. The physical layer may be configured to specify frequencies, voltages, bit rates and the like for transmission of data. The Open Systems Interconnection (OSI) Reference Model, for example, provides for a layered communication architecture including a physical layer (L1).
A PLP generally refers to a transmission channel between a source and a destination node defined at the physical layer. The physical layer may define multiple channels—pipes—through which raw bits representative of the data such as broadcast data may be sent. For example, different broadcast services and data associated therewith may be mapped to different physical layer pipes through which the data is transmitted. Accordingly, the physical layer may be configured to identify the appropriate transmission channel for a series of bits corresponding to a particular service and transmit the data through the identified channel or pipe. In a broadcast arrangement, a PLP may be established between a source and multiple destinations. In one example, a PLP may correspond to a physical layer multiplexed channel (i.e., a multiplex) that is carried by specified slices of a transmission stream (e.g., a DVB-T2 stream, which uses time-division multiplexing). When an end-user device wishes to access a component of a particular service, the end-user device may identify the corresponding PLP or PLPs from which to access the service data. In the broadcast scenario, a receiving device may listen for the particular PLP or PLPs carrying the desired service or services.
PLPs corresponding to components of a single service may be identified by combining PLPs into a logical grouping—into a link layer pipe—that is associated with a service. LLPs generally refer to logical associations such as mappings that link a service or service components to a PLP. The logical associations may also include indications of the type of the PLPs associated with the services or the service components. These association types may for example refer to the content transmitted in a particular PLP, or the location of the PLP with respect to other PLPs. For example, association type could indicate that a particular PLP is an anchor PLP. Such anchor PLPs may carry the most important data related to a particular service. LLPs may be defined using various data structures such as tables, lists and the like. PLPs may be identified for accessing components of a service by determining the logical grouping or LLP associated with that service and examining PLP parameters specified thereby. In one example, an LLP may be identified in a service descriptor configured to advertise available services to network devices, such as mobile phones, computers and set-top boxes. LLP identification information may be carried in a packet header of the broadcast transmission stream. Alternatively or additionally, LLP information, (e.g., example LLP identifiers) for each service may be specified in electronic service guide data or layer 2 signaling. Thus, upon receiving the packet header and/or electronic service guide data, a receiving device such as cell phone may extract LLP information to identify components of a service and their associated PLPs.
An LLP may comprise multiple frames, which may be used to allow for the fair division of resources in a broadcast transmission stream. Accordingly, a first frame of an LLP may be transmitted at time T1, while a second frame may be transmitted at time T2 and a third frame may be transmitted at time T3. The interval between the transmission of each frame in an LLP may be defined by a parameter (e.g., TINT
Grouped PLPs for a particular LLP may be defined by specified slots or slices and packet sizes in a transmission stream. For example, a first PLP for an LLP might be defined as occupying the 1st, 5th, and 9th slices in a payload portion of a T2 frame. PLPs may occupy different numbers of available slots or slices; for example, a PLP may be twice as large as another PLP and, therefore may occupy twice the number of available slots. A remainder of a T2 frame may be apportioned to header data and other LLP frames of other services.
In addition, an Electronic Service Guide (ESG) 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 may encompass 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.
ESG information, such as an ESG table, may include information on one or more services. The services may be Open Mobile Alliance Mobile Broadcast (OMA BCAST) services that may include one or more Internet Protocol (IP) streams and/or User Datagram Protocol (UDP) streams to transport components. Each service included in the ESG information may have a Global service identifier, which may be a unique identifier of the service. Each service may be associated with one or more components that may respectively transport audio, video, text, etc. Each component may be associated with a uniform resource identifier (URI) to identify information corresponding to the components of the desired service from service association information. In one example, using ESG information, service association information, and local multiplex information, a receiving device may identify a particular PLP carrying a component of a desired service. The details of this example will be described below. ESG information may be received via any type of bearer (for example, application, point-to-point, broadcast, etc.).
As illustrated in
In embodiments utilizing the example protocol stack illustrated in
In various embodiments, the protocol stack of
With respect to the upper layer information (ULI) of the illustrated example protocol stacks (e.g., ULI 403-a of
As illustrated in
Referring to the information included within the service_association section 503, a section_length parameter may be a field (e.g., a 32 bit field) that indicates the length of the service association section and a number_of_services parameter may be a field (e.g., a 8 bit field) indicating the number of services delivered through the current channel (i.e., multiplex). The number_of_services may be used for indicating the number of iterations for the loop that is located in the example service_association section 503 between number_of_services and CRC 32.
Each service may include one or more components, and the number_of_components parameter may be a field (e.g., 8-bit field) used to indicate the number of components delivered through the corresponding service in that service loop. The number_of_components parameter may be used for indicating the number of iterations for the loop that is located in the example service_association section 503 between number_of_components and LLP_ID.
For each component of each service, a resource length parameter (e.g., URI_length) may be a field (e.g., 8 bit field) used for indicating the length of the URI for that service/component. The URI_length may be used to indicate the number of iterations for the loop that is located in the example service_association section 503 between URI_length and context_id, for retrieving the URI_byte or (IP_address:port) parameter(s).
The URI_byte or (IP_address:port) parameter(s) may be a string of one or more bytes (e.g., text bytes), which indicate the URI or number sequence (e.g., IPv4/IPv6 address and port number) for locating the service/component of that particular loop iteration.
In addition to the URI location identifier string, a number of other parameters are provided for each service/component to support RoHC decompression. These may include a context_id parameter indicating the context id of the RoHC compressed IP stream, the context_profile parameter indicating context profile of the compressed IP stream, the static_info_length parameter indicating the length of the static chain byte sequence, and the static_chain_byte parameter, which may be a byte sequence indicating the static information of the compressed IP stream.
For each component of each service, a PLP_ID parameter may be a field (e.g., 8 bit field) identifying uniquely the physical layer pipe through which the corresponding component is delivered. Similarly, for each service, a LLP_ID parameter may be a field (e.g., 16-bit field) identifying uniquely one logical layer pipe within network for the corresponding service.
A cyclic redundancy check (CRC) parameter (e.g., CRC—32) may contain a CRC value for performing a redundancy check. In one example, CRC—32 may be a 32-bit field that contains the value that gives a zero output of the registers in the CRC decoder.
With respect to the L2 signaling data for a broadcast protocol of the illustrated example protocol stacks (e.g., DVB-NGH), the L2 signaling data can include data related to local multiplex information and other multiplex information. The L2 signaling data may include information that maps between services and multiplex information. In some embodiments, the included information may be similar to the information of PSI/SI signaling. Traditionally, PSI/SI signaling is carried with OSI Layer 2 information. In contrast to PSI/SI signaling, in some embodiments, the L2 signaling data may be carried within OSI layer 3 (e.g., on top of the IP layer), or within OSI layers 4 and above (e.g., on top of the RTP layer).
Referring to the information included within the LMI section 603, a section length parameter (e.g., section_length) may be used for indicating a length of the sub-section that is located in the example LMI section 603 between section_length and CRC—32. In one example, section_length may indicate the number of LLPs, which is the number of iterations, N, of the loop following the section_length parameter. In another example, section_length may indicate the entire length of the section, including all possible loops.
A LLP identifier parameter (e.g., LLP_ID) may be used to identify each LLP. In one example, each LLP has a corresponding LLP_ID.
A time interval parameter (e.g., T_INT_LLPF) may be used to indicate the time between LLP frames in a transmission (e.g., milliseconds, OFDM symbols).
A maximum size parameter (e.g., BS_LLPF) may be used to indicate the size of the largest frame within an LLP.
A PLP loop length parameter (e.g., PLP_loop_length) may be used for indicating the number of iterations of the loop that is located in the example LMI section 603 beginning after PLP_loop_length.
A PLP identifier parameter (e.g., PLP_ID) may be used to identify each PLP grouped within the LLP of that LLP_ID iteration. In one example, each PLP has a corresponding PLP_ID.
A cyclic redundancy check (CRC) parameter (e.g., CRC—32) may contain a CRC value for performing a redundancy check. In one example, CRC—32 may be a 32-bit field that contains the value that gives a zero output of the registers in the CRC decoder.
Referring to the information included within the OMI section 653, a section length parameter (e.g., section_length) may be used for indicating a length of the sub-section that is located in the example OMI section 653 between section_length and CRC—32. In one example, section_length may indicate the number of neighboring networks, which may be the number of iterations of the loop following the section_length parameter. In another example, section_length may indicate the entire length of the section, including all possible loops.
A network identifier (e.g., network_id) may be used for uniquely identifying a network, such as a network associated with a neighboring cell.
A number of multiplexes parameter (e.g., n_of_multiplexes) may be used for indicating the number of iterations for the loop that is located in the example OMI section 653 beginning after n_of_multiplexes. In one example, n_of_multiplexes is dependent on the number of multiplexes (e.g., signals) available.
A frequency field (e.g., frequency) may be used for indicating a frequency of the signal carrying the associated multiplex for that iteration of the loop. The associated multiplex may be in a signal covering an area of the neighboring cell. The indicated frequency may be the channel center frequency.
A guard interval field (e.g., GUARD_INTERVAL) may be used for indicating the guard interval of the current super-frame of the associated multiplex (e.g., signal).
A fast Fourier transfer (FFT) size parameter (e.g., FFT_SIZE) may be used for indicating the FFT size (e.g., 2K, 8K, etc.) of the current frame type in the associated multiplex. The multiplex may include also other types of frames, for example, future extension frames, which may have a different FFT size.
A pilot pattern parameter (e.g., PILOT_PATTERN) may be used for indicating the pilot pattern of the signal. In one example, PILOT_PATTERN indicates the scattered pilot pattern used for the data Orthogonal Frequency Division Multiplexing (OFDM) symbols of the associated multiplex.
A cell identifier (e.g., cell_id) may be used for identifying a cell. In one example, each cell may be unique within one network.
A frame offset parameter (e.g., frame_synch_offset) may be used for indicating the frame offset between the physical layer frame transmitted within the current multiplex (e.g., the multiplex the receiving device is currently receiving) and the physical layer transmitted within the associated multiplex (e.g., a multiplex of the neighboring cell).
For each associated multiplex, a parameter indicating a number of services/components for that multiplex (e.g., n_components) may used to indicate the number of iterations for the loop following n_components. For each service/component within the loop, an identification parameter (e.g., COMPONENT_ID) may be used for providing an indexed identification for services/components within the current and neighboring multiplexes. The COMPONENT_ID may be unique in each multiplex, and thus may be reused for identifying the current and adjacent services/components. Using COMPONENT_ID may advantageously reduce the needed signaling capacity, since a COMPONENT_ID may be shorter than the corresponding unique resource identifier. For each service/component, a LLP and PLP are identified with LLP_ID and PLP_ID.
The RTP header data structure may include a version field (e.g. 2 bit Version) which indicates the version of the RTP protocol. The version may for example be version 2 as defined in RFC3350. A padding field (e.g., 1 bit P) may follow the version field and be used to indicate if there are extra padding bytes at the end of the RTP packet. Padding may be used to fill up a block of certain size, for example as required by an encryption algorithm. Following the padding field, an extension field (e.g., 1 bit X) may indicate presence of an extension header between standard header and payload data. This is application or profile specific. A contributing source ID count field (e.g., 4 bit CC) may be included, which contains the number of CSRC identifiers (described below) that follow the header. A marker field (e.g., 1 bit M) may be used at the application level and defined by a profile. If it is set, it means that the current data has some special relevance for the application. A payload type field (e.g., 7 bit PT) may indicate the format of the payload and determine its interpretation by the application. This is specified by an RTP profile (e.g., RTP Profile for audio and video conferences with minimal control (RFC 3551)). A sequence number field (e.g., 16 bit Sequence Number) may typically be included and incremented by one for each RTP data packet sent and may to be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number may be random to make known-plaintext attacks on encryption more difficult. In this example, the timestamp field is used as discussed below. A timestamp (e.g., 32 bit Timestamp) may be included, which enables the receiver, when used for multimedia content, to play back the received samples at appropriate intervals. In this example, the timestamp is used as discussed below. A synchronization source identifier (e.g., 32-bit SSRC identifier) and contributing source identifiers (e.g., 32 bit CSRC identifier) may be included to uniquely identify the source of a stream and to enumerate contributing sources to a stream, which has been generated from multiple sources. Optionally, the header may further include an extension header, which may include a profile-specific identifier (e.g., 16 bit Profile specific extension header ID), a length specifier (e.g. 16 bit Extension header length), and additional 32 bit units.
In one variation, the circled RTP header fields in
One advantage of using the RTP layer to encapsulate the signaling data is that multiple sections of signaling data (i.e., multiple ULIs, LMIs, and OMIs) may be carried in the broadcast signal and distinguished by a receiver, which receives the broadcast signal. When more than one section of a certain type of signaling data is transmitted, the sequence number field in the RTP header (e.g., Sequence Number) may identify each of multiple sections of a particular type of signaling data (e.g., of ULI, LMI or OMI) with a unique section number. This field may be unique per each PT type and may be reset within the start of each new set of ULI, LMI or OMI sections.
When transmitting a set of ULI, LMI, or OMI sections, the marker field, M, may be set or cleared to indicate the last section of the set. For example, the marker field, when set, may indicate the last section of multiple ULI sections.
In certain variations, the timestamp field (e.g., Timestamp) may indicate a time period when the encapsulated signaling data is valid. In one embodiment, the field indicates the starting time when the signaling data is valid. In another embodiment, the field indicates the expiration time when the validity of the signaling data ends.
The ULI, LMI or OMI data may be contained within the RTP payload, and the length of the data may be fixed or it may be detected from the UDP payload length fields below the RTP layer.
Whether the upper level signaling data is within the IP layer as shown in
At step 706, the ULI may be extracted from the PLP carrying the ULI. In some instances, this can include separating the ULI from the additional signaling information included in the PLP carrying the ULI. Additionally, when the ULI is carried within the Internet Protocol layer (e.g.,
At step 708, one or more services (e.g., the one or more desired services) may be selected. In one example, a service may be selected (e.g., by a user of the receiving device via a user interface or autonomously by an application executed by the receiving device). A service identifier (e.g., a URI) for the selected service may then be discovered. For example, a receiver may analyze ESG information, such as an ESG table, stored at the receiver to identify a URI for a desired service.
At step 710, service mapping information for the selected one or more services may be determined from the upper level information. For example, the upper level information (e.g., the service_association section 503 of
At step 712, the determined mapping information (e.g., the component parameters determined in step 710) may be stored (e.g., in a memory of the receiving device) for later access.
Upon retrieving and/or storing the service mapping information, the receiving device may continue processing the signaling data by performing the example process illustrated in
At step 806, the LMI may be extracted from the PLP carrying the LMI. Similar to extraction of the ULI, in some instances, this can include separating the LMI from the additional signaling information included in the PLP carrying the LMI (e.g., separating the LMI from the ULI). Additionally, extracting the LMI may include decapsulating the LMI from IP packets and/or decoding the LMI. As also similar to the ULI, in some embodiments, the LMI may be provided using dedicated IP addresses and ports. Alternatively, the IP address and port of the LMI may be provided within dedicated bootstrap information. Alternatively or additionally, the LMI may be provided with a dedicated PT type in an RTP frame. In some examples, such bootstrap information may be located at the beginning of the PLP carrying the LMI.
At step 808, location information may be determined from the extracted LMI section. For example, for each LLP_ID found in the last step of
At step 810, the location of one or more PLPs is determined based on the location multiplex information and L1 signaling. For example, the location multiplex information (e.g., the buffer information and PLP identifiers) and the L1 signaling (e.g., the L1 signaling extracted and stored in method illustrated by
The receiving device may require a handover to be performed. In one example, the receiving device may initiate a handover from a first cell to a second cell. The receiver may attempt to continue receiving and/or consuming the desired service(s) currently being received and/or consumed by the receiving device. A handover procedure, in some embodiments, may include using information included in the other multiplex information (e.g., OMI 653 of
At step 906, the OMI may be extracted from the PLP carrying the OMI. Similar to extraction of the ULI and/or the LMI, in some instances, this can include separating the OMI from the additional signaling information included in the PLP carrying the OMI (e.g., separating the OMI from the ULI, LMI and/or other OMIs). Additionally, extracting the OMI may include decapsulating the OMI from IP packets and/or decoding the OMI. Similar to the ULI and/or LMI described above, in some embodiments, the OMI may be provided using dedicated IP addresses and ports. Alternatively, the IP address and port of the OMI may be provided within dedicated bootstrap information. Alternatively or additionally, the OMI may be provided with a dedicated PT type in an RTP frame. In some examples, such bootstrap information may be located at the beginning of the PLP carrying the OMI. In some embodiments, the OMI (e.g., OMI section 653 of
In
In step 1202, after the PLP has been received and the IP frame containing the ULI, LMI or OMI data identified through bootstrap or other information as described above, the UDP packets are decapsulated from the IP layer payload, and the RTP packets are decapsulated from the UDP payload. In step 1204, the RTP data stream is parsed and the RTP header(s) are inspected for signaling identification information as described above with respect to
Once the relevant RTP header data is parsed, the payload type field, PT, is inspected in step 1206 to determine whether a ULI, LMI or OMI payload type is found. The RTP header may be inspected for all types of signaling types, or less than all signaling types. For example, step 1206 may inspect the payload type field for only the ULI payload type.
If the ULI, LMI, or OMI payload type is not found, 1204 is repeated to inspect the next received and/or stored RTP header. If a ULI, LMI or OMI payload type is found, the M and/or sequence number fields are inspected in steps 1208 and 1210. An M bit of a predetermined value (e.g., ‘1’) may indicate the ULI, LMI, or OMI in the RTP payload is the last section of one or more sections of that particular payload type. The section number provides a unique identifier (starting at ‘0’ in this example) for each section of multiple sections of a particular payload type. In steps 1208 and 1210, if M is ‘1’ and the sequence number is ‘0’, then the RTP contains the only section of that particular payload type, and step 1212 is performed. Step 1212 decapsulates the ULI, LMI, or OMI signaling data from the RTP payload, decodes the signaling data, and optionally stores the signaling data in a memory.
If in steps 1208 and 1210, the M bit is ‘0’, then there is more than one section of the same payload type and there may be more sections to retrieve. Similarly, if the M bit is ‘1 ’, indicating that the RTP payload contains the last section, but the section number is not ‘0’, than there may be more sections to retrieve. In either situation, step 1214 is performed to determine if there are any more RTP headers to inspect. If there are uninspected RTP headers, step 1204 is repeated. If all RTP headers have been inspected, than step 1212 is executed to complete the decoding of the signaling data (e.g., ULI, LMI, and OMI).
In certain variations, the steps of
At step 1004, a handover has been initiated and the OMI may be compared to handover criteria. The OMI may list one or more (e.g., some or all) components carried within the current multiplex (e.g., the multiplex, or signal, the receiving device is currently tuned to) and/or other multiplexes (e.g., the multiplexes not currently tuned to, but available to the device, such as multiplexes of neighboring cells or other multiplexes of the current cell). In one example, each multiplex may be included in the OMI and may have a respective list of components that are carried within the multiplex. Components listed in the OMI may use the same component identifiers as the component identifiers found in the ULI and/or the LMI (e.g., COMPONENT_IDs).
In some embodiments, the handover criteria may be one or more services currently being received and/or consumed by the receiving device. Additionally and/or alternatively, the handover criteria may include one or more services recently received and/or consumed by the receiving device, and/or may include one or more services predicted to be received and/or consumed by the receiving device (e.g., a prediction based on reception and/or consumption habits of a user at the receiving device). These services may be represented in the handover criteria by their component identifiers. Comparing the OMI to the handover criteria may include identifying one or more multiplexes of the OMI that include a listing of component identifiers that match the component identifiers of the handover criteria. In one instance, one or more multiplexes of the OMI may be identified by the comparison against handover criteria representing the services currently being received and/or consumed by the receiving device. In this instance, these identified multiplexes carry the services currently being received and/or consumed by the receiving device.
In some embodiments, the comparison may compare the handover criteria to every multiplex included in the OMI. In others, the comparison may compare the handover criteria until a first matching multiplex is identified in the OMI. In yet others, the comparison may compare the handover criteria until a threshold number (e.g., 2, 3, 4, etc.) of matching multiplexes are identified in the OMI. Additionally, the information for the identified matching multiplexes may be extracted from the OMI and/or stored for later access. For example, referring to the OMI section 653 of
Referring again to
At step 1006, the handover to an available handover candidate multiplex is performed. The handover may include selecting a handover multiplex from the available handover candidate multiplexes and starting reception of the handover multiplex. In some instances, the handover multiplex may be a different frequency than the current multiplex. Selecting the handover multiplex may be performed in various ways, including, for example: selecting the first available candidate multiplex; selecting based on multiplex priority (e.g., multiplexes having certain parameter and/or identifier values, such as network identifier and/or cell identifier, may be given priority over other multiplexes having different parameter/identifier values); and/or selecting based on other criteria (e.g., signal strength of the available multiplexes). The handover may be performed using the information of the selected handover multiplex that was extracted from the OMI (e.g., the parameters and/or identifiers extracted from OMI section 653 of
At step 1008, upon reception of a signal of the handover multiplex, the L1 signaling is located. The L1 signaling may then be extracted for use by the receiving device. In conjunction with the information for the handover multiplex extracted from the OMI (e.g., component identifiers, PLP identifiers, LLP identifiers, etc.), the L1 signaling may provide the receiving device the information needed locate and extract information from PLPs carrying the data for the desired services. In some embodiments, the receiving device may proceed immediately with locating and extracting information from the PLPs carrying the data for the desired services so that the receiving device may continue receiving and/or consuming the desired services. For example, there may be no need to locate and process ULI and LMI information (e.g., the example methods illustrated in
At step 1010, reception of the desired services may be continued by extracting data from one or more PLPs of the desired service from the received signal of the handover multiplex. Extracting the data may include locating the one or more PLPs using the L1 signaling located in step 1008 and the information of the handover multiplex extracted from the OMI. For example, the one or more PLPs may be located (e.g., the physical location of the one or more PLPs may be determined) based on the L1 signaling, the component identifiers of the handover multiplex, the PLP identifiers of the handover multiplex, and/or the LLP identifiers of the handover multiplex.
At step 1108, other multiplex information may be generated that includes information related to one or more available multiplexes (e.g., information represented by the structure of OMI section 653 of
At step 1110, upper layer information is generated that associates a uniform resource identifier with one or more component identifiers (e.g., information represented by the structure of service_association section 503 of
Any of the method steps, operations, procedures or functions described herein may be implemented using one or more processors and/or one or more memory in combination with executable instructions that cause the processors and other components to perform the method steps, procedures or functions. For example, service provider 125, content provider/server 130, digital content sources 104, digital broadcast transmitter 103, antenna 101, and client devices (e.g., devices 105, 110, 115, 120, and 112) may each include one or more processors and/or one or more memory in combination with executable instructions that cause each device/system to perform their respective functions. As used herein, the terms “processor”/“controller” and “computer” whether used alone or in combination with executable instructions stored in a memory or other computer-readable storage medium should be understood to encompass any of various types of well-known computing structures including but not limited to one or more microprocessors, special-purpose computer chips, field-programmable gate arrays (FPGAs), controllers, application-specific integrated circuits (ASICs), combinations of hardware/firmware/software, or other special or general-purpose processing circuitry.
The methods and features recited herein may further be implemented through any number of machine readable media that are able to store machine executable instructions. Examples of machine readable media that may be used include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD or other optical disk storage, magnetic cassettes, magnetic tape, magnetic storage and the like.
Additionally or alternatively, in at least some embodiments, the methods and features recited herein may be implemented through one or more integrated circuits (ICs). An integrated circuit may, for example, be a microprocessor that accesses machine executable instructions or other data stored in a read only memory (ROM). In some such embodiments, the ROM stores machine executable instructions that cause the IC to perform operations according to one or more of the methods described herein. In at least some other embodiments, one or more the methods described herein are hardwired into an IC. In other words, the IC is in such cases an application specific integrated circuit (ASIC) having gates and other logic dedicated to the calculations and other operations described herein. In still other embodiments, the IC may perform some operations based on execution of machine executable instructions read from ROM or RAM, with other operations hardwired into gates and other logic of IC. Further, the IC may output image data to a display buffer.
As used herein, machine executable instructions include instructions retrieved from a memory and executable instructions in the form of hardwired logic, and combinations of the two. A memory storing machine executable instructions include a ROM, RAM or other data storage component storing instructions that may be retrieved and executed, as well as a portion of an ASIC or other processor containing hardwired logic.
Although specific examples of carrying out the invention have been described, those skilled in the art will appreciate that there are numerous variations and permutations of the above-described systems and methods that are contained within the spirit and scope of the invention as set forth in the appended claims. Additionally, numerous other embodiments, modifications and variations within the scope and spirit of the appended claims will occur to persons of ordinary skill in the art from a review of this disclosure.
