EP2329642A1

EP2329642A1 - Method and system to enable adaptation between physical bearers and oma-bcast

Info

Publication number: EP2329642A1
Application number: EP09815758A
Authority: EP
Inventors: Jani VÄRE; Jyrki Alamaunu; Harri Pekonen; Tommi Auranen
Original assignee: Nokia Oyj
Current assignee: Nokia Technologies Oy
Priority date: 2008-09-29
Filing date: 2009-09-22
Publication date: 2011-06-08
Also published as: WO2010035215A1; EP2329642A4; CN102165789A

Abstract

Systems and methods are provided that combine Open Mobile Alliance Mobile Broadcast Services (OMA BCAST) with different bearers, such as China Multimedia Mobile Broadcasting (CMMB) by associating service-related identifiers within an OMA BCAST electronic service guide with CMMB bearer-specific parameters. Furthermore, associating IP source and/or destination address pairs of a service with the location of the service within the CMMB bearer can be achieved and used with unicast, multicast, and broadcast environments. Further still, systems and methods are provided that allow for electronic service guide bootstrapping., where a desired electronic service guide can be discovered by bootstrapping.

Description

METHOD AND SYSTEM TO ENABLE ADAPTATION BETWEEN PHYSICAL BEARERS AND OMA-BCAST

FIELD

[0001] Various embodiments relate generally to the field of multimedia broadcast and multicast service systems. More particularly, various embodiments relate to enabling adaptation between a bearer agnostic electronic service guide (ESG) and different physical bearer standards.

BACKGROUND

[0002] This section is intended to provide a background or context to various embodiments recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section. [0003] Mobile multicast and broadcast systems have recently been standardized by different organizations, such as the 3rd Generation Partnership Project (3 GPP) Multimedia Broadcast/Multicast Service (MBMS), the Digital Video Broadcasting (DVB) Technical Module Convergence of Broadcast and Mobile Services (TM-CBMS), and the Open Mobile Alliance (OMA) Mobile Broadcast Services (BCAST) organizations. Other multicast and broadcast systems further include Integrated Services Digital Broadcasting - Terrestrial (ISDB-T), Digital Multimedia Broadcast-Terrestrial/Handheld (DMB-T/H), Digital Multimedia Broadcasting (T- DMB), Advanced Television Systems Committee mobile/handheld (ATSC-M/H), Forward Link Only (FLO) and proprietary systems, such as for example, MediaFLO. Two primary services provided by such multicast/broadcast solutions are streaming and file delivery services. [0004] OMA BCAST refers to an open global standard for mobile services, such as mobile TV and on-demand video services. Such services may be adapted to mobile IP-based content delivery and peer-to-peer content delivery. For example, OMA BCAST supports broadcast technologies such as DVB - Handheld (DVB-H). 3GPP MBMS, and mobile unicast streaming systems. The OMA BCAST standard defines various features including, e.g., electronic service guide, file delivery, streaming content delivery, service and content protection, service provisioning, notifications, etc. [0005] DVB IP Datacast (IPDC) and OMA BCAST define a service guide that carries a description of a service at issue. The IPDC ESG defines, in the Acquisition Fragment, the semantics of component characteristics. A receiving terminal can detect the characteristics of the service and decide whether it can consume the service or not. OMA BCAST has defined a bearer agnostic electronic service guide to be transmitted above different physical bearers. [0006] Electronic service guides enable a terminal to communicate available services to end users (receivers) and to indicate how such services may be accessed. Electronic service guides serve to provide users with information regarding a variety of scheduled programs, allowing a user to navigate, select, and discover content by time, title, channel, genre, etc. [0007] Electronic service guide fragments are independently-existing pieces of the electronic service guide. Electronic service guide fragments can comprise XML documents, Session Description Protocol (SDP) descriptions, textual files, images and other items. Electronic service guide fragments describe one or several aspects of currently available services, future services or broadcast programs. Such aspects may include, for example, free text descriptions, schedules, geographical availability information, prices, purchase methods, genres, and supplementary information such as preview images or clips. Audio, video and other types of data comprising the electronic service guide fragments may be transmitted through a variety of types of networks according to many different protocols. For example, data can be transmitted through 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. The data can, however, be multicast (to a set of users) or broadcast to all users in an area.

[0008] In an electronic service guide, information is typically presented to a user in terms of time. For example, as individual audio or video programs are scheduled to be presented during specified time periods, the electronic service guide concerning this information can be organized according to these same time periods, such that information about programs that are about to begin will be presented before programs occurring several hours in the future. [0009] The China Multimedia Mobile Broadcasting standard (CMMB) is a mobile TV and multimedia standard developed and specified by the State Administration of Radio, Film, and Television (SARFT) of China, which has been characterized as being similar to the DVB- Satellite services to Handhelds (DVB-SH) standard for satellite and terrestrial broadcasting of digital video. CMMB has specified an application layer agnostic data link layer and physical layer for the transmission of services such as mobile TV. However, utilizing OMA BCAST "on top" of CMMB in order to provide a complete end-to-end system, would result in a lack of mapping between the services signaled within the OMA BCAST ESG and the location of services signaled according to the CMMB specification.

SUMMARY

[0010] Various embodiments are described which allow the combining of OMA BCAST with different bearers, such as CMMB by associating service-related identifiers within an OMA BCAST ESG with CMMB bearer-specific parameters. That is, flexible mapping between application layer identifiers, e.g., GlobalservicelD, IP addresses, etc. and CMMB specific locations of the same service is effectuated. The CMMB-specific location is identified with a multiplex frame identifier (MF ID), a multiplex sub-frame identifier (MSF ID), a service identifier (servicelD), and a frequency_point_number. Various embodiments can be used to associate IP source and/or destination address pairs of a service with the location of the service within the CMMB bearer, and can be used in unicast, multicast, and broadcast environments. The OMA BCAST ESG can be transmitted through broadcast network or through any bidirectional interaction network, such as 3G. Also the tables proposed within this application can be transmitted to the terminals through several different paths, e.g. through broadcast network and/or interaction network. Furthermore, the transmission mechanisms for the signaling can be any combination of different signaling through broadcast network and interaction network. [0011] Furthermore, various embodiments are described which allow for electronic service guide bootstrapping, i.e., a desired electronic service guide can be discovered by bootstrapping, e.g., OMA BCAST ESG. In accordance with one electronic service guide bootstrapping embodiment, bootstrap information is discovered from a Bootstrap Service Association Table (BSAT), where, e.g., the BSAT is carried within a particular multiplex frame. After selecting a desired service, a receiver looks for the Service Association Table (SAT), after which the receiver is able to discover the location of the desired service.

[0012] Moreover, the two signaling tables, BSAT and SAT are to be transmitted within the CMMB signaling in parallel with existing signaling tables such as the Continual/Short time Service Multiplex Configuration Table (CMCT/SMCT) As described above, the SAT provides the mapping between service components announced within an electronic service guide, where in accordance with one embodiment, the SAT is substantially similar in syntax, structure, and/or content to that of the electronic service guide defined in the OMA BCAST Service Guide and the location of these services within the CMMB miltiplex. The BSAT in turn, provides the bootstrapping for the available electronic service guides offered by the CMMB network. [0013] These and other advantages and features of various embodiments, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, wherein like elements have like numerals throughout the several drawings described below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Embodiments of various embodiments are described by referring to the attached drawings, in which:

[0015] Figure 1 illustrates an exemplary structure and syntax of a Service Association Table according to one embodiment;

[0016] Figure 2 illustrates an end-to-end model of the delivery of an OMA BCAST type of service through a CMMB system in accordance with various embodiments;

[0017] Figure 3a illustrates another exemplary structure and syntax of a Service Association

Table in accordance with another embodiment;

[0018] Figure 3b illustrates yet another exemplary structure and syntax of a Service

Association Table in accordance with yet another embodiment;

[0019] Figure 4 illustrates an exemplary association effectuated with the exemplary structure and syntax of the Service Association Table of Figure 3;

[0020] Figure 5 illustrates exemplary relationships between CMMB elements, multiplex frame, multiplex sub-frame, signaling information, and services in accordance with various embodiments;

