Patent Description:
Evolved Multimedia Broadcast Multicast Service (eMBMS) networks have been established to provide broadcast services (e.g., Multimedia Broadcast Multicast Service (MBMS) services) to computing devices, including smartphones. An enhancement being contemplated involves broadcasting MBMS services for use by receive-only devices.

The publication "<NPL> relates to specifying the range of MBMS Service ID values reserved for the MBMS service in receive only mode.

The publication "<NPL> relates to discussions of the standardized/reserved range of TMGI for Receive only mode from the stage <NUM> perspective.

The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate example embodiments of the claims, and together with the general description given above and the detailed description given below, serve to explain the features of the claims.

References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims.

As used herein, the terms "mobile device", "receiver device", and "computing device" are used interchangeably herein to refer to any one or all of cellular telephones, smart phones, personal or mobile multi-media players, personal data assistants (PDAs), laptop computers, personal computers, tablet computers, smart books, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, satellite or cable set top boxes, streaming media players (such as, ROKU® or CHROMECAST® or FIRE TV™), smart televisions, digital video recorders (DVRs), and similar personal electronic devices which include a programmable processor and memory and circuitry for sending and/or receiving files.

The various embodiments are described herein using the term "server" to refer to any computing device capable of functioning as a server, such as a master exchange server, web server, mail server, document server, content server, or any other type of server. A server may be a dedicated computing device or a computing device including a server module (e.g., running an application that may cause the computing device to operate as a server). A server module (e.g., server application) may be a full function server module, or a light or secondary server module (e.g., light or secondary server application) that is configured to provide synchronization services among the dynamic databases on receiver devices. A light server or secondary server may be a slimmed-down version of server-type functionality that can be implemented on a receiver device thereby enabling it to function as an Internet server (e.g., an enterprise e-mail server) only to the extent necessary to provide the functionality described herein.

Evolved Multimedia Broadcast Multicast Service (eMBMS) networks have been established according to the 3rd Generation Partnership Projects (3GPP) Technical Standards (TSs). In such eMBMS networks, broadcast services (e.g., audio streaming, video streaming, etc.) may be provide as broadcast services (e.g., Multimedia Broadcast Multicast Service (MBMS) services) to computing devices.

In the signals provided by eMBMS networks, broadcast services may be identified by temporary mobile group identifiers (TMGIs). A TMGI may be generated for a broadcast service, such as an MBMS service, by combining the MBMS service ID with the mobile country code ("MCC") and mobile network code ("MNC"). The MCC and MNC may be combined to identify a core network (CN) operator by the CN operator's public land mobile network ("PLMN") ID. A TMGI may be broadcast on the broadcast channel from base stations (e.g., evolved Node Bs (eNodeBs)) in a network. The mapping between TMGIs and services may enable a computing device to determine the services available in the network and to receive one or more service by activating one or more selected TMGIs.

A service announcement (SA) is a type of broadcast service that provides information to a computing device receiving the SA describing the broadcast services available in the network and the characteristics of those broadcast services. An SA may have its own TMGI, and within the SA the TMGIs of the other services available in the network may be listed along with other information, such as the service type, codecs, service names, etc. SA services may be different from other types of broadcast services (e.g., broadcast TV services, V2X services, IoT supporting services, etc.) in that SA services may operate at the cellular network level rather than the content level like other types of broadcast services. SA services may be channel guides mapping TMGIs of broadcast services to characteristics of those services, such as service type indications.

In eMBMS networks established according to the 3GPP TSs, a computing device may listen to the broadcast channel without registering with the network. The ability to listen to the broadcast channel without registering with the network may enable receive-only mode (ROM) computing devices to receive broadcast services in a network. A ROM computing device may be a computing device that is operating such that only broadcast transmissions are received from the network. A ROM computing device may not need a subscription to a network (e.g., the ROM computing device may not include a Universal Subscriber Identity Module (USIM)). ROM computing devices may have no unicast capability and may not perform signaling with the network (e.g., no registration, no authentication, no authorization, etc.). Some ROM computing devices may be dedicated ROM computing devices with eMBMS modems that can only operate to receive broadcast signals and do not include any capability to output eMBMS signals. Other ROM computing devices may be temporary ROM computing devices that do include eMBMS modems with the capability to make and receive unicast transmission, but that are operating to only receive broadcast signals at a given time. A ROM computing device may camp on a network to receive broadcast services without registering with the network.

Broadcast services intended for use by ROM computing devices may include several different types of services (or service types). As examples, broadcast television (TV) services may be intended for use by ROM computing devices, vehicle to everything (V2X) services may be intended for use by ROM devices, Internet of Things (IoT) supporting services may be intended for use by ROM computing devices, or any other service that may be suitable for broadcast transmission may be intended for use by ROM computing devices. Some ROM computing devices may support multiple broadcast service types, such as two or more, three or more, more than three, or all broadcast services types. Some ROM computing devices may support only a single broadcast service type. Some ROM computing devices may support receiving an SA service. Some ROM computing devices may not support receiving an SA service.

To support the provisioning of services by ROM computing devices, ranges of TMGIs may be reserved for broadcast services intended for use by ROM computing devices. Special values for MCCs and MNCs that do not correspond to any actual country code and/or any network code in use by a CN operator may be reserved for use in the TMGIs of broadcast services intended for use by ROM computing devices. Such shared MCCs and MNCs may not be associated with any geographic region or CN operator. For example, an MCC value of <NUM> and an MNC value of <NUM> may be assigned to all broadcast services intended for use by ROM computing devices. In such an example, all broadcast services intended for use by ROM computing devices may have the same PLMN ID, such as <NUM>. In this manner, the TMGIs for all broadcast services intended for use by ROM computing devices may have the same PLMN ID and that PLMN ID may be CN agnostic as the PLMN ID may not correspond to any specific (or actual) CN operator's PLMN. Reserving shared PLMN IDs that may not be assigned to any specific (or actual) CN operator for all broadcast services intended for use by ROM computing devices may enable ranges of TMGIs to identify broadcast services across different geographic areas.

The different types of broadcast services intended for use by ROM computing devices, such as one or more of broadcast TV services, V2X services, IoT supporting services, SA services, etc., may be identified as broadcast services intended for use by ROM computing devices by their common PLMN ID. As the PLMN ID of such broadcast services intended for use by ROM computing devices may be CN agnostic, the same TMGIs may be assigned for broadcast services intended for use by ROM computing devices across different networks.

While a CN agnostic PLMN ID (e.g., a PLMN ID including a shared MCC value and/or a shared MNC value that does not identify any specific (or actual) CN operator) may allow broadcast services intended for use by ROM computing devices to be identified, without a constraint on the MBMS service IDs service discovery by a ROM computing device may be a trial and error approach with each possible MBMS Service ID and CN agnostic PLMN ID combination needing to be tried to acquire supported services in any network. This may take significant amounts of time as the MBMS service ID may be <NUM> bits. The amount of time to acquire supported services by trial and error may consume excessive battery charge and/or may reduce the customer experience due to the delay in acquisition. Additionally, broadcast services the ROM computing device does not support may be acquired and computing resources may be expended attempting to output unsupported services in the trial and error approach.

The systems, methods, and devices of the various embodiments enable efficient broadcast service acquisition by ROM computing devices. In various embodiments, the MBMS Service IDs for broadcast services intended for use by ROM computing devices may allocated by broadcast service type (e.g., broadcast TV services, V2X services, IoT supporting services, SA services, etc.).

In various embodiments, the MBMS Service IDs for broadcast services intended for use by ROM computing devices may be divided into ranges by broadcast service type (e.g., broadcast TV services, V2X services, IoT supporting services, etc.). The combination of the ranges of MBMS Service IDs divided by broadcast service type and a network agnostic PLMN ID (e.g., a PLMN ID including a shared MCC value and/or a shared MNC value that does not identify any specific (or actual) network operator, such as any specific (or actual) CN operator) may provide TMGIs with sub-ranges each corresponding to one type of broadcast service type. For example, as the MBMS Service ID may be a <NUM>-bit long number, the "N" most significant bits (MSB) may designate the type of service. As a specific example where N=<NUM>, the MSB of <NUM> may designate broadcast TV services, the MSB of <NUM> may designate V2X services, and the MSB of <NUM> may designate IoT supporting services.

In various embodiments, one or more MBMS service ID may be allocated for SA services. The combination of the one or more MBMS service IDs allocated for SA service and a network agnostic PLMN ID (e.g., a PLMN ID including a shared MCC value and/or a shared MNC value that does not identify any specific (or actual) network operator, such as any specific (or actual) CN operator) may provide one or more TMGI sub-ranges corresponding to one or more SA services. For example, the "M" least significant bits (LSB) may designate the SA service. As a specific example where M=<NUM>, the LSBs from <NUM> to <NUM> may be reserved for designating SA services.

In various embodiments, one or more MBMS service IDs may be allocated for SA services by broadcast service type (e.g., broadcast TV services, V2X services, IoT supporting services, etc.). The combination of the one or more MBMS service IDs allocated for SA service by broadcast service type and a network agnostic PLMN ID (e.g., a PLMN ID including a shared MCC value and/or a shared MNC value that does not identify any specific (or actual) network operator, such as any specific (or actual) CN operator) may provide one or more TMGI sub-ranges corresponding to one or more SA services for each broadcast service type. For example, the "N" most significant bits (MSBs) may designate the type of service in an MBMS service ID and the "M" least significant bits (LSBs) may designate the SA service in the MBMS service ID. As a specific example, where both N and M equal <NUM>, the MSB of <NUM> may designate broadcast TV services, the MSB of <NUM> may designate V2X services, and the LSBs from <NUM> to <NUM> may be reserved for SA services. In another example, MBMS Service ID values between <NUM><NUM><NUM><NUM> and <NUM><NUM><NUM><NUM> may be reserved for SA services for broadcast TV services and MBMS Service ID values between <NUM><NUM><NUM><NUM> and <NUM><NUM><NUM><NUM> may be reserved for SA services associated for V2X services. By using specific reserved values for the N number of MSBs and M number of LSBs, SA services for different types of services may be distinguished from other type services by only those MSBs and LSBs of the MBMS Service IDs. As such, only a portion of the MBMS Service ID (e.g., the MSBs and/or LSBs) may need to be considered by a computing device to identify the type of service and/or whether that MBMS Service ID is for SA services or not. In another example, SA services may be designated by a pre-determined set of values of MBMS service IDs in a sub-range of MBMS service IDs, such as a number of the smallest value MBMS service IDs in the sub-range. As a specific example, the sixteen smallest value MBMS service IDs in a sub-range of MBMS service IDs may be pre-determined as designating SA services.