[0021] Figure 6 illustrates an exemplary process for effectuating an end-to-end association of service-related identifiers within an OMA BCAST ESG and CMMB elements in accordance with one embodiment;

[0022] Figure 7 illustrates an exemplary process for discovering an electronic service guide from a CMMB bearer via a Bootstrap Service Association Table in accordance with various embodiments;

[0023] Figure 8 illustrates an exemplary receiver implementation process for service discovery in accordance with various embodiments;

[0024] Figure 9 illustrates an exemplary service discovery flow of processes performed from access to an ESG bootstrap until discovery of a service location within a CMMB multiplex in accordance with various embodiments, wherein the multiplex configuration table refers to a

CMCT/SMCT;

[0025] Figure 10 illustrates an exemplary multiplex frame populated with data in accordance with various embodiments;

[0026] Figure 11 illustrates exemplary syntax and structure of the multiplex frame of Figure

10; [0027] Figure 12 illustrates various processes performed in an exemplary embodiment for starting up a service;

[0028] Figure 13 illustrates another exemplary receiver implementation process for service discovery in accordance with other various embodiments;

[0029] Figure 14 illustrates an exemplary broadcast channel frame in accordance with another embodiment;

[0030] Figures 15a- 15b illustrate various exemplary syntaxes of an IP Multiplex Configuration

Table in accordance with various embodiments;

[0031] Figures 16a-16b illustrate exemplary syntaxes of an IP Multiplex Configuration Table

Association Table in accordance with various embodiments;

[0032] Figures 17a- 17b illustrate exemplary encapsulation scenarios of data sections in accordance with various embodiments;

[0033] Figures 18a- 18b illustrate still other exemplary receiver service discovery processes in accordance with various embodiments;

[0034] Figure 19 is an overview diagram of a system within which various embodiments may be implemented;

[0035] Figure 20 is a perspective view of an electronic device that can be used in conjunction with the implementation of various embodiments; and

[0036] Figure 21 is a schematic representation of the circuitry which may be included in the electronic device of Figure 10.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

[0037] Various embodiments enable the combining of OMA BCAST with different bearers, such as CMMB by associating service-related identifiers within an OMA BCAST ESG with CMMB elements. It should be noted that the adaptation in accordance with various embodiments described herein between OMA BCAST and CMMB is merely exemplary. The same or substantially similar systems and methods can also be utilized to associate electronic service guide identifiers with elements for other bearers as well, which have similar functionalities. In accordance with various embodiments, a mapping functionality is provided by defining a Service Association Table, which can be used, for example, within a data link layer (in a Program Specific Information/Service Information (PSI/SI) fashion). Additionally, the Service Association Table can be embedded in application layer XML metadata. [0038] Table 1, described below, is an exemplary Service Association Table defined in accordance with various embodiments that provides a mapping between one or more identifiers within an OMA BCAST ESG that have an association with a service. Such an association can be direct, e.g., pointing to the service itself. This type of a direct association can be accomplished through the use of a globalservicelD, for example. Alternatively, the association can be accomplished by pointing to the service by way of one or more IP addresses. The association can also be an indirect association, where pointing to a service is accomplished by pointing to fragments associated with the service. Furthermore, various embodiments include a private data field that can allow new identifiers to be defined in the future.

Table 1.

[0039] Identifiers such as those described above can include, but are not limited to, e.g., Universal Resource Identifiers (URIs). URIs are widely used within the signaling of different identifiers according to OMA-BCAST. That is, identifier types, such as those presented in Table 1 are signaled within the Service Association Table. The URIs are used, e.g., for the identification of services (through a GlobalservicelD) or fragments (through fragmentlDs) within the electronic service guide.

[0040] Figure 1 illustrates an exemplary structure and syntax of a Service Association Table according to one embodiment. Figure 2 illustrates an end-to-end model of the delivery of OMA BCAST type services through the CMMB system in accordance with this embodiment. According to this one embodiment, the OMA BCAST and/or any other application layer service- specific identifiers are mapped with four CMMB bearer- specific parameters. The four CMMB bearer-specific parameters indicate the location of a service within the CMMB physical layer. For example, the latter parameters can be frequency_point_number, MF ID, MSF ID and servicelD.

[0041] Earlier parameters listed in Figure 1 include the following: table id which refers to an identifier of a table; section syntax indicator which refers to a 1-bit field which can be set to "1"; section_length, a 12-bit field that specifies the number of bytes of a section, starting immediately following the section length field and including the CRC; and version number which refers to a 5-bit field indicating a version number of the table. It should be noted that the version number shall be incremented by 1 when a change in the information carried within the table occurs. When the version number reaches a value, e.g., 31 , the version number wraps around to 0. When the current next indicator, described above, is set to "1," the version number shall be that of the currently applicable table. When the current next indicator is set to "0," then the version number shall be that of the next applicable table. [0042] Additional parameters include: current next indicator, a 1-bit indicator, which when set to "1" indicates that the table is the currently applicable table, and when the bit is set to "0" is indicative that the table sent is not yet applicable and shall be the next table to be valid; and section number, which is an 8-bit field that gives the number of a section, where the section number of the first section in the table shall be "0x00." It should be noted that the section number shall be incremented by 1 with each additional section with the same table id, service id, transport stream id, and original network id. In this case, the table may be structured as a number of segments, where within each segment, the section number shall increment by 1 with each additional section. However, a gap in numbering is permitted between the last section of a segment and the first section of the adjacent segment. [0043] Further parameters include: last section number, an 8-bit field specifying the number of the last section (i.e., the section with the highest section number) of the table of which this section is a part; identifier Loop length, a 12-bit field that indicates the length of a following identifier loop; identifier type, a field that indicates the type of an associated identifier, such as those listed in Table 1 above; URI length, an 8-bit field specifying the length in bytes of a URI; URI byte, another 8-bit field, where a string of "uri char" fields specifies the URI identifying the service, and text information is coded in an 8-bit Unicode Transformation Format (UTF-8); number of identifiers, indicative of the number of identifiers associated with a servicelD within one iteration of the identifier loop; IPv4_src_addr, which is a 32-bit field that specifies an IPv4 unicast/multicast/broadcast source address, where the IPv4 address is fragmented into 4 fields of 8 bits and the first field contains the most significant block of the IPv4 address (dotted notation); IPv4_dst_addr, a 32-bit field that specifies an IPv4 unicast/multicast/broadcast destination address, where the IPv4 address is fragmented into 4 fields of 8 bits and the first field contains the most significant block of the IPv4 address (dotted notation); IPvβ src addr, a 128-bit field that specifies an IPv6 unicast/multicast/anycast source address, where the IPv6 address is fragmented into 8 fields of 16 bits and the first field contains the most significant block of the IPv6 address (dotted notation); and IPv6_dst_addr, another 128-bit field that specifies an IPv6 unicast/multicast/anycast destination address, where the IPv6 address is fragmented into 8 fields of 16 bits and the first field contains the most significant block of the IPv6 address (dotted notation).

[0044] Further still, parameters include: servicelD which identifies a service within the CMMB system; MF ID which is a field indicative of the identifier of the multiplex frame within the CMMB system.; MSF ID, a field that identifies the multiplex sub-frame within the CMMB system; and Frequency_point_number, an 8-bit field that refers to a sequence number of the frequency point affiliated with a CMCT/SMCT and to the MF ID, MSF ID and servicelD announced within a particular Service Association Table. Moreover, another embodiment may include parameters such as service loop length, a 12-bit field that indicates the length of the following service loop (not shown). It should be noted that the above-described parameters and field lengths indicated in Figure 1 are merely exemplary in accordance with one embodiment. It should further be noted that the CMCT/SMCT is used to describe information of each continual/short time service multiplex frame configuration within a certain period of time. Such information includes the position of each multiplex frame, channel processing method, and the coincidence relation between sub-frames and service identifier.