In various embodiments, ROM computing devices may select one or more range of MBMS service IDs for a broadcast service type (e.g., broadcast TV services, V2X services, IoT supporting services, SA services, etc.) and activate sub-ranges of TMGIs based on the selected one or more range of MBMS service IDs to receive one or more broadcast services intended for use by ROM computing devices of the broadcast service type.

In various embodiments, a ROM computing device may receive a list of TMGIs for broadcast services in a network. The ROM computing device may determine whether any of the TMGIs on the list correspond to any receive-only mode (ROM) services supported by the computing device based at least in part on any of the TMGIs being within ranges allocated to the ROM services supported by the ROM computing device. The ROM computing device may acquire at least one of the supported ROM services in response to determining that any of the TMGIs on the list correspond to any of the supported ROM services. In various embodiments, the ROM computing device may receive a list of TMGIs for broadcast services in a network from a broadcast channel. The ROM computing device may determine whether any of the TMGIs on the list correspond to a ROM SA based at least in part on any of the TMGIs being within ranges allocated to ROM SA services. The ROM computing device may obtain a list of ROM service TMGIs from the ROM SA in response to determining that any of the TMGIs on the list correspond to the ROM SA. The ROM computing device may acquire a supported ROM service using at least one of the ROM service TMGIs. In various embodiments acquiring the ROM service may include determining whether any of the ROM service TMGIs correspond to a supported ROM service type. In various embodiments, acquiring at least one of the ROM services may include receiving service data over the broadcast channel, decoding the service data, and presenting the data to an application layer.

Various examples of different MBMS service ID range divisions and assignments are discussed herein; specifically, divisions by broadcast service types, MSB assignments, LSB assignments, etc. The discussions of broadcast service types, MSB assignments, and LSB assignments are provided merely as examples to better illustrate the aspects of the various embodiments, and are not intended to limit the scope of the disclosure or the claims in any way. Other MBMS service ID range divisions and assignments may be used with the various embodiments, and the other MBMS service ID range divisions and assignments may be substituted in the various examples without departing from the scope of the claims.

<FIG> illustrates a network system <NUM> suitable for use with the various embodiments. The cellular network system <NUM> may include multiple devices, such as a receiver device <NUM>, one or more cellular towers or base stations <NUM>, and one or more servers <NUM> and <NUM> connected to the Internet <NUM>. The receiver device <NUM> may exchange data via one or more cellular connections <NUM>, including Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Global System for Mobile Communications (GSM), Personal Communication Service (PCS), Third Generation (<NUM>), Fourth Generation (<NUM>), Long Term Evolution (LTE), or any other type connection, with the cellular tower or base station <NUM>. The receiver device <NUM> may be a ROM computing device operating such that only broadcast transmissions are being received from the one or more cellular towers or base stations <NUM> at a given time. The cellular tower or base station <NUM> may be in communication with a router that may connect to the Internet <NUM>. In this manner, data may be exchanged between the receiver device <NUM> and the server(s) <NUM> and <NUM> via the connections to the cellular tower or base station <NUM>, and/or Internet <NUM>. In an embodiment, server <NUM> may be a web server or content provider server, such as a Content Delivery Network (CDN) server, providing files for delivery to computing devices, such as receiver device <NUM>. In an embodiment, server <NUM> may be network operator server, such as a Broadcast Multimedia Service Center (BMSC) server, that may receive files, such as files from server <NUM>, and control the Over-the-Air (OTA) transmission of the files to the receiver device <NUM>. For example, a network operator server <NUM> may control the content server <NUM> and the cellular network including the receiver device <NUM> and the cellular tower or base station <NUM> to provide one or more service to the receiver device <NUM> via broadcast OTA transmissions. While features of embodiment receiver devices and networks may be described with reference to OTA transmissions, these features may be used in connection with wired transmissions, wireless transmissions, or a combination of wired and wireless transmissions. Thus, OTA transmission is not required.

<FIG> illustrates an embodiment method <NUM> for MBMS Service provisioning. In various embodiments, the operations of method <NUM> may be performed by processor of a server, such as servers <NUM> and/or <NUM> described with reference to <FIG>.

In block <NUM> the processor may determine a service type of one or more broadcast services intended for use by a ROM computing device. In various embodiments, service types may reflect the nature of the content provided by a service intended for use by a ROM computing device. As examples, service types may include broadcast TV services, V2X services, IoT supporting services, SA services, etc. Based on the content to be provided by a service, the processor may determine the service type of that broadcast service.

In block <NUM> the processor may assign an MBMS service ID to each broadcast service based at least in part on that broadcast service's determined service type. In various embodiments, the MBMS Service IDs for broadcast services intended for use by ROM computing devices may be divided into ranges by broadcast service type (e.g., broadcast TV services, V2X services, IoT supporting services, SA services, etc.). The processor may assign each broadcast service's respective MBMS service ID by correlating the determined service type for that broadcast service to the service type corresponding with each range of MBMS service IDs. An MBMS service ID from the corresponding range may be selected and designated for that specific broadcast service, thereby assigning the MBMS Service ID to that broadcast service.

In some embodiments, the MSBs of the MBMS Service ID may designate the service type of the broadcast service to which the MBMS Service ID may be assigned. For example, as the MBMS Service ID may be a <NUM>-bit long number, the "N" MSBs may designate the type of service. As a specific example where N=<NUM>, the MSB of <NUM> may designate broadcast TV services, the MSB of <NUM> may designate V2X services, and the MSB of <NUM> may designate IoT supporting services.

In some embodiments, a number of LSBs may designate the determined service type is an SA service in MBMS Service IDs set aside for SA services. For example, the "M" LSBs may designate the SA service. As a specific example where M=<NUM>, the LSBs from <NUM> to <NUM> may be reserved for SA services.

In some embodiments, one or more MBMS service IDs may be allocated for SA services within the ranges designated for specific broadcast services (e.g., broadcast TV services, V2X services, IoT supporting services, etc.). By using specific reserved values for the N number of MSBs and M number of LSBs, SA services for different types of services may be distinguished from other type services by only those MSBs and LSBs of the MBMS Service IDs. As such, only a portion of the MBMS Service ID (e.g., the MSBs and/or LSBs) may need to be considered by a computing device to identify the type of service and/or whether that MBMS Service ID is for SA services or not. For example, the "N" most significant bits (MSBs) may designate the type of service in an MBMS service ID and the "M" least significant bits (LSBs) may designate the SA service in the MBMS service ID. As a specific example in which both N and M equal <NUM>, the MSB of <NUM> may designate broadcast TV services, the MSB of <NUM> may designate V2X services, and the LSBs from <NUM> to <NUM> may be reserved for SA services. In such an example, MBMS Service ID values between <NUM><NUM><NUM><NUM> and <NUM><NUM><NUM><NUM> may be reserved for SA services for broadcast TV services and MBMS Service ID values between <NUM><NUM><NUM><NUM> and <NUM><NUM><NUM><NUM> may be reserved for SA services associated for V2X services. In another example, SA services may be designated by a pre-determined set of values of MBMS service IDs in a sub-range of MBMS service IDs, such as a number of the smallest value MBMS service IDs in the sub-range. As a specific example, the sixteen smallest value MBMS service IDs in a sub-range of MBMS service IDs may be pre-determined as designating SA services.

In block <NUM> the processor may combine each MBMS service ID with a CN agnostic PLMN ID to generate a TMGI for each respective broadcast service. In various embodiments, a CN agnostic PLMN ID may be a PLMN ID including a shared MCC value and/or a shared MNC value that does not identify any specific (or actual) CN operator. Such shared MCCs and MNCs may not be associated with any geographic region or CN operator. In various embodiments, a designated CN agnostic PLMN ID may be reserved for broadcast services intended for use by ROM computing devices. For example, an MCC value of <NUM> and an MNC value of <NUM> may be assigned to all broadcast services intended for use by ROM computing devices. As another example, an MCC value of <NUM> and an MNC value of <NUM> may be assigned to all broadcast services intended for use by ROM computing devices. By reserving MCC values and MNC values to services for use by ROM computing devices, shared PLMN IDs that do not identify any specific (or actual) CN operator may be created. The combination of the ranges of MBMS Service IDs divided by broadcast service type and a CN agnostic PLMN ID may provide TMGIs with sub-ranges each corresponding to one type of broadcast service type (e.g., sub-ranges of TMGIs for one or more of broadcast TV services, V2X services, IoT supporting services, SA services, etc.).

In block <NUM>, the processor may broadcast each respective service with the generated TMGI for that broadcast service. In this manner, networks may provide broadcast services intended for ROM computing devices using the generated TMGIs. ROM computing devices may activate TMGIs in the sub-ranges for a selected broadcast service type to receive one or more broadcast services of that service type (e.g., activate TMGIs in a sub-range for one or more broadcast TV services, activate TMGIs in a sub-range for one or more V2X services, activate TMGIs in a sub-range for one or more IoT supporting services, activate TMGIs in a sub-range for one or more SA services, etc.).