[0045] Although IP is conventionally utilized as an interface between the application layer and bearer-specific layer 2 (L2) signaling, various embodiments provide a flexible interface that allows any application layer identifier to be associated with CMMB bearer- specific structures. Although delivery of IP over CMMB is not defined in the CMMB specification(s), such functionality is provided for by allowing for the delivery of, e.g., IP in data sections. [0046] As noted above, Figure 2 illustrates an end-to-end model of the delivery of OMA BCAST type services through the CMMB system in accordance with one embodiment. According to this one embodiment, the OMA BCAST and/or any other application layer service- specific identifiers are mapped with four CMMB bearer- specific parameters which indicate the location of a service within the CMMB physical layer, e.g., frequency_point_number, MF ID, MSF ID and servicelD.

[0047] Figure 2 further illustrates relationships between various domains. That is, 40 timeslots may be configured in the physical domain, e.g., tsO, tsl, ts2... ts39, where tsO may reserved for signaling purposes. The multiplex domain has defined therein, a maximum of 40 multiplex frames, e.g., MF 0, MF 1, MF n... MF m, where MF ID 0 is reserved for signaling and MF ID 1 is reserved for ESG. Each multiplex frame may be made up of one or more multiplex sub- frames, with a maximum of 15 multiplex sub-frames per multiplex frame. For example, Figure 2 illustrates that multiplex frame MF n is made up of multiplex sub-frames MSF 1 and MSF j, while multiplex frame MF m is made up of its own multiplex sub-frames MSF 1 ' and MSF j'. [0048] In CMMB, each multiplex sub-frame is equated with a service. Additionally, each multiplex sub-frame may be made up of different sections. For example, MSF 1 is made up of, e.g., a sub-frame header, a video section, an audio section, and a data section, while MSF Y is made up of its own sub-frame header, video section, audio section, and data section. Each data section can in turn be made up of a maximum of 255 data units. For example, data section 200 includes data unit 202a and 202 b, while data section 200' includes a data unit 202a' and a data unit 202b'. The type and length of each data unit is indicated in a data section header, for example, data section header 204 of data section 200 and data section header 204' of data section 200'.

[0049] Within the IP domain, e.g., in the OMA BCAST IP context, IP packets, such as IP packets 206, are mapped to one or more multiplex sub-frame data sections. Thus a collection of "CMMB services" will form one OMA BCAST ESG domain..

[0050] In accordance with another embodiment, a truncated version of the Service Association Table may be utilized, where the Service Association Table lacks the parameters MF ID, MSF ID and frequency_point_number. In this situation, a receiver visits a CMCT/SMCT to obtain these missing parameters and thus, complete discovery of a service location within the CMMB physical bearer. Figure 3a illustrates this truncated version of the Service Association Table.

[0051] Figure 3b illustrates yet another version of an exemplary Service Association Table in accordance with yet another embodiment. In this embodiment, the Service Association Table structure includes an inner loop within an identifier loop for enabling several identifiers to bundled together. Hence, the bundled identifiers can be associated with a servicelD parameter. Such a feature avoids the possible redundancy experienced when signaling the same servicelD parameter repeatedly. Table 2 below is also another exemplary Service Association Table defined in accordance with another embodiment.

Table 2.

[0052] The "analog" of the structure and syntax depicted in Figure 2 is illustrated in a simplified form in Figure 4 by way of an example association of three URIs 412, 414, and 416 with CMMB bearer-specific parameters, which in this case are the service ID, the frequency_point_number, the MF ID, and the MSF ID parameters. That is, a Service Association Table 400 includes a "header part" 405 and an identifier loop 410, in which the URIs 412, 414, and 416 are "announced."

[0053] The relationship between a multiplex frame, multiplex sub-frames, and a service or signaling information is described with reference to Figure 5. As was illustrated in Figure 2, a multiplex frame with a particular MF ID 500 includes a plurality of multiplex sub-frames, e.g., multiplex sub-frames 502, 504, 506... 510. Each of these multiple sub-frames, e.g., multiplex sub-frame 502 is in turn related to service or signaling information, e.g., service or signaling information 520, 522... 526.

[0054] Figure 6 illustrates processes performed in a "3-step approach" to accomplish end-to- end mapping in accordance with various embodiments, where URIs announced within an OMA- BCAST ESG are associated with the CMMB elements/bearer-specific parameters. At 600, identifiers are announced within the OMA BCAST ESG internal structures, and have mutual associations (where, e.g., a system service, content provider, network operator, broadcast service provider, etc. generates and transmits its OMA-BCAST ESG and/or its fragments to a multicast group address). That is, service fragments are associated with services and GlobalservicelDs, which are further associated with access fragments, etc. An identifier can be any URI or, for example, an IPv4 or IPv6 address. Additionally, any other identifiers may be used, if defined for, e.g., the private field in the Service Association Table.

[0055] At 610, the type of identifier is distinguished by an identifier type-field. Additionally, the identifiers are associated within the Service Association Table with the CMMB elements, i.e. the bearer- specific parameters that define the location of the service within the CMMB physical layer. For simplicity and continuity, the exemplary parameters are the latter parameters discussed above, i.e., MF ID, MSF ID, frequency_point_number, and servicelD. [0056] In accordance with one embodiment, such as the embodiment described in relation to Figure 2, the location of the CMMB bearer-specific parameters frequency_point_number, MF ID, MSF ID, and servicelD are all announced within the Service Association Table. Hence, a potential receiver of content, services, etc. indicated in an ESG may obtain access to the content/service^) based solely on the information carried within the Service Association Table and on the OMA-BCAST ESG.

[0057] In accordance with another embodiment described above, the Service Association Table may lack CMMB bearer-specific parameters such as the frequency_point_number, MF ID, and MSF ID parameters. In this instance, a receiver is directed to visit one or more CMMB tables to obtain a full mapping between a service announced within the OMA BCAST ESG (i.e., an identifier used for this purpose, e.g., globalservicelD or IP address) and the location within the CMMB physical layer stream. Thus, at 620, the desired multiplex frames and multiplex sub- frames can be filtered from a larger set of multiplex frames by means of an identification provided at 610 that directs the receiver to, e.g., a multiplex configuration table containing the requisite frequency_point_number, MF ID, and MSF ID parameters. [0058] In addition to service mapping, various embodiments provide bootstrapping for a desired electronic service guide, e.g., a OMA BCAST ESG. That is, various embodiments allow for the discovery of an ESG from a CMMB bearer. It should be noted that the OMA BCAST ESG is used merely as an example, and various embodiments support bootstrapping for various electronic service guides. According to a first embodiment of the electronic service guide bootstrap feature, the electronic service guide bootstrap is identified with the first IP source "src" and/or destination "dst" addresses announced within a first Service Association Table (SAT), where the port number for this bootstrap is fixed. According to a second embodiment of the electronic service guide bootstrapping feature, the electronic service guide bootstrap is identified with the first identifier announced and associated with the CMMB bearer within the SAT. According to a third embodiment of the electronic service guide bootstrapping feature, the electronic service guide bootstrap is identified within a specific Bootstrap Service Association Table (BSAT), which has an identical structure to that of an SAT. However, the BSAT is used only to announce the bootstrap location. The BSAT is always carried within the first multiplex frame (i.e., MF ID = 0).