<FIG> illustrates a method <NUM> for MBMS Service provisioning according to some embodiments. In various embodiments, the operations of the method <NUM> may be performed by a processor of a server, such as servers <NUM> and/or <NUM> described with reference to <FIG>. In various embodiments, the operations of the method <NUM> may be performed in conjunction with the operations of the method <NUM> described with reference to <FIG>.

In block <NUM>, the processor may determine a service type of one or more broadcast services. In various embodiments, service types may reflect the nature of the content provided by a service intended for use by a computing device, such as a ROM computing device or any other type computing device. Based on the content to be provided by a service, the processor may determine the service type of that broadcast service.

In block <NUM>, the processor may assign an MBMS service ID to each broadcast service based at least in part on that broadcast service's determined type. In various embodiments, the MBMS Service IDs for broadcast services may be divided into ranges by broadcast service type (e.g., broadcast TV services, V2X services, IoT supporting services, SA services, etc.). The processor may assign each broadcast service's respective MBMS service ID by correlating the determined service type for that broadcast service to the service type corresponding with each range of MBMS service IDs. An MBMS service ID from the corresponding range may be selected and designated for that specific broadcast service, thereby assigning the MBMS Service ID to that broadcast service.

In some embodiments, a number of LSBs may designate the determined service type is an SA service in MBMS Service IDs set aside for SA services. For example, the "M" LSBs may designate the SA service. As a specific example in which M=<NUM>, the LSBs from <NUM> to <NUM> may be reserved for SA services.

In block <NUM>, the processor may combine each MBMS service ID with a PLMN ID to generate a TMGI for each respective broadcast service. In various embodiments, the PLMN ID may be a PLMN ID associated with a CN operator or assigned to designate a specific entity, such as a PLMN ID including a MCC value and/or a MNC value that does identify a specific (or actual) CN operator or other specific entity. In various embodiments, the PLMN ID may be a CN agnostic PLMN ID, and the CN agnostic PLMN ID may be a PLMN ID including a shared MCC value and/or a shared MNC value that does not identify any specific (or actual) CN operator. Such shared MCCs and MNCs may not be associated with any geographic region or CN operator. In various embodiments, a designated CN agnostic PLMN ID may be reserved for types of broadcast services, such as broadcast services intended for use by ROM computing devices. For example, an MCC value of <NUM> and an MNC value of <NUM> may be assigned to all broadcast services intended for use by ROM computing devices. By reserving MCC values and MNC values to types of broadcast services, shared PLMN IDs that do not identify any specific (or actual) CN operator may be created. The combination of the ranges of MBMS Service IDs divided by broadcast service type and a CN agnostic PLMN ID may provide TMGIs with sub-ranges each corresponding to one type of broadcast service type (e.g., sub-ranges of TMGIs for one or more of broadcast TV services, V2X services, IoT supporting services, SA services, etc.).

<FIG> illustrates an embodiment method <NUM> for MBMS Service provisioning. In various embodiments, the operations of method <NUM> may be performed by a processor of a server, such as servers <NUM> and/or <NUM> described with reference to <FIG>. In various embodiments, the operations of the method <NUM> may be performed in conjunction with the operations of one or more of the methods <NUM> or <NUM> described with reference to <FIG> and <FIG>, respectively.

In optional block <NUM> the processor may determine a service type of broadcast services described in each respective SA service intended for use by a ROM computing device. Block <NUM> may be optional as MBMS Service ID ranges assigned to SA services may not be sub-divided into sub-ranges based on service types. In optional embodiments in which MBMS Service ID ranges assigned to SA services may be sub-divided into sub-ranges based on service types, service types may reflect the nature of the content provided by a service intended for use by a ROM computing device that is described in a SA. As examples, SA services may be provisioned on a service type basis with separate SA services for broadcast TV services, V2X services, IoT supporting services, etc. Based on the content to be provided by a service described in the SA, the processor may determine a service type of broadcast services described in each respective SA service intended for use by a ROM computing device in optional block <NUM>.

In block <NUM>, the processor may assign an MBMS service ID to each broadcast SA service intended for use by a ROM computing device from a sub-range of MBMS service IDs reserved for SA services. In various embodiments, a range of MBMS service IDs may be allocated for SA services. The processor may assign each SA service's respective MBMS service ID by selecting and designated for that specific SA service one of the MBMS service IDs in the range allocated for SA services. For example, the "M" LSBs may designate the SA service. As a specific example where M=<NUM>, the LSBs from <NUM> to <NUM> may be reserved for SA services such that MBMS Service IDs with LSBs from <NUM> to <NUM> represent the range of MBMS service IDs allocated for SA services.