[0059] Figure 7 illustrates an example of service flow discovery via BSAT and SAT. At 700, bootstrap information is discovered from the BSAT, where, e.g., the BSAT is carried within multiplex frame MF 0. After selecting a desired service, the receiver looks for the SAT at 710. At 720, the receiver is able to discover the location of the desired service. [0060] Figure 8 is a flow chart illustrating processes performed in service discovery from a receiver perspective in accordance with various embodiments. It should be noted that more or less processes can be performed, and in differing order, to achieve various features and functions described herein. At 800, a receiver searches CMMB signals until one or CMMB signals are found. At 810, from the found CMMB signal, the receiver looks for the OMA BCAST ESG. Upon accessing the OMA BCAST ESG, the receiver parses the ESG and decodes associated metadata at 820. The OMA BCAST ESG can be fixed to a specific servicelD within the CMMB. Additionally, the servicelDs associated with different electronic service guides are announced within the beginning of a Service Association Table. Alternatively, a Service Association Table may associate the first listed identifier with the OMA BCAST ESG. For example, the first listed identifier would be the "bootstrap identifier." In accordance with still other embodiments and as described above, a BSAT (which has a structure identical to that of an SAT) is utilized. Again, it should be noted that the BSAT is transmitted within the first Multiplex frame (i.e., MF ID = 0). The metadata is then displayed to an end user of the receiver, and the end user may select one or more desired services from the electronic service guide. [0061] At 830, all needed identifiers for the desired service(s) are search for and the receiver stores all of the needed identifiers associated with each desired service. These identifiers can be, e.g., globalservicelD, IP address, accessfragmentID, etc. depending on how the implementation is realized in mapping the CMMB bearer-specific parameters with the higher layer identifiers of the one or more services. At 840, the receiver accesses the first sub-frame of the first multiplex frame within the CMMB (which carries the proposed Service Association Table). At 850, the receiver starts to search for the Service Association Table from the beginning of the first sub- frame of the first multiplex frame. When the Service Association Table is found, the receiver is able to discover the location information for the one or more identifiers associated with the CMMB bearer-specific information and which it has previously stored to memory at 860. If the Service Association Table does not carry all of the requisite parameters for discovering the location of the service(s), the receiver continues to seek and inspect, e.g., a multiplex configuration table as described earlier, to complete discovery of the service(s). [0062] It should be noted that in accordance with one embodiment, transmission of the Service Association Table can be via the carriage within the L2 signaling, similar to the CMMB specific tables. In accordance with yet another embodiment, transmission of a proposed Service Association Table can be, e.g., the carriage within the metadata of an electronic service guide. Further still, the Service Association Table or similar information can be delivered through an interaction network, e.g., by way of a network server where the client has subscription. Such a service can be public.

[0063] Figure 9 illustrates another exemplary service discovery flow of processes performed from access to an ESG bootstrap until discovery of a service location within a CMMB multiplex configuration table for example, a CMCT/SMCT in accordance with various embodiments. At 900, it is shown that the BSAT is carried within multiplex frame MF ID=O, together with one or more other legacy CMMB tables. The IP address pair for the electronic service guide bootstrap discovery information IP source (IP src addr) and destination (IP dst addr) addresses is always announced as the first IP address pair within the BSAT as described above. Additionally and as also described above, the port number for accessing the electronic service guide bootstrap discovery information may be fixed. It should be noted that in accordance with one embodiment, the first IP address pair in the BSAT may lead to an available electronic service guide if the bootstrap mechanism is not used.

[0064] At 910, a terminal or User Equipment (UE) may find the location of the announced electronic service guide bootstrap discovery information from the CMCT/SMCT based on the service identification (servicelD) accompanied by the IP address pair in the BSAT. The location information comprises multiplex frame identification, multiplex sub-frame identification and frequency point as described above. The electronic service guide bootstrap discovery information is then received, where the electronic service guide bootstrap discovery information may comprise one or more entries that include electronic service guide provider identification with an IP address pair.

[0065] At 920, the selection for the desired ESG provider(s) is performed based on the list of ESG providers available in an electronic service guide provider descriptor that may be substantially similar to the ESGProviderDiscovery descriptor that is specified in the European Telecommunications Standards Institute (ETSI) standard TS 102471, "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG)." The ESGProviderDiscovery descriptor specifies the ESG providers that deliver ESGs in a given IP platform, although it should be noted that the ESG Provider Discovery Descriptor may still be used as if there is only one IP platform if the multiple IP platform "concept" is unsupported. The ESGProviderDiscovery descriptor is represented as a textual XML file. Based on the ESGProviderDiscovery descriptor, the UE/terminal may select the electronic service guide to boot with. Based on the ESGProviderID associated with each described ESGProvider or ESG URI associated with each described ESG, the terminal/UE may parse the related ESGAccessDescriptor to boot the electronic service guide. Furthermore, the ESGAccessDescriptor is a binary representation of ESG Acquisition information. The ESGAccessDescriptor specifies the Acquisition information related to a particular ESGProviderID signaled in the ESGProviderDiscovery descriptor. An ESG Provider can offer several electronic service guides identified by a unique ESG URI. For each electronic service guide, the access points from where a DeliveryList and ESG Fragments can be retrieved are signaled in the AccessDescriptor. Each access point is identified by an identifier, e.g., accessPointID. "Interactive" and "complementary" access point implies the capability and context of a specific ESG URI associated with it, whereas a "repair" access point always offers the same ESG Fragments as is offered in the broadcast delivery.

[0066] The access information comprising IP address pair, port number and URI for the electronic service guide of the desired electronic service guide provider can also be discovered from associated metadata. In the electronic service guide provider identification, ESGProviderID is an example of the URI. Additionally, and in accordance with one embodiment, the selection of the desired ESG provider may be based on currently pending subscriptions, and in the event that several subscriptions exist, the selection may be performed by the user. In accordance with another embodiment, the selection may be based on the user (or UE) location, wherein the location information can be acquired from received cell or transmitter information. The ESG provider list may be shown to the user, or alternatively, the electronic service guide may be automatically retrieved based on the subscriptions or predefined user selections.

[0067] The selection of the ESG provider, in effect, amounts to selecting the electronic service guide. In accordance with one embodiment, the selection of the electronic service guide comprises selecting a combination of services from several electronic service guide providers, where the receiver/terminal only has access to those services for which it has subscription. Furthermore, only those services would be visible to the user. In accordance with various embodiments, a user interface may present non-subscribed services differently from subscribed services. In one embodiment, one ESG provider may provide more than one electronic service guide, for example, for different time span(s), for different service description(s) (e.g., different language, different dialect, different service content descriptions (long/short)). In such embodiments, some descriptive information may be added to the data in the electronic service guide discovery bootstrap information. The IP address pair in the electronic service guide bootstrap discovery information is the IP address pair for the electronic service guide. [0068] At 930, the location information for the servicelD (announced within the BSAT) associated with the discovered ESG access information is sought from the CMCT/SMCT. At 940, the content from the MSF ID associated with the requested servicelD is inspected from the multiplex sub-frame MSF, which carries the related SAT with data type =SAT and the electronic service guide (that in this exemplary embodiment) is an OMA-BCAST ESG(s). At 950, the selection is performed for the desired service(s) from the electronic service guide presented to the user. At 960, the servicelD for the selected service having the IP address pair is discovered from the SAT and the process continues again to the inspection of the CMCT/SMCT. At 970, the location of the desired servicelD is discovered from the CMCT/SMCT and the data for the selected service 1 can be received. [0069] Various embodiments described herein includes the definition of new data types and of the definition of syntax and semantics for the BSAT and SAT. As indicated above, the BSAT is carried within the multiplex fram MF ID = 0. The SAT, in turn, is carried together with the related electronic service guide within the same multiplex sub-frame. Hence, there is one "full" SAT per electronic service guide. For the CMMB system's data section (described above) in the multiplex sub-frame that may carry the SAT and IP addresses new data types may be defined including but not limited to the following: SAT = OxI ; IPv4 = 0x2; and IPv6 = 0x3. The syntax and semantics of BSAT and SAT are mutually identical. The syntax for the proposed SAT and BSAT structure is depicted as previously shown in Figure 3B, followed with the definition of each field. It should be noted that the illustrated syntax and semantics including the size of the fields are merely exemplary in accordance with one embodiment. Alternatively, the syntax of the BSAT may be different from the syntax of the SAT in situations where the first IP address pair and related service identification comprising data relating to the electronic service guide bootstrap discovery information is not within the loop.

[0070] Figure 10 illustrates an exemplary multiplex frame 1000 and how/where the multiplex frame is populated with data. The multiplex frame 1000 includes a multiplex frame header 1010 (as described above). The multiplex frame 1000 also includes a field 1020 for a protocol version number that can be updated when needed, e.g., when updating information for the BSAT and the SAT. Additionally, a field 1030 and a field 1040 are included in the multiplex frame 1000 for indicating a sequence number for ESG update and sequence number for (B)SAT update, respectively. It should be noted that these sequence numbers correspond to sequence numbers specified in CMMB. Moreover, it should be noted that reserved bits are utilized after an ESG update for the (B)SAT updated. That is, the reserved bits illustrated in, e.g., Figures 1, 3a, and 3b can be changed if the IP mapping carried in a particular multiplex frame (MF 1000) has been changed or if the (B)SAT has changed.

[0071] Figure 11 illustrates the syntax and structure of an exemplary multiplex frame, e.g., MF 1000. Four reserved bits in the multiplex frame header (as per the CMMB standard) are defined to indicate sequence number for the BSAT and the SAT or the IMCT and the IAT (described in greater detail below). Whenever there is a change in information described in the BSAT and/or the SAT, or in the IMCT and/or the IAT, the respective sequence number(s) within this field(s) are changed as well by cyclic value adoption ranging from 0 to 15 and by adding a 1 for each update.

[0072] Figure 12 illustrates various processes performed in an exemplary embodiment for starting up a "service." At 1200, a terminal or UE issues a tune command to initiate listening for, e.g., multiplex frames transmitted via a broadcast or interaction network. Additionally, a time slot (tsO) file is set. As described above, the time slots are configured in the physical domain, where the duration of a physical layer frame is 1 second, which consists of 40 time slots numbered from 0 to 39. At 1210, from the next tsO, the terminal/UE extracts the BSAT, where the BSAT informs IP mapping for the ESG bootstrap (BS), ESG Carousels, and related SATs. At 1220, a filter is created from the BS service. At 1230, when the ESG BS Carousel is received, the desired ESG provider can be selected. At 1240, a filter is created for the ESG Carousel (and SAT). At 1250, the SAT (IP mapping for ESG) and ESG is received. Thereafter, any service(s) based on the ESG + SAT can be received.

[0073] Figure 13 illustrates yet another exemplary receiver implementation process for service discovery in accordance with other various embodiments. At 1300, a receiver searches CMMB signals until one or more CMMB signals are found. If one or more signals is found, at 1310, a filter for the tsO is sent and the receiver waits for the next tsO. Once the tsO is received, the receiver filters and inspects the BSAT at 1320 (which as described above, is extracted from the next tsO). At 1330, a filter is created for the bootstrap service. Once the bootstrap service is received, information associated with the bootstrap service is inspected and a desired ESG provider is selected at 1340. At 1350, a filter is set for the ESG Carousel and SAT of the selected ESG provider. Once the electronic service guide is received, information associated with the electronic service guide is inspects and the desired service may be selected at 1360. At 1370, a filter is set for the desired service(s) based on the information in the electronic service guide and SAT.

[0074] With regard to handover, a Continual Service Configuration Table (CSCT) and a Short time Service Configuration Table (SSCT) can be used to map a service identifier and frequency point. The CSCT and SSCT desribe the coincidence relation information of all continual/short time services to carrier frequencies. That is, the data in the CSCT/SSCT comprises services identification (serviceΙD)-channel center frequency (frequency_point_number) pairs for all services carried in a network. Hence, the mapping can be used during handover to determine from which frequencies, a service(s) can be found. Additionally, the CSCT/SSCT mapping also makes it possible to signal, e.g., receivers, about services that are not necessarily present in the current frequency, because the CSCT/SSCT may be included in the SAT. It should be noted that the CSCT and the SSCT have the same parameters except for their table identifier numbers. [0075] Figure 14 illustrates a broadcast channel frame 1400 in accordance with still another embodiment. The frame 1400 includes a tsO field and fields for various services, identified by ServicelD 1, ServicelD 2, and ServicelD 3. The broadcast channel frame 1400 can be found from a bootstrap FLUTE session. The tsO can contain a list 1410 of ESG Providers (IP addresses) associated with each of the services. It should be noted that common IP address resolution for bootstrap and all ESG Carousels is utilized, and the possibility extists for the same or for different resolution for IP belonging to different ESG Providers. [0076] In accordance with still other embodiments, the signaling extension for the OMA- BCAST over CMMB can consist of new signaling tables, i.e., the IP Multiplex Configuration table (IMCT) and the IMCT Association Table (IAT). The IMCT can be likened to the above- described SAT, while the IAT can be likened to the BSAT. That is, the IMCT provides the mapping between IP addresses and CMMB servicelDs, while the IAT, in turn, provides the bootstrap functionality which helps receiver to discover the desired IMCT(s). In addition, the legacy CMMB signaling structure is used as such, together with these new signaling elements. [0077] IMCT is platform specific and it SHALL associate IP addresses of one platform with the CMMB servicelD. The IP addresses announced within the IMCT are unique within the associated platform id. In addition to the IP addresses IMCT may associate other identifiers with the given platform id and with the CMMB servicelD. An exemplary syntax of IMCT is described in Figure 15 a. The semantics of the IMCT are the same or substantially the same as those previously described in relation to, e.g., Figure 1, 3a, and 3b. However, Figure 15a illustrates a platform identifier "platform id" which is a 12 bit field that indicates the length of the following identifier loop. Another exemplary syntax of IMCT is described in Figure 15b. The semantics of the IMCT syntax illustrated in Figure 15b include the following which may or may not differ from the previous exemplary IMCT syntax: a table identifier number/table id which is an 8-bit identifier of the table; a length of section field which is a 16-bit field that includes the table identifier number, but excludes the CRC 32 field, and the unit is byte; a section number which refers to an 8-bit field that gives the section number, where the section number of the first section in the table is 'OxOO' which is incremented by 1 with each additional section; a quantity of sections fields that is an 8 -bit field indicating the quantity of sections segmented in an IMCT; and a sequence number for IMCT update which is a 4-bit field that indicates when there is a change in information described in the IMCT table, such that the value signaled within this table starts from '0'.

[0078] The IAT provides an association between platform and CMMB servicelD pairs. A 24- bit platform id and name is signaled for each platform announced within this table. One CMMB servicelD may be associated with multiple platform ids, although one platform id is not associated with more than one CMMB servicelD. The IAT contain a linkage to all the platforms available within a particular network. An exemplary syntax of the IAT is illustrated in Figure 16a. As with the IMCT, the majority of the semantics for the IAT have already been described above in relation to the exemplary IMCT syntax illustrated in Figure 15 a. However, the IAT also includes a platform id (noted above) that refers to a 24-bit field that is an identifier for a globally unique platform. Additionally, the IAT includes a platform name length field that is an 8-bit field for specifying the length in Bytes of the platform name, as well as a servicelD which in this embodiment, refers to a 16-bit identifier which is used to provide the association between the IAT and CMCT/SMCT, where this identifier is unique within a network number. Figure 16b illustrates another exemplary syntax of the IAT that is commensurate with the IMCT syntax illustrated in Figure 15b. That is, the semantics of this exemplary IAT includes, e.g., a table identifier number/table id, a length of section field, a section number, a quantity of sections field, and a sequence number for IMCT update field.

[0079] Encapsulation differs between the IAT and the IMCT. With regard to encapsulation of IAT, it is similar to that described above for legacy CMMB signaling tables such as the BSAT, where the table identifier for the IAT is set to a value of "0x07" or alternatively, to a value of "0x08." If a sequence number field is included in the syntax of the IMCT/IAT, the sequence number of the IAT is identical to the sequence number of the IMCT. The IMCT, ESG and IP based services are encapsulated within data units, where the following applies: the type of the data unit carrying the IMCT which is set to a value of, e.g., "0x01" or "OxAA"; the table identifier of the IMCT which is set to the value of "0x08" or alternatively, to the value of "0x09"; the type of the data unit carrying IP datagrams which is set to the value of "0x02 or other embodiments, to the value of "OxAB"; and the type of the data unit carrying the electronic service guide that is set to the value "0x02."

[0080] Figure 17a illustrates an example encapsulation of data sections that contain the IMCT, electronic service guide, and IP datagrams, in accordance with such an embodiment. As described above, a data section 1700 is made up of a data section header 1704 and a plurality of data units including, e.g., a data unit 1702a of type 0x1, a data unit 1702b of type 0x0, and a data unit 1702c of type 0x2. The data unit 1702a encapsulates the IMCT 1710 and the data unit 1702b encapsulates the electronic service guide 1720. The data unit 1702x encapsulates IP datagrams 1730a, 1730b, and 1730c. It should be noted that more or less data units can make up the data section 1700 and that more or less IP datagrams can be encapsulated in more or less data units. Figure 17b illustrates another example of the encapsulation of data sections. Figure 17b, where a section 1750 is made up of a data section header 1754 and a plurality of data units. The plurality of data units include data unit 1752a of type OxAA, data unit 1752b of type OxAB, and so on, until data unit 1752n of type OxAB. Data unit 1752a encapsulates the IMCT 1760, while data unit 1752b encapsulates an IP datagram 1770a. Data unit 1752n encapsulates IP datagrams 1770b-d. The data section header 1754 comprises information regarding the number of data units and in addition, includes data type and data length information for each of the data units