In optional embodiments in which the MBMS Service ID range allocated to SA services may be sub-divided into sub-ranges based on service types, the processor may assign each SA service's respective MBMS service ID by correlating the determined service type service type of broadcast services described in that respective SA to the service type corresponding with each sub-range of MBMS service IDs in the MBMS Service ID range allocated to SA services. An MBMS service ID from the corresponding range may be selected and designated for that specific broadcast service, thereby assigning the MBMS Service ID to that broadcast service. For example, the "N" most significant bits (MSBs) may designate the type of service in an MBMS service ID and the "M" least significant bits (LSBs) may designate the SA service in the MBMS service ID. As a specific example where both N and M equal <NUM>, the MSB of <NUM> may designate broadcast TV services, the MSB of <NUM> may designate V2X services, and the LSBs from <NUM> to <NUM> may be reserved for SA services, MBMS Service ID values between <NUM><NUM><NUM><NUM> and <NUM><NUM><NUM><NUM> may be reserved for SA services for broadcast TV services and MBMS Service ID values between <NUM><NUM><NUM><NUM> and <NUM><NUM><NUM><NUM> may be reserved for SA services associated for V2X services. In another example, SA services may be designated by a pre-determined set of values of MBMS service IDs in a sub-range of MBMS service IDs, such as number of the smallest value MBMS service IDs in the sub-range. As a specific example, the sixteen smallest value MBMS service IDs in a sub-range of MBMS service IDs may be pre-determined as designating SA services.

In block <NUM>, the processor may combine each MBMS service ID with a CN agnostic PLMN ID to generate a TMGI for each respective SA service. In various embodiments, a CN agnostic PLMN ID may be a PLMN ID including a shared MCC value and/or a shared MNC value that does not identify any specific (or actual) CN operator. In various embodiments, a designated CN agnostic PLMN ID may be reserved for broadcast services intended for use by ROM computing devices. For example, a MCC value of <NUM> and an MNC value of <NUM> may be assigned to all broadcast services intended for use by ROM computing devices. The combination of the range (and/or optional sub-range) of MBMS Service IDs allocated for SA services and a CN agnostic PLMN ID may provide TMGIs with a range (and/or optionally sub-range) corresponding to SA services (and/or optionally the SA services describing types of broadcast service type, such as sub-ranges of TMGIs for SA services for broadcast TV services, V2X services, IoT supporting services, etc.).

In block <NUM>, the processor may broadcast each respective SA service with the generated TMGI for that broadcast service. In this manner, networks may provide SA services intended for ROM computing devices using the generated TMGIs. ROM computing devices may activate TMGIs in the range (or optionally sub-range) to receive an SA service. The SA service may describe broadcast services intended for ROM computing devices in the network (for example, indicating the TMGI for the broadcast services intended for ROM computing devices in the network), and the ROM computing device may activate the TMGIs for the broadcast services indicated in the SA service to receive files for those services.

<FIG> illustrates an embodiment method <NUM> for MBMS Service reception. In various embodiments, the operations of the method <NUM> may be performed by a processor of a ROM computing device, such as the receiver device <NUM> described with reference to <FIG>. In various embodiments, the operations of the method <NUM> may be performed by a ROM computing device processor to receive broadcast services broadcast based at least in part using the operations of one or more of the methods <NUM>, <NUM>, or <NUM> described with reference to <FIG>, <FIG>, and <FIG>, respectively.

In block <NUM>, the processor may activate one or more TMGIs from a sub-range of TMGIs corresponding to supported service types of broadcast services intended for use by ROM computing devices. In various embodiments, a processor of a ROM computing device may obtain TMGIs in a sub-range of TMGIs corresponding to supported service types of broadcast services intended for use by ROM computing devices and may activate sequentially and/or simultaneously all or part of the obtained TMGIs to attempt to receive broadcast services from a network. The obtained TMGIs may correspond to supported service types (e.g., broadcast TV services, V2X services, IoT supporting services, SA services, etc.) for the ROM computing device. The obtained TMGIs may be received by the processor in various manners, such as from an application running on the processor, out-of-band transmissions, pre-configured memory available to the processor, etc. As an example, a ROM computing device configured to receive broadcast TV services may activate a TMGI in a sub-range of TMGIs allocated to broadcast TV services. As another example, a ROM computing device configured to receive V2X services may activate a TMGI in a sub-range of TMGIs allocated to V2X services. As a further example, a ROM computing device configured to receive IoT supporting services may activate a TMGI in a sub-range of TMGIs allocated to IoT supporting services. As yet another example, a ROM computing device configured to receive SA services may activate a TMGI in a sub-range of TMGIs allocated to SA services. As a still further example, a ROM computing device configured to receive SA services and a specific type of broadcast services (e.g., broadcast TV services) may activate a TMGI in a sub-range of TMGIs allocated to SA services for that specific type of broadcast service (e.g., a sub-range of TMGIs for broadcast TV service SA services). As discussed with reference to <FIG> and <FIG>, the sub-ranges of TMGIs may be created by a network server by combining sub-ranges of MBMS service IDs with a CN agnostic PLMN ID.

In determination block <NUM>, the processor may determine whether one or more supported broadcast services are available. For example, the processor may determine whether files for a supported service are received via one or more activated TMGIs to determine whether one or more supported broadcast services are available.