1752a to data unit 1752n. Various embodiments have been described in conjunction within the context of different values and data lengths. It should be noted that such values and data lengths are merely exemplary.

[0081] With regard to transmission, the IAT is sent at least one time per second, and the IAT is sent within the multiplex frame MF ID = 0 within tsO. Additionally, the IMCT update is announced within the multiplex frame header where the IMCT is carried. The IMCT is also sent at least once per second, and the IMCT and its related electronic service guide is sent within the same multiplex frame. In accordance with one embodiment, one servicelD should not be associated with more than one IMCT, and the IMCT update can be announced within the multiplex frame header where the IMCT is carried as described above in relation to transmission of the IAT.

[0082] Figure 18a illustrates yet another example of receiver service discovery based on signaling for IP services using IAT, IMCT, and CMCT in accordance with the IAT/IMCT described in association with Figures 15a and 16a above. At 1800, after a receiver has found one or more CMMB signals with sufficient signal quality, the receiver decodes the IAT and CMCT from a multiplex frame, MF ID = 0. The receiver is interested in a platform named "SARFT," which has a platform id = 1. The IAT has the desired platform available and it points to the serviceID=24. The receiver inspects the CMCT and discovers the frequency_point_number, MF ID and MSF ID associated with the servicelD = 24. At 1810, the receiver receives and decodes the multiplex sub-frame MSF based on the tuple: servicelD = 24; frequency_point_number=10; MF ID = 2;0 and MSF ID = 7. The location of the IMCT within the MSF_ID=7 is discovered based on the 'type of data unit =IMCT' and the location of the electronic service guide is discovered based on 'type of data unit = 0.' At 1820, after the decoding of the electronic service guide, the receiver selects the desired service. The servicelD = 10 associated with the selected service is discovered from the IMCT. At 1830, the CMCT is inspected and the association for the servicelD = 10 is determined from there. At 1840, the CMCT associates the servicelD = 10 with the triplet: frequency_point_number = 10, MF ID = 14 and MSF ID = 3. Then, the receiver receives and decodes the pointed to MSF ID and may receive the service data. It should be noted that the service discovery process in the case of the SMCT is identical or at least substantially similar to that of the service discovery process in the cast of CMCT described herein.

[0083] Figure 18b illustrates still another example of receiver service discovery based on signaling for IP services using IAT, IMCT, and CMCT in accordance with the IAT/IMCT described in association with Figures 15b and 16b above. At 1850, after a receiver has found one or more CMMB signals with sufficient signal quality, the receiver decodes the IAT and

CMCT from a multiplex frame, MF ID = 0. The receiver is interested in a platform named "SARFT," which has a platform id = 1. The IAT has the desired platform available and it points to the serviceID=24. The receiver inspects the CMCT and discovers the frequency_point_number, MF ID and MSF ID associated with the servicelD = 24. At 1855, the receiver receives and decodes the multiplex sub-frame based on the tuple: service ID = 24; frequency_point_number = 10; MF ID = 2, and MSF ID = 7. The location of the iMCT within the MSF ID = 7 is discovered based on the data type specified for the IMCT (i.e., OxAA). At 1860, the receiver looks for the mapping between the ESG bootstrap address and servicelD = 10 from the IMCT. At 1865, the receiver inspects the mapping betweent eh servicelD = 10 and the frequency_point_number, the MF ID, and the MSF ID from the CMCT. The receiver filters and decodes the ESG bootstrap structure from the location found. At 1870, the receiver looks for the IP addresses associated with the SARFT ESG within the bootstrap. The receiver looks for the related servicelD for the IP address pair that has been found from the IMCT. At 1875, the receiver looks for the association between the servicelD that has been found an other parameters from the CMCT. At 1880, the receiver filers and decodes the SARFT ESG based on the IP address the CMMB tuple. At 1885, the receiver selects a desired service, e.g., service A, from the SARFT ESG and looks for the related servicelD for the service A IP addresses from the IMCT. At 1890, the receiver again inspects the association between the servicelD and the other CMMB parameters. At 1895, the receiver filters and decodes the service A. As noted above, the service discovery process in the case of the SMCT is identical or at least substantially similar to that of the service discovery process in the cast of CMCT described herein. [0084] Figure 19 shows a system 10 in which various embodiments can be utilized, comprising multiple communication devices that can communicate through one or more networks. The system 10 may comprise any combination of wired or wireless networks including, but not limited to, a mobile telephone network, a wireless Local Area Network (LAN), a Bluetooth personal area network, an Ethernet LAN, a token ring LAN, a wide area network, the Internet, etc. The system 10 may include both wired and wireless communication devices. [0085] For exemplification, the system 10 shown in Figure 19 includes a mobile telephone network 11 and the Internet 28. Connectivity to the Internet 28 may include, but is not limited to, long range wireless connections, short range wireless connections, and various wired connections including, but not limited to, telephone lines, cable lines, power lines, and the like. [0086] The exemplary communication devices of the system 10 may include, but are not limited to, an electronic device 12 in the form of a mobile telephone, a combination personal digital assistant (PDA) and mobile telephone 14, a PDA 16, an integrated messaging device (IMD) 18, a desktop computer 20, a notebook computer 22, etc. The communication devices may be stationary or mobile as when carried by an individual who is moving. The communication devices may also be located in a mode of transportation including, but not limited to, an automobile, a truck, a taxi, a bus, a train, a boat, an airplane, a bicycle, a motorcycle, etc. Some or all of the communication devices may send and receive calls and messages and communicate with service providers through a wireless connection 25 to a base station 24. The base station 24 may be connected to a network server 26 that allows communication between the mobile telephone network 11 and the Internet 28. The system 9 may include additional communication devices and communication devices of different types. [0087] The communication devices may communicate using various transmission technologies including, but not limited to, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Transmission Control Protocol/Internet Protocol (TCP/IP), Short Messaging Service (SMS), Multimedia Messaging Service (MMS), e-mail, Instant Messaging Service (IMS), Bluetooth, IEEE 802.11, etc. A communication device involved in implementing various embodiments may communicate using various media including, but not limited to, radio, infrared, laser, cable connection, and the like.

[0088] Figures 20 and 21 show one representative electronic device 12 within which various embodiments may be implemented. It should be understood, however, that various embodiments are not intended to be limited to one particular type of device. The electronic device 12 of Figures 20 and 21 includes a housing 30, a display 32 in the form of a liquid crystal display, a keypad 34, a microphone 36, an ear-piece 38, a battery 40, an infrared port 42, an antenna 44, a smart card 46 in the form of a UICC according to one embodiment, a card reader 48, radio interface circuitry 52, codec circuitry 54, a controller 56 and a memory 58. Individual circuits and elements are all of a type well known in the art.

[0089] Various embodiments described herein are described in the general context of method steps or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM), Random Access Memory (RAM), compact discs (CDs), digital versatile discs (DVD), etc. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.

[0090] Various embodiments may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/or hardware may reside, for example, on a chipset, a mobile device, a desktop, a laptop or a server. Software and web implementations of various embodiments can be accomplished with standard programming techniques with rule-based logic and other logic to accomplish various database searching steps or processes, correlation steps or processes, comparison steps or processes and decision steps or processes. Various embodiments may also be fully or partially implemented within network elements or modules. It should be noted that the words "component" and "module," as used herein and in the following claims, is intended to encompass implementations using one or more lines of software code, and/or hardware implementations, and/or equipment for receiving manual inputs.