In response to determining that one or more supported broadcast services are available (i.e., determination block <NUM> = "Yes"), the processor may receive the one or more supported broadcast services in block <NUM>. Receiving the one or more supported broadcast services may include receiving files for the one or more service and consuming those files (e.g., outputting video or audio date for a service, using an SA file to select other TMGIs to activate to receive broadcast services, etc.). As a specific example, receiving the one or more supported broadcast services may include receiving an SA service describing TMGIs of one or more other broadcast services, such as one or more other broadcast services intended for use by ROM computing devices.

In response to determining that one or more supported broadcast services are not available (i.e., determination block <NUM> = "No"), the processor may indicate an error in block <NUM>.

In block <NUM> a processor may receive a list of TMGIs. For example, a processor of a ROM computing device may receive a list of TMGIs for broadcast services in a network from a broadcast channel.

In determination block <NUM> the processor may determine whether any TMGI on the list of TMGIs is in a useful range of TMGIs. In various embodiments, the processor may determine whether any TMGI on the list of TMGIs is in a useful range of TMGIs by determining whether any of the TMGIs on the list correspond to any receive-only mode services supported by the ROM computing device based at least in part on any of the TMGIs being within ranges allocated to the ROM services supported by the ROM computing device. In various embodiments, the processor may determine whether any TMGI on the list of TMGIs is in a useful range of TMGIs by determining whether any of the TMGIs on the list correspond to a ROM SA based at least in part on any of the TMGIs being within ranges allocated to ROM SA services. The processor may obtain a list of ROM service TMGIs from the ROM SA in response to determining that any of the TMGIs on the list correspond to the ROM SA.

In response to determining that no TMGI on the list of TMGIs is in a useful range of TMGIs (i.e., determination block <NUM> = "No"), the processor may indicate an error in block <NUM>. In response to determining that any TMGI on the list of TMGIs is in a useful range of TMGIs (i.e., determination block <NUM> = "Yes"), in block <NUM> the processor may acquire one or more service corresponding to the TMGIs in the useful range. Acquiring the one or more services may include acquiring one or more supported ROM services. In various embodiments acquiring a service may include determining whether any of the ROM service TMGIs correspond to a supported ROM service type. In various embodiments, acquiring a service may include receiving service data over the broadcast channel, decoding the service data, and presenting the data to an application layer.

The various embodiments (including, but not limited to, embodiments discussed above with reference to <FIG>) may be implemented in any of a variety of the computing devices (e.g., ROM computing devices), an example of which is illustrated in <FIG>. For example, the mobile device <NUM> may include a processor <NUM> coupled to a touch screen controller <NUM> and an internal memory <NUM>. The processor <NUM> may be one or more multicore integrated circuits (ICs) designated for general or specific processing tasks. The internal memory <NUM> may be volatile or non-volatile memory, and may also be secure and/or encrypted memory, or unsecure and/or unencrypted memory, or any combination thereof. The touch screen controller <NUM> and the processor <NUM> may also be coupled to a touch screen panel <NUM>, such as a resistive-sensing touch screen, capacitive-sensing touch screen, infrared sensing touch screen, etc. The mobile device <NUM> may have one or more radio signal transceivers <NUM> (e.g., Peanut®, Bluetooth®, Zigbee®, Wi-Fi, RF, cellular, etc.) and antennae <NUM>, for sending and receiving, coupled to each other and/or to the processor <NUM>. The transceivers <NUM> and antennae <NUM> may be used with the above-mentioned circuitry to implement the various wireless transmission protocol stacks and interfaces. The mobile device <NUM> may include one or more cellular network wireless modem chips <NUM>, such as one cellular network wireless modem chip, two cellular network wireless modem chips, three cellular network wireless modem chips, four cellular network wireless modem chips, or more than four cellular network wireless modem chips, that enables communication via one or more cellular networks and that are coupled to the processor <NUM>. The one or more cellular network wireless modem chips <NUM> may enable the mobile device <NUM> to receive broadcast services from one or more cellular networks (e.g., CDMA, TDMA, GSM, PCS, <NUM>, <NUM>, LTE, or any other type of cellular network).

The mobile device <NUM> may include a peripheral device connection interface <NUM> coupled to the processor <NUM>. The peripheral device connection interface <NUM> may be singularly configured to accept one type of connection, or multiply configured to accept various types of physical and communication connections, common or proprietary, such as USB, FireWire, Thunderbolt, Ethernet, or PCIe. The peripheral device connection interface <NUM> may also be coupled to a similarly configured peripheral device connection port (not shown). The mobile device <NUM> may also include speakers <NUM> for providing audio outputs.

The mobile device <NUM> may also include a housing <NUM>, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components discussed herein. The mobile device <NUM> may include a power source <NUM> coupled to the processor <NUM>, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the mobile device <NUM>.