[0091] Individual and specific structures described in the foregoing examples should be understood as constituting representative structure of means for performing specific functions described in the following the claims, although limitations in the claims should not be interpreted as constituting "means plus function" limitations in the event that the term "means" is not used therein. Additionally, the use of the term "step" in the foregoing description should not be used to construe any specific limitation in the claims as constituting a "step plus function" limitation. To the extent that individual references, including issued patents, patent applications, and non- patent publications, are described or otherwise mentioned herein, such references are not intended and should not be interpreted as limiting the scope of the following claims. [0092] The foregoing description of embodiments has been presented for purposes of illustration and description. The foregoing description is not intended to be exhaustive or to limit various embodiments to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. The embodiments discussed herein were chosen and described in order to explain the principles and the nature of various embodiments and its practical application to enable one skilled in the art to utilize various embodiments and with various modifications as are suited to the particular use contemplated. The features of the embodiments described herein may be combined in all possible combinations of methods, apparatus, modules, systems, and computer program products.

Claims

WHAT IS CLAIMED IS:

1. A method, comprising: announcing at least one identifier within an electronic service guide; distinguishing the at least one identifier by type; and associating, via a service association table, the at least one identifier with bearer-specific elements, wherein the bearer-specific elements define a signaled location of a bearer service.

2. The method according to claim 1, wherein the electronic service guide is an Open Mobile Alliance Mobile Broadcast Services Electronic Service Guide, and the bearer service is service provided over a China Multimedia Broadcasting bearer standard.

3. The method according to claim 1, wherein the bearer-specific elements include at least one of a frequency_point_number parameter, a multiplex frame identifier parameter, a multiplex sub-frame identifier parameter, and a servicelD parameter.

4. The method according to claim 1 further comprising, upon a determination that at least one of the bearer- specific elements is missing from the service association table, directing a receiver to a multiplex configuration table to obtain a full mapping between the electronic service guide and the bearer service.

5. The method according to claim 4, wherein the receiver filters at least one of a desired multiplex frame and a multiplex sub-frame from a larger set of multiple frames within the service association table.

6. The method according to claim 1, wherein the at least one identifier comprises a uniform resource identifier configured to one of directly and indirectly point to at least one the bearer service and a fragment of the bearer service within the electronic service guide.

7. The method according to claim 1 further comprising, bundling the at least one identifier with at least another identifier, and associating the bundle of the at least one identifier and the at least another identifier with one of the bearer-specific elements, the one bearer-specific element comprising a servicelD parameter.

8. A computer program product, embodied on computer-readable medium, comprising computer code configured to perform the processes according to any of claims 1 to7.

9. An apparatus, comprising: a processor and a memory including computer program code the memory and the computer program code configured to, with the processor, cause the apparatus at least to perform: announce at least one identifier within an electronic service guide; distinguish the at least one identifier by type; and associate, via a service association table, the at least one identifier with bearer-specific elements, wherein the bearer-specific elements define a signaled location of a bearer service.

10. The apparatus according to claim 9, wherein the electronic service guide is an Open Mobile Alliance Mobile Broadcast Services Electronic Service Guide, and the bearer service is service provided over a China Multimedia Broadcasting bearer standard.

11. The apparatus according to claim 9, wherein the bearer-specific elements include at least one of a frequency_point_number parameter, a multiplex frame identifier parameter, a multiplex sub-frame identifier parameter, and a servicelD parameter.

12. The apparatus according to claim 9, wherein the electronic device is further configured to, upon a determination that at least one of the bearer-specific elements is missing from the service association table, direct a receiver to a multiplex configuration table to obtain a full mapping between the electronic service guide and the bearer service.

13. The apparatus according to claim 12, wherein the receiver filters at least one of a desired multiplex frame and a multiplex sub-frame from a larger set of multiple frames within the service association table.

14. The apparatus according to claim 9, wherein the at least one identifier comprises a Uniform Resource Identifier configured to one of directly and indirectly point to at least one the bearer service and a fragment of the bearer service within the electronic service guide.

15. The apparatus according to claim 9, wherein the electronic device is further configured to bundle the at least one identifier with at least another identifier, and associate the bundle of the at least one identifier and the at least another identifier with one of the bearer-specific elements, the one bearer-specific element comprising a servicelD parameter.

16. A method comprising : searching for a bearer signal; looking for an electronic service guide, parsing the electronic service guide, and decoding metadata from the electronic service guide; searching for and storing at least one needed identifier within the electronic service guide for a desired service; accessing a first sub-frame of a first multiplex frame within the bearer signal and searching for a service association table; and discovering signaled location information for the at least one needed identifier within the service association table, the at least one needed identifier being associated with bearer-specific elements.

17. The method according to claim 16 further comprising, upon a determination that at least one of the bearer- specific elements is missing from the service association table, accessing and inspecting a multiplex configuration table to complete service discovery

18. The method according to claim 16, wherein the electronic service guide is an Open Mobile Alliance Mobile Broadcast Services Electronic Service Guide, and the bearer service is service provided over a China Multimedia Broadcasting bearer standard.

19. The method according to claim 16, wherein the bearer-specific elements include at least one of a frequency_point_number parameter, a multiplex frame identifier parameter, a multiplex sub-frame identifier parameter, and a servicelD parameter.

20. The method according to claim 16, wherein the electronic service guide is fixed to a specific servicelD of a bearer.

21. The method according to claim 16, wherein a bootstrap identifier of the electronic service guide is associated with a first identifier of the at least one needed identifier within the service association table.

22. The method according to claim 16, wherein a bootstrap identifier of the electronic service guide is associated with at least one of a first internet protocol source and internet protocol destination addresses announced within the service association table.

23. The method according to claim 16, wherein a bootstrap identifier of the electronic service guide is associated with a bootstrap service association table carried within a first multiplex frame of the bearer signal.

24. The method according to claim 23 further comprising, looking for and accessing the service association table associated with the bootstrap association service table, and discovering a location of the desired service.

25. The method according to claim 16 further comprising, upon decoding the metadata, displaying the metadata to an end-user for selection of the desired service.

26. The method according to claim 16, wherein the service association table is transmitted within a carriage of one of layer 2 signaling of a bearer, the metadata of the electronic service guide, and an interaction network.

27. A computer program product, embodied on a computer-readable, comprising computer code configured to perform the processes according to any of claims 16 to 26.

28. An apparatus comprising: a processor and a memory including computer program code the memory and the computer program code configured to, with the processor, cause the apparatus at least to perform: search for a bearer signal; look for an electronic service guide, parse the electronic service guide, and decode metadata from the electronic service guide; search for and store at least one needed identifier within the electronic service guide for a desired service; access a first sub-frame of a first multiplex frame within the bearer signal and search for a service association table; and discover signaled location information for the at least one needed identifier within the service association table, the at least one needed identifier being associated with bearer-specific elements.

29. The apparatus according to claim 28, wherein the electronic device is further configured to, upon a determination that at least one of the bearer-specific elements is missing from the service association table, access and inspect a multiplex configuration table to complete service discovery

30. The apparatus according to claim 28, wherein the electronic service guide is an Open Mobile Alliance Mobile Broadcast Services Electronic Service Guide, and the bearer service is service provided over a China Multimedia Broadcasting bearer standard.

31. The apparatus according to claim 28, wherein the bearer-specific elements include at least one of a frequency_point_number parameter, a multiplex frame identifier parameter, a multiplex sub-frame identifier parameter, and a servicelD parameter.

32. The apparatus according to claim 28, wherein the electronic service guide is fixed to a specific servicelD of a bearer.

33. The apparatus according to claim 28, wherein a bootstrap identifier of the electronic service guide is associated with a first identifier of the at least one needed identifier within the service association table.

34. The apparatus according to claim 28, wherein a bootstrap identifier of the electronic service guide is associated with at least one of a first internet protocol source and internet protocol destination addresses announced within the service association table.

35. The apparatus according to claim 28, wherein a bootstrap identifier of the electronic service guide is associated with a bootstrap service association table carried within a first multiplex frame of the bearer signal.

36. The apparatus according to claim 35, wherein the electronic device is further configured to look for and access the service association table associated with the bootstrap association service table, and discover a location of the desired service.

37. The apparatus according to claim 28, wherein the electronic device is further configured to, upon decoding the metadata, display the metadata to an end-user for selection of the desired service.

38. The apparatus according to claim 28, wherein the service association table is transmitted within a carriage of one of layer 2 signaling of a bearer, the metadata of the electronic service guide, and an interaction network.

39. The apparatus according to claim 28, wherein the electronic device comprises a receiver.

40. A method comprising: searching for a bearer signal; setting a first filter for a first time slot and waiting for a subsequent corresponding time slot, the corresponding time slot containing a bootstrap service association table; upon extracting the bootstrap service association table, creating a second filter for a bootstrap service and upon receiving bootstrap discovery information for the bootstrap service, selecting a desired electronic service guide provider; setting a third filter for an electronic service guide carousel and service association table of the selected electronic service guide provider; selecting a desired service based upon a received electronic service guide from the electronic service guide provider; and setting a filter for the desired service based on information within the electronic service guide and the service association table.

41. The method according to claim 40, wherein the bootstrap service association table is carried within a first multiplex frame of the bearer signal along with at least one Chinese Multimedia Broadcasting multiplex configuration table.

42. The method according to claim 41, wherein the bootstrap discovery information is announced in the at least one Chinese Multimedia Broadcasting multiplex configuration table.

43. The method according to claim 41 further comprising, finding a location of the bootstrap discovery information based upon a service identification accompanied by an internet protocol address pair in the bootstrap service association table.

44. The method according to claim 43, wherein location information of the location comprises a multiplex frame identification, a multiplex sub-frame identification, and a frequency point.

45. The method according to claim 40, wherein the bootstrap discovery information comprises at least one identifier of the electronic service guide provider with an internet protocol address pair.

46. The method according to claim 45, wherein the internet protocol address pair of the bootstrap discovery information is the same internet protocol address pair of the electronic service guide.

47. The method according to claim 40, wherein the selection of the desired electronic service guide provider is based upon a list of a plurality of electronic service guide providers that includes the desired electronic service guide provider available in an electronic service guide provider descriptor.

48. The method according to claim 47, wherein the electronic service guide provider descriptor specifies the plurality of electronic service guide providers that deliver a plurality of electronic service guides in a given internet protocol platform.

49. The method according to claim 40, wherein the selection of the desired electronic service guide provider is based upon one of at least one currently pending subscription to the desired service and a location of a user equipment during the searching of the bearer signal.

50. A computer program product, embodied on a computer-readable medium, comprising computer code configured to perform the processes according to any of claims 40 to 49.

51. An apparatus comprising: a processor and a memory including computer program code the memory and the computer program code configured to, with the processor, cause the apparatus at least to perform: search for a bearer signal; set a first filter for a first time slot and wait for a subsequent corresponding time slot, the corresponding time slot containing a bootstrap service association table; upon extraction of the bootstrap service association table, create a second filter for a bootstrap service, and upon receipt of bootstrap discovery information for the bootstrap service, select a desired electronic service guide provider; set a third filter for an electronic service guide carousel and service association table of the selected electronic service guide provider; select a desired service based upon a received electronic service guide from the electronic service guide provider; and set a filter for the desired service based on information within the electronic service guide and the service association table.

52. The apparatus according to claim 51, wherein the bootstrap service association table is carried within a first multiplex frame of the bearer signal along with at least one Chinese Multimedia Broadcasting multiplex configuration table.

53. The apparatus according to claim 52, wherein the bootstrap discovery information is announced in the at least one Chinese Multimedia Broadcasting multiplex configuration table.

54. The apparatus according to claim 52, wherein the electronic device is further configured to find a location of the bootstrap discovery information based upon a service identification accompanied by an internet protocol address pair in the bootstrap service association table.

55. The apparatus according to claim 54, wherein location information of the location comprises a multiplex frame identification, a multiplex sub-frame identification, and a frequency point.

56. The apparatus according to claim 51, wherein the bootstrap discovery information comprises at least one identifier of the electronic service guide provider with an internet protocol address pair.

57. The apparatus according to claim 56, wherein the internet protocol address pair of the bootstrap discovery information is the same internet protocol address pair of the electronic service guide.

58. The apparatus according to claim 51, wherein the selection of the desired electronic service guide provider is based upon a list of a plurality of electronic service guide providers that includes the desired electronic service guide provider available in an electronic service guide provider descriptor.

59. The apparatus according to claim 58, wherein the electronic service guide provider descriptor specifies the plurality of electronic service guide providers that deliver a plurality of electronic service guides in a given internet protocol platform.

60. The apparatus according to claim 51, wherein the selection of the desired electronic service guide provider is based upon one of at least one currently pending subscription to the desired service and a location of a user equipment during the searching of the bearer signal.

61. A method, comprising : announcing location information for a service identifier within a bootstrap service association table, wherein the service identifier is associated, via a service association table, with bearer-specific elements, the bearer-specific element defining a signaled location of a bearer service; and announcing bootstrap discovery information within the bootstrap service association table, the bootstrap discovery information including at least one electronic service guide provider identifier that provides an electronic service guide for the bearer service.

62. The method according to claim 61, wherein the bootstrap service association table is carried within a first multiplex frame of the bearer signal along with at least one Chinese Multimedia Broadcasting multiplex configuration table.

63. The method according to claim 62, wherein the announcing of the bootstrap discovery information occurs in the at least one Chinese Multimedia Broadcasting multiplex configuration table.

64. The method according to claim 61, wherein an internet protocol address pair for the bootstrap discovery information is announced as a first internet protocol pair within the bootstrap service association table.

65. The method according to claim 64, wherein the location information comprises a multiplex frame identification, a multiplex sub- frame identification, and a frequency point.

66. The method according to claim 61, wherein the service association table comprises an Internet Protocol Multiplex Configuration Table and the bootstrap service association table comprises an Internet Protocol Multiplex Configuration Table Association Table.

67. A computer program product, embodied on a computer-readable medium, comprising computer code configured to perform the processes according to any of claims 61 to 66.

68. An apparatus, comprising: a processor and a memory including computer program code the memory and the computer program code configured to, with the processor, cause the apparatus at least to perform: announce location information for a service identifier within a bootstrap service association table, wherein the service identifier is associated, via a service association table, with bearer-specific elements, the bearer-specific element defining a signaled location of a bearer service; and announce bootstrap discovery information within the bootstrap service association table, the bootstrap discovery information including at least one electronic service guide provider identifier that provides an electronic service guide for the bearer service.

69. The apparatus according to claim 68, wherein the bootstrap service association table is carried within a first multiplex frame of the bearer signal along with at least one Chinese Multimedia Broadcasting multiplex configuration table.

70. The apparatus according to claim 69, wherein the announcement of the bootstrap discovery information occurs in the at least one Chinese Multimedia Broadcasting multiplex configuration table.

71. The apparatus according to claim 68, wherein an internet protocol address pair for the bootstrap discovery information is announced as a first internet protocol pair within the bootstrap service association table.

72. The apparatus according to claim 70, wherein the location information comprises a multiplex frame identification, a multiplex sub- frame identification, and a frequency point.

73. The apparatus according to claim 68, wherein the service association table comprises an Internet Protocol Multiplex Configuration Table and the bootstrap service association table comprises an Internet Protocol Multiplex Configuration Table Association Table.

74. A system, comprising: means for announcing location information for a service identifier within a bootstrap service association table, wherein the service identifier is associated, via a service association table, with bearer-specific elements, the bearer-specific element defining a signaled location of a bearer service means for searching for the bearer signal; means for setting a first filter for a first time slot and waiting for a subsequent corresponding time slot, the corresponding time slot containing the bootstrap service association table; means for, upon extracting the bootstrap service association table, creating a second filter for a bootstrap service and upon receiving bootstrap discovery information for the bootstrap service, selecting a desired electronic service guide provider, wherein the bootstrap discovery information is announced within the bootstrap service association table; means for setting a third filter for an electronic service guide carousel and service association table of the selected electronic service guide provider; means for selecting a desired service based upon a received electronic service guide from the electronic service guide provider; means for setting a filter for the desired service based on information within the electronic service guide and the service association table; and receiving data for the bearer service.

75. The system according to claim 74, wherein the bootstrap service association table is carried within a first multiplex frame of the bearer signal along with at least one Chinese Multimedia Broadcasting multiplex configuration table.