The various embodiments (including, but not limited to, embodiments discussed above with reference to <FIG>) may also be implemented on any of a variety of commercially available server devices, such as the server <NUM> illustrated in <FIG>. Such a server <NUM> typically includes a processor <NUM> coupled to volatile memory <NUM> and a large capacity nonvolatile memory, such as a disk drive <NUM>. The server <NUM> may also include a floppy disc drive, compact disc (CD) or digital versatile disc (DVD) disc drive <NUM> coupled to the processor <NUM>. The server <NUM> may also include one or more wired or wireless network transceivers <NUM>, such one or more network access ports and/or wired or wireless modems (e.g., one wireless modem, two wireless modems, three wireless modems, four wireless modems, or more than four wireless modems), coupled to the processor <NUM> for establishing network interface connections with one or more communication networks <NUM>, such as a local area network (e.g., Ethernet, etc.) coupled to other computing devices and/or servers, the Internet, the public switched telephone network, and/or one or more cellular networks (e.g., CDMA, TDMA, GSM, PCS, <NUM>, <NUM>, LTE, or any other type of cellular network).

The various embodiments (including, but not limited to, embodiments discussed above with reference to <FIG>), may be implemented in any of a variety of receiver devices (e.g., a ROM computing device), an example of which is illustrated in <FIG>. The receiver device <NUM> may include a processor <NUM> and an internal memory <NUM>. The processor <NUM> may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory <NUM> may be volatile or non-volatile memory, and may also be secure and/or encrypted memory, or unsecure and/or unencrypted memory, or any combination thereof. In another embodiment (not shown), the receiver device <NUM> may also be coupled to an external memory, such as an external hard drive.

The receiver device <NUM> may have one or more satellite, cable, or terrestrial tuners <NUM> coupled to the processor <NUM>. The one or more tuners <NUM> may be used with the above-mentioned circuitry to receive and tune signals (e.g., television signals) received from a transmitter system (not shown) over a physical connection <NUM> (e.g., a connection to a cable network, a connection to an antenna, etc.).

The receiver device <NUM> may have one or more radio signal transceivers <NUM> (e.g., Peanut®, Bluetooth®, Zigbee®, Wi-Fi, RF, cellular, etc.) and antennae <NUM>, for sending and receiving, coupled to each other and/or to the processor <NUM>. The transceivers <NUM> and antennae <NUM> may be used with the above-mentioned circuitry to implement the various wireless transmission protocol stacks and interfaces. The receiver device <NUM> may include one or more cellular network wireless modem chips <NUM>, such as one cellular network wireless modem chip, two cellular network wireless modem chips, three cellular network wireless modem chips, four cellular network wireless modem chips, or more than four cellular network wireless modem chips, that enables communication via one or more cellular networks and that are coupled to the processor <NUM>. The one or more cellular network wireless modem chips <NUM> may enable the receiver device <NUM> to receive broadcast services from one or more cellular networks (e.g., CDMA, TDMA, GSM, PCS, <NUM>, <NUM>, LTE, or any other type of cellular network).

The receiver device <NUM> may include a peripheral device connection interface <NUM> coupled to the processor <NUM>. The peripheral device connection interface <NUM> may be singularly configured to accept one type of connection, or may be configured to accept various types of physical and communication interfaces/connections, common or proprietary, such as USB, FireWire, Thunderbolt, or PCIe. The peripheral device connection interface <NUM> may also be coupled to a similarly configured peripheral device connection port (not shown), such as a connection port included on a conditional access module <NUM> in communication with the receiver device <NUM>.

The receiver device <NUM> may also include speakers <NUM> for providing audio outputs. The receiver device <NUM> may also include a housing <NUM>, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components discussed herein. The receiver device <NUM> may be connected to a power source (not shown), such as a wall outlet. The receiver device <NUM> may also include a physical button <NUM> for receiving user inputs. The receiver device <NUM> may also include a display screen <NUM> coupled to the processor <NUM> and used for displaying visual images, such as television programs, etc..

The processors <NUM>, <NUM>, and <NUM> may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described above. In some devices, multiple processors may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory before they are accessed and loaded into the processors <NUM>, <NUM>, and <NUM>. The processors <NUM>, <NUM>, and <NUM> may include internal memory sufficient to store the application software instructions. In many devices, the internal memory may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to memory accessible by the processors <NUM>, <NUM>, and <NUM> including internal memory or removable memory plugged into the device and memory within the processors <NUM>, <NUM>, and <NUM> themselves.

In various embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or non-transitory processor-readable medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory server-readable, computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory server-readable, computer-readable or processor-readable media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes CD, laser disc, optical disc, DVD, floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory server-readable, computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory server-readable, processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.

Claim 1:
A method for Multimedia Broadcast Multicast Service, MBMS, Service provisioning for use by a receive only mode, ROM, computing device, comprising:
assigning a MBMS Service Identifier, ID, to each of one or more broadcast services based at least in part on the service type of that broadcast service, wherein the service type reflects the nature of the content provided by a service intended for use by a ROM computing device (<NUM>) and wherein the service type is one or more of a broadcast television service, a vehicle to everything service, or an Internet of Things supporting service;
combining each MBMS Service ID with a public land mobile network, PLMN, ID to generate a Temporary Mobile Group Identifier, TMGI, for each respective broadcast service (<NUM>); and
broadcasting each respective broadcast service with the generated TMGI for that broadcast service (<NUM>).