WO2017105522A1

WO2017105522A1 - PROVIDING EVOLVED MULTIMEDIA BROADCAST MULTICAST (eMBMS) SERVICES TO USER EQUIPMENTS

Info

Publication number: WO2017105522A1
Application number: PCT/US2015/066933
Authority: WO
Inventors: Ajay Panchal; Birgit Breining
Original assignee: Intel IP Corporation
Priority date: 2015-12-18
Filing date: 2015-12-18
Publication date: 2017-06-22

Abstract

Technology for a user equipment (UE) operable to receive Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling from a base station is disclosed. The UE can identify a bootstrap file that includes eMBMS configuration information that enables the UE to receive eMBMS services from the base station. The UE can establish a connection with the base station when a defined eMBMS service is to be received at the UE from the base station. The UE can identify a defined set of multicast-broadcast single- frequency network (MBSFN) subframes to receive multicast traffic channel (MTCH) data for the defined eMBMS service based on the eMBMS configuration information included in the bootstrap file. The UE can receive from the base station the MTCH data for the eMBMS service on the defined set of MBSFN subframes.

Description

PROVIDING EVOLVED MULTIMEDIA BROADCAST

MULTICAST (eMBMS) SERVICES TO USER EQUIPMENTS

BACKGROUND

[0001] Wireless mobile communication technology uses various standards and protocols to transmit data between a node (e.g., a transmission station) and a wireless device (e.g., a mobile device). Some wireless devices communicate using orthogonal frequency-division multiple access (OFDMA) in a downlink (DL) transmission and single carrier frequency division multiple access (SC-FDMA) in uplink (UL). Standards and protocols that use orthogonal frequency-division multiplexing (OFDM) for signal transmission include the third generation partnership project (3 GPP) long term evolution (LTE), the Institute of Electrical and Electronics Engineers (IEEE) 1102.16 standard (e.g., 1102.16e, 1102.16m), which is commonly known to industry groups as WiMAX (Worldwide interoperability for Microwave Access), and the IEEE 1102.11 standard, which is commonly known to industry groups as WiFi.

[0002] In 3GPP radio access network (RAN) LTE systems, the node can be a

combination of Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node Bs (also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs) and Radio Network Controllers (RNCs), which communicates with the wireless device, known as a user equipment (UE). The downlink (DL) transmission can be a

communication from the node (e.g., eNodeB) to the wireless device (e.g., UE), and the uplink (UL) transmission can be a communication from the wireless device to the node.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Features and advantages of the disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the disclosure; and, wherein:

[0004] FIG 1 illustrates a legacy enhanced multimedia broadcast and multicast services (eMBMS) signaling procedure for user equipments (UEs) in accordance with an example;

[0005] FIG 2 illustrates a novel enhanced multimedia broadcast and multicast services (eMBMS) signaling procedure for user equipments (UEs) in accordance with an example; [0006] FIG. 3 A illustrates a legacy temporary mobile group identifier (TMGI) update procedure in an enhanced multimedia broadcast and multicast services (eMBMS) system in accordance with an example;

[0007] FIG. 3B illustrates a novel temporary mobile group identifier (TMGI) update procedure in an enhanced multimedia broadcast and multicast services (eMBMS) system in accordance with an example;

[0008] FIG 4 illustrates an enhanced multimedia broadcast and multicast services (eMBMS) system for cellular Internet of Things (CIoT) devices in accordance with an example;

[0009] FIG. 5 illustrates a temporary mobile group identifier (TMGI) transmission repetition procedure in accordance with an example;

[0010] FIG 6 illustrates an enhanced multimedia broadcast and multicast services (eMBMS) procedure for cellular Internet of Things (CIoT) devices in accordance with an example;

[0011] FIG 7 illustrates a signaling procedure to update a bootstrap file that includes enhanced multimedia broadcast and multicast services (eMBMS) configuration information at a user equipment (UE) in accordance with an example;

[0012] FIG. 8 depicts functionality of a user equipment (UE) operable to receive Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling from a base station in accordance with an example;

[0013] FIG. 9 depicts functionality of a base station operable to provide Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling to a cellular Internet of Things (CIoT) device in accordance with an example;

[0014] FIG 10 depicts a flowchart of a machine readable storage medium having instructions embodied thereon for communicating Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling between a cellular Internet of Things (CIoT) device and a base station in accordance with an example;

[0015] FIG 11 illustrates a diagram of a wireless device (e.g., UE) in accordance with an example; and [0016] FIG 12 illustrates a diagram of a wireless device (e.g., UE) in accordance with an example.

[0017] Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the technology is thereby intended.

DETAILED DESCRIPTION

[0018] Before the present technology is disclosed and described, it is to be understood that this technology is not limited to the particular structures, process actions, or materials disclosed herein, but is extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular examples only and is not intended to be limiting. The same reference numerals in different drawings represent the same element. Numbers provided in flow charts and processes are provided for clarity in illustrating actions and operations and do not necessarily indicate a particular order or sequence.

EXAMPLE EMBODIMENTS

[0019] An initial overview of technology embodiments is provided below and then specific technology embodiments are described in further detail later. This initial summary is intended to aid readers in understanding the technology more quickly but is not intended to identify key features or essential features of the technology nor is it intended to limit the scope of the claimed subject matter.

[0020] The on-going commercialization of LTE networks has precipitated increasing interest in the deployment of enhanced multimedia broadcast and multicast services (eMBMS). The LTE version of Multimedia Broadcast Multicast Services (MBMS) is eMBMS. MBMS is a point-to-multipoint interface specification designed to provide efficient delivery of broadcast and multicast services. MBMS can be applicable to mobile television (TV) and radio broadcasting, as well as file delivery and emergency alerts. MBMS, which is specified in 3 GPP TS 26.346 Releases 6-12, is a point-to-multipoint system utilized on cellular networks operating in accordance with one of the cellular standards promulgated by the 3GPP. MBMS is designed for efficient delivery of popular media content to a plurality of receivers based on broadcast and multicast techniques. At the service layer, MBMS defines delivery protocols for both streaming of multimedia content and reliable download of files, based on the user datagram protocol (UDP) at the transport layer, and using real-time transmission protocol (RTP) for streaming and File Delivery over Unidirectional Transport (FLUTE) for file delivery.

[0021] In one example, eMBMS technology can be utilized by cellular Internet of Things (CIoT) devices. CIoT devices can also be referred to as machine type communication (MTC) devices. In one example, CIoT devices can use eMBMS for certain services, such as software updates and configuration updates. The CIoT device can receive the eMBMS services in a periodic manner, such as once a day, week, month, etc. These eMBMS service configurations for the CIoT devices may not change frequently, as compared to other online streaming services received at non-CIoT devices (e.g., UEs that stream media content). Rather, the eMBMS services received by CIoT devices can be more static across the eMBMS cellular network.

[0022] In one example, eMBMS technology can be particularly disadvantageous to CIoT devices. For example, eMBMS technology is associated with a relatively high signaling overhead for the device (e.g., CIoT or non-CIoT device) receiving the eMBMS services, which is especially unsuitable for CIoT devices. A desired battery life for CIoT devices is approximately ten years, and excess signaling from the CIoT devices to the network can reduce a lifespan of the CIoT device's battery. Therefore, for CIoT devices that receive such eMBMS services, eMBMS signaling can be restricted in the interest of power consumption and network signaling load reduction.

[0023] In the present technology, since eMBMS service configurations for CIoT devices generally change infrequently, these eMBMS service configurations can be pre-stored in the CIoT device. More specifically, the eMBMS service configurations can be included in a bootstrap file, which is stored in the CIoT device. When the CIoT is due to receive a particular eMBMS service, the corresponding eMBMS service configuration that is pre- stored at the CIoT device can be accessed and used by the CIoT device to receive the eMBMS service. As a result, the CIoT device can reduce signaling overhead and power consumption since the CIoT device does not interact with the eMBMS cellular network to determine which eMBMS services are available from the eMBMS cellular network. Rather, the CIoT device can receive the eMBMS services based on pre-stored

configurations.

[0024] FIG 1 illustrates an example of a legacy enhanced multimedia broadcast and multicast services (eMBMS) signaling procedure for user equipments (UEs). For example, a user equipment (UE) 130 can receive eMBMS services from a base station 140. The UE 130 can be a cellular Internet of Things (CIoT) device or a machine type communication (MTC) device. The UE 130 can include eMBMS middleware 110 and a modem 120. The eMBMS middleware 110 can be executed on an application processor of the UE 130, and the modem 120 can be associated with a baseband processor (or transceiver) of the UE 130. The eMBMS middleware 110 can reside in a higher layer, such as an application layer of the UE 130. The eMBMS middleware 110 can interface with the modem 120 within the UE 130. The modem 120 can communicate with the base station 140 in order to receive eMBMS services from the base station 140.

[0025] In one example, in action 1, a bootstrap file can be stored in the eMBMS middleware 110 of the UE 130. The bootstrap file can be pre-stored at an initial setup. In one example, the bootstrap file can already be stored at the UE 130 upon purchase of the UE 130, or the bootstrap file can be downloaded from a service provider during an initial setup procedure of the UE 130. The bootstrap file can include a configuration to acquire a service announcement (or a SA-TMGI). The service announcement can be similar to a television channel guide. For example, the service announcement can include a list of available eMBMS services (or a configuration of the eMBMS services). The service announcement can include times during which each of the eMBMS services are to be transmitted, the frequency at which each of the eMBMS services are to be transmitted, etc. Based on the bootstrap file, the UE 130 is configured to receive the service announcement when the UE 130 camps on a cell formed by the base station 140.

[0026] In action 2, the UE 130 can be switched on, and the UE 130 can camp on a suitable or available cell (e.g., a cell formed by the base station 140) in order to receive the eMBMS services. In action 2.1, the eMBMS middleware 110 can send a service announcement temporary mobile group identifier (SA-TMGI) request message to the modem 120, which indicates to the modem 120 to retrieve the service announcement from the base station 140. In other words, the eMBMS middleware 110 may wish to know the list of upcoming eMBMS services. In action 3, the modem 120 can receive a system information block 2 (SIB2) from the base station 140, wherein the SIB2 includes a multicast-broadcast single-frequency network (MBSFN) subframe configuration list. In action 3.1, the UE 130 can reserve MBSFN subframes for eMBMS. In action 4, the modem 120 can receive a system information block 13 (SIB13) from the base station 140, wherein the SIB 13 includes a MBSFN area information list and a notification

configuration. In action 4.1, the UE 130 can be configured to receive a MBMS point-to- multipoint Control Channel (MCCH) and multicast channel (MCH) scheduling information (MSI) for each MBSFN area. In action 4.2, the UE 130 can monitor and read a MCCH change notification from the base station 140.

[0027] In action 5, the base station 140 can transmit an MBSFN area configuration message to the UE 130, wherein the MBSFN area configuration message includes a list of TMGI information for a specific MBSFN area. The TMGIs refer to the eMBMS services, so the list of TMGI information includes information about the MBMS services for the specific MBSFN area. The modem 120 of the UE 130 can receive the MBSFN area configuration message from the base station 140, and in action 5.1, the modem 120 can transmit a TMGI list to the eMBMS middleware 110. The TMGI list can include a list of TMGIs (or list of eMBMS services) available for the specific MBSFN area. In other words, the modem 120 can indicate to the eMBMS middleware 110 the list of available MBMS services for the particular cell formed by the base station 140. Actions 5 and 5.1 can pertain to all available MBSFN areas for the cell formed by the base station 140. In action 6, the base station 140 can transmit multicast traffic channel (MTCH) data for a service announcement (SA) TMGI (or service) to the modem 120 of the UE 130, and the modem 120 can forward the MTCH data for the SA-TMGI to the eMBMS middleware 110. The SA-TMGI can include the list of eMBMS services transmitted from the base station 140. In other words, the SA-TMGI can include service descriptions of available TMGIs, wherein the SA-TMGI can include various parameters, such as a destination Internet Protocol (IP) address, a port, a forward error correction (FEC) scheme that it utilized, a protocol type, a media type, etc. The various parameters included in the SA- TMGI are further defined in 3 GPP Technical Specification (TS) 26.346 Section 7.3.

[0028] In action 7, the eMBMS middleware 110 can evaluate TMGIs of interest based on the list of TMGIs and the SA-TMGI (or service announcement). Based on the evaluation, in action 8, the eMBMS middleware 110 can send a TMGI service request to the modem 120, wherein the TMGI service request can include one or more specific TMGIs that are of interest to the eMBMS middleware 110 of the UE 130. As an example, the list of TMGIs and the SA-TMGI can indicate that 100 eMBMS services are being transmitted in the cell. From the 100 available eMBMS services, the eMBMS middleware 110 may be interested in two eMBMS services. Therefore, in this example, these two eMBMS services can be indicated in the TMGI service request transmitted from the eMBMS middleware 110 to the modem 120. In other words, the eMBMS middleware 110 can request these two particular eMBMS services from the cellular network. In action 9, the modem 120 of the UE 130 can sync up on MBSFN subframes belonging to a certain TMGI, and the MBSFN subframes can correspond to the one or more requested eMBMS services from the eMBMS middleware 110. In other words, the modem 120 can start reading these MBSFN subframes. In action 9.1, based on the sync-up to the MBSFN subframes, the modem 120 can receive MTCH data for the eMBMS service(s) from the base station 140. The MTCH data can be associated with the TMGI(s), or eMBMS service(s), of interest to the eMBMS middleware 110. The modem 120 of the UE 130 can forward the MTCH data associated with the TMGI(s) of interest to the eMBMS middleware 110 of the UE 130.

[0029] As shown in FIG 1, the UE 130 (e.g., CIoT device) can decode the SIB2, SIB13, and the MCCH-Change-notification. The UE 130 can read the MCCH to determine the eMBMS services transmitted from the cellular network. Based on this list of services transmitted from the cellular network, the eMBMS middleware 110 can determine which eMBMS services are of interest to the UE 130. The eMBMS middleware 110 can trigger the modem 120 of the UE 130 to receive those eMBMS services. In other words, the modem 120 can start receiving the eMBMS services upon request from the eMBMS middleware 110.

[0030] In one example, previous eMBMS solutions include a mechanism to acquire a service announcement eMBMS service (or SA-TMGI). The SA-TMGI is globally constant and is specified in a pre-stored bootstrap file in the UE 130. The modem 120 of the UE 130 can attempt to acquire the SA-TMGI upon request from the eMBMS middleware 110 of the UE 130. However, during this process, the modem 120 may acquire all the eMBMS signaling information and look for SA-TMGI availability, and if found, the modem 120 can receive the eMBMS MTCH data for TMGIs of interest to the eMBMS middleware 110 of the UE 130.

[0031] In the previous solution shown in FIG 1, the relatively high amount of signaling to receive the eMBMS service can be disadvantageous for CIoT devices. Therefore, as explained in greater detail below, a mechanism can be employed to reduce the amount of signaling involved in receiving eMBMS services, which can be particularly advantageous for CIoT devices due to the increased power consumption caused by excess signaling.

[0032] FIG 2 illustrates an example of a novel enhanced multimedia broadcast and multicast services (eMBMS) signaling procedure for user equipments (UEs). For example, a user equipment (UE) 230 can receive eMBMS services from a base station 240. The UE 230 can be a cellular Internet of Things (CIoT) device or a machine type communication (MTC) device. The UE 230 can include eMBMS middleware 210 and a modem 220. The eMBMS middleware 210 can be executed on an application processor of the UE 230, and the modem 220 can be associated with a baseband processor (or transceiver) of the UE 230. The modem 220 can communicate with the base station 240 in order to receive eMBMS services from the base station 240.

[0033] In one example, in action 1, a bootstrap file can be stored in the eMBMS middleware 210 of the UE 230. The bootstrap file can be pre-stored at an initial setup. In one example, the bootstrap file can already be stored at the UE 130 upon purchase of the UE 230, or the bootstrap file can be downloaded from a service provider during an initial setup procedure of the UE 230. For example, the bootstrap file can be downloaded using an over the air (OTA) software update. The bootstrap file can include eMBMS configuration information that enables the UE to receive eMBMS services from the base station with a reduced amount of signaling. More specifically, the bootstrap file stored at the UE 230 can include eMBMS cell information and a list of temporary mobile group identities (TMGIs) information. The eMBMS cell information can enable the UE 230 to camp on an eMBMS cell to receive eMBMS services with a reduced amount of signaling, as certain useful parameters for camping on the eMBMS cell are already stored at the UE and do not have to be received from the network. The list of TMGIs information can list the TMGIs to receive CIoT services along with eMBMS cellular network configuration information. In other words, the bootstrap file can include configuration information on the TMGIs (which correspond to the eMBMS services) that are available in the cell formed by the base station 240. In addition, pre-storing the list of TMGIs information in the bootstrap file is especially beneficial with respect to CIoT devices because the TMGI information does not frequently change (i.e., the TMGI information for CIoT devices is more semi-static), as opposed to TMGI information for non-CIoT devices.

[0034] In one example, the eMBMS cell information is a field that can be useful in enabling the modem 220 of the UE 230 to quickly camp on an eMBMS cell in order to receive eMBMS services. Since a majority of CIoT devices are static (e.g. non-moving), such as smart meters, the eMBMS cell information is generally semi-static information that does not frequently change. Therefore, the eMBMS cell information can be stored in the bootstrap file, such that the UE 230 can directly use the eMBMS cell information to quickly camp on the cell. The eMBMS cell information can include eMBMS frequencies, which are the frequencies at which eMBMS is supported for the TMGIs of interest. This frequency information can be used by the eMBMS middleware 210 to determine which frequencies are for interested eMBMS services, so the modem 220 can camp on the cell from this frequency list. The eMBMS cell information can include a cell global ID EUTRA list (CellGloballdEUTRA-list), which is a list of EUTRAN Global Cell IDs where TMGIs of interest are supported. In addition, the eMBMS cell information can include other information that enables the modem 220 to camp on an appropriate eMBMS cell at power-on.

[0035] In one example, the list of TMGIs information can include TMGIs of possible interest to the UE 130. The list of TMGIs information can be useful to the modem 220 in directly receiving multicast traffic channel (MTCH) data based on given parameters. The list of TMGIs information can include a number of entries. For example, each entry on the list can be associated with the following fields: (1) a TMGI that identifies a specific eMBMS service; (2) an eMBMS reception frequency that indicates how frequently a particular TMGI transmission is scheduled (e.g., once every month or once every week); (3) an eMBMS reception day and starting time that indicates a day and time at which a particular TMGI is started to transmit from the cellular network, and the eMBMS reception day and time start allows the UE 230 to determine when to wake up and start receiving the eMBMS service; (4) an eMBMS transmission repetition period that indicates a periodicity at which a transmission of a TMGI (or eMBMS service) from the cellular network is to be repeated; (5) a maximum number of eMBMS repetitions which indicates the maximum number of repetitions for the eMBMS service to be transmitted by the cellular network (e.g., a TMGI can be transmitted 20 times over a one day period every 20 minutes); and (6) physical multicast channel (PMCH) information that indicates an MBSFN subframe configuration for a defined TMGI for each repetition, such that the UE 230 can directly start receiving eMBMS services from these MBSFN subframes without performing another signaling procedure.

[0036] Therefore, as shown in action 1, the bootstrap file stored at the UE 230 can include the eMBMS cell information and the list of TMGIs information, wherein each entry on the list of TMGIs information includes a TMGI field, an eMBMS reception frequency field, an eMBMS repetition day time start field, an eMBMS transmission repetition period field, an eMBMS maximum repetitions field, and a PMCH information field.

[0037] In action 2, the UE 230 can be switched on, and the UE 230 can camp on a suitable or available cell (e.g., a cell formed by the base station 240) in order to receive the eMBMS services. In one example, when the eMBMS middleware 210 is expected to receive an eMBMS service, the eMBMS middleware 210 can notify the modem 220 to power on. At that point in time, the modem 220 can power on and camp on an eMBMS cell in order to receive the eMBMS service. The UE 230 can camp on the eMBMS cell based on the eMBMS cell information stored in the bootstrap file. As a result, a reduced amount of signaling is employed at the UE 230 when camping on the eMBMS cell formed by the base station 240.

[0038] In action 3, the eMBMS middleware 210 of the UE 230 can send a TMGI configuration request to the modem 220 of the UE 230, wherein the TMGI configuration request indicates one or more TMGIs (or eMBMS services) that are of interest to the eMBMS middleware 210. For example, the requested TMGIs (or eMBMS services) can enable the UE 230 to receive software updates, control information, video services, etc. In addition, the TMGI configuration request can include list of TMGIs information (stored in the bootstrap file) in the TMGI configuration request, and the list of TMGIs information can be utilized by the modem 220 when receiving the eMBMS service. [0039] In action 4, based on the list of TMGIs information, the modem 220 can sync up to MBSFN subframes belonging to a certain TMGI, and the MBSFN subframes can correspond to the one or more requested eMBMS services. In other words, the modem 220 can start reading the MBSFN subframes that correspond to the one or more TMGIs (or eMBMS services) included in the TMGI configuration request. The modem 220 can identify the particular MBSFN subframes that correspond to the requested eMBMS services based on the list of TMGIs information included in the TMGI configuration request. As previously explained, the list of TMGIs information can include, in the PMCH information parameter, the specific MBSFN subframe configuration for a particular TMGI for each repetition. Therefore, based on knowledge of which MBSFN subframes correspond to particular TMGIs (or eMBMS services), as indicated in the list of TMGIs information, the modem 220 can read the appropriate MBSFN subframes in order to receive the eMBMS services.

[0040] In action 4.1, based on the sync-up to MBSFN subframes belonging to a certain TMGI, the modem 420 can receive MTCH data for the eMBMS service(s) from the base station 440. The MTCH data can be associated with the TMGI(s), or eMBMS service(s), of interest to the eMBMS middleware 210. The modem 220 of the UE 230 can forward the MTCH data associated with the TMGI(s) of interest to the eMBMS middleware 210 of the UE 230.

[0041] In this configuration, PMCH information on which particular subframes are utilized for specific eMBMS services is provided to the modem 220 from the eMBMS middleware 210, whereas in previous solutions (as shown in FIG 1), the modem 220 receives the PMCH information from the network. However, as previously described, receiving the PMCH information (as well as other related TMGI information) can create an increased amount of signaling for the UE 230, which is particularly disadvantageous when the UE 230 is a CIoT device with strict power consumption restrictions. By storing the PMCH information (and other related TMGI information) in the bootstrap file, the modem 220 does not acquire this information from the network, thereby reducing the amount of signaling overhead and increasing power savings at the UE 230.

[0042] In one configuration, in action 4.1, the MTCH data can be related to the bootstrap file. In other words, the bootstrap file stored at the UE 230 can be updated by receiving MTCH data for the bootstrap file from the base station 240. The bootstrap file can be updated using the eMBMS service. At a later time, when the UE 230 is to receive eMBMS services, the UE 230 can utilize the updated bootstrap file. For example, the updated bootstrap file can include updated eMBMS cell information and an updated list of TMGIs information. The procedure for updating the bootstrap file is described in more detail below.

[0043] As shown in FIG. 2, a pre-stored bootstrap file mechanism can be utilized. In this configuration, CIoT-specific TMGIs and their configurations to receive eMBMS services can be pre-stored at the UE 230. The ability to pre-store this information is due to the infrequent configuration changes for CIoT devices. The cellular network can specify the fixed TMGIs (like SA-TMGI) targeted for certain UEs (e.g., CIoT devices) in the bootstrap file using existing pre-stored mechanisms. As a result, the UE 230 does not read eMBMS specific SIBs for a MCCH configuration, nor does the UE 230 receive the MSI, MCCH or MCCH change notification. Rather, the UE 230 can directly read MTCH data associated with the eMBMS TMGIs. In addition, if the TMGI information changes at a later time, a bootstrap update mechanism can be performed to update the bootstrap file stored at the UE 230.

[0044] FIG 3A illustrates an example of a legacy temporary mobile group identifier (TMGI) update procedure in an enhanced multimedia broadcast and multicast services (eMBMS) system. A user equipment (UE), such as a cellular Internet of Things (CIoT) device, can include eMBMS middleware and a modem. As shown in FIG. 3A, the modem of the UE can be powered on or wake up only for eMBMS services. The modem can read a master information block (MIB) and camp on a suitable cell to receive eMBMS services. The modem can read a system information block 2 (SIB2) and a SIB 13. The modem can monitor and read a MBMS point-to-multipoint Control Channel (MCCH) and multicast channel (MCH) scheduling information (MSI). After a next MCCH

modification period, the modem can receive a service announcement TMGI (SA-TMGI). The modem can receive TMGIs, which are the eMBMS services. At this point, after the eMBMS services are read, the modem can be powered down or transitioned into a sleep mode until a subsequent read or when the modem is not scheduled to perform additional operations. [0045] FIG 3B illustrates an example of a novel temporary mobile group identifier (TMGI) update procedure in an enhanced multimedia broadcast and multicast services (eMBMS) system. A user equipment (UE), such as a cellular Internet of Things (CIoT) device, can include eMBMS middleware and a modem. As shown in FIG. 3B, the modem of the UE can be powered on or wake up only for eMBMS services. The modem can read a master information block (MIB) and camp on a suitable cell to receive eMBMS services. The modem can receive TMGIs, which are the eMBMS services. At this point, after the eMBMS services are read, the modem can be powered down or transitioned into a sleep mode until a subsequent read or when the modem is not scheduled to perform additional operations.

[0046] As shown in FIG 3A, the legacy TMGI update procedure involves a relatively length period of time to read the MIB, camp on the cell, read the SIB2, read the SIB13, monitor and read the MCCH and MSI, receive the SA-TMGI, and receive the TMGIs (or eMBMS services). In contrast, as shown in FIG 3B, the novel TMGI update procedure only involves reading the MIB, camping on the cell, and receiving the TMGIs. These additional actions can be avoided due to the bootstrap file that is stored at the UE.

Therefore, the novel TMGI update procedure can reduce signaling overhead and reduce power consumption at the UE.

[0047] FIG 4 illustrates an example of an enhanced multimedia broadcast and multicast services (eMBMS) system for cellular Internet of Things (CIoT) devices. In the eMBMS system, multiple eNodeBs can each transmit a plurality of temporary mobile group identifiers (TMGIs), which can correspond to eMBMS services. For example, the eMBMS system can comprise an eMBMS cellular network that includes a first eNodeB 410 and a second eNodeB 420. The first eNodeB 410 and the second eNodeB 420 can each transmit TMGI-0, which can correspond to a fixed TMGI for a bootstrap file update. The first eNodeB 410 and the second eNodeB 420 can each transmit TMGI-1 to TMGI-3, which can correspond to various CIoT eMBMS services, such as software updates, configuration updates, etc. Therefore, the eMBMS cellular network can fix certain TMGIs to specific eMBMS services for CIoT devices.

[0048] In one example, the first eNodeB 410 and the second eNodeB 420 can each transmit TMGI -4 to TMGI-p, which can correspond to various eMBMS services for non- CIoT devices (e.g., phones tablets), wherein p is a fixed integer. However, the handling of the eMBMS procedures with respect to TMGI-4 to TMGI-p, a user equipment (UE) and the eMBMS cellular network may not follow the mechanism previously described in FIG 2. For example, the UE can separate the CIoT-TMGIs from the non-CIoT TMGIs using contents of the bootstrap file.

[0049] In one example, the eMBMS cellular network can fix the configuration of CIoT TMGIs to certain multicast-broadcast single-frequency network (MBSFN) subframes, and the eMBMS cellular network can schedule these eMBMS services to certain times and/or days (e.g., during specific times of day every month). In addition, the eMBMS cellular network can generally keep the configuration of the CIoT TMGIs unchanged. However, some configuration parameters of the CIoT TMGIs may change over time.

[0050] In one example, a CIoT device can contain a pre-stored bootstrap file, which typically contains TMGIs configuration information to be utilized by the CIoT device (e.g., TMGI-0 for bootstrap updates, TMGI-1 for a defined eMBMS service). Using the contents stored in the bootstrap file, the CIoT device can configure a modem in the CIoT device to receive one or more TMGIs of interest. The modem in the CIoT device can decode eMBMS subframes for certain TMGIs, and then deliver TMGI data related to the eMBMS service to a middleware in the CIoT device. In this procedure, the MBSFN subframes for the MTCHs are utilized directly by the CIoT device, and therefore, no additional signaling is involved at the CIoT device.

[0051] As an example, as shown in FIG. 4, the eMBMS system can include device A 425, device B 430, and device C 435. Device A 425, device B 430, and device C 435 can each store a bootstrap file with the TMGIs configuration information. As an example, device A 425 can request TMGI-0 and TMGI-1, which are of interest to device A 425, and device A 425 can receive eMBMS services corresponding to TMGI-0 and TMGI-1 based on the mechanism described above. As another example, device B 430 can request TMGI-0, TMGI-2 and TMGI-3, which are of interest to device B 430, and device B 430 can receive eMBMS services corresponding to TMGI-0, TMGI-2 and TMGI-3 based on the mechanism described above. As yet another example, device C 435 can request TMGI-0 and TMGI-3, which are of interest to device C 435, and device C 435 can receive eMBMS services corresponding to TMGI-0 and TMGI-3 based on the mechanism described above.

[0052] FIG. 5 illustrates an exemplary temporary mobile group identifier (TMGI) transmission repetition procedure. When a cellular Internet of Things (CIoT) device does not receive an enhanced multimedia broadcast and multicast services (eMBMS) service successfully from a cellular network, the cellular network can periodically repeat a certain TMGI (or eMBMS service). The TMGI transmissions can be repeated in accordance with various parameters that are stored in a bootstrap file. For example, an eMBMS reception day time start parameter in the bootstrap file can define when a first TMGI transmission is to happen. An eMBMS transmission repetition period parameter in the bootstrap file can define a periodicity at which the TMGI transmission is to be repeated (e.g., every 3 hours). In addition, an eMBMS maximum repetitions parameter in the bootstrap file can define a maximum number of TMGI transmissions from the cellular network. As a result, the cellular network can generally ensure that the transmission of the TMGI (or eMBMS service) is received at the CIoT device.

[0053] FIG 6 illustrates an example of an enhanced multimedia broadcast and multicast services (eMBMS) procedure for cellular Internet of Things (CIoT) devices. In action 1, the CIoT device can determine it is time to start receiving an eMBMS service. In action 2, the CIoT device can determine whether a modem in the CIoT device is powered on. The modem can be associated with a baseband processor (or transceiver) of the CIoT device. If the modem is powered on, then in action 4, a middleware in the CIoT device can send a TMGI configuration request to the modem, wherein the middleware is executed on an application processor of the CIoT device. The TMGI configuration request can include one or more requested TMGIs and corresponding TMGI configuration information (which can be stored in a bootstrap file at the CIoT device). In addition, the TMGI configuration request can include eMBMS cell information (which can be stored in the bootstrap file at the CIoT device). In action 5, the CIoT device can camp on a suitable eMBMS cell to receive eMBMS services based on the eMBMS cell information included in the TMGI configuration request.

[0054] In one example, in action 2, if the UE determines that the modem is not powered on, then in action 3, the middleware can send the TMGI configuration request to the modem and the modem can power on, and then the UE can camp on the suitable eMBMS cell (as in action 5).

[0055] In one example, in action 6, the modem can acquire MTCH data from MBSFN subframes associated with the requested TMGI(s), as indicated in the TMGI configuration information included in the TMGI configuration request. In other words, the MTCH data received at the modem can correspond to the requested TMGIs (or eMBMS services). In action 7, the CIoT device can determine whether the reception of the MTCH data (or TMGI data) was successful. If successful, in action 10, the CIoT device can power down the modem if no other operations are pending. If not successful, in action 8, the modem can reacquire the MTCH data in a subsequent TMGI retransmission. The subsequent TMGI transmission can be in accordance with an eMBMS retransmission repetition period. After the MTCH data is reacquired, in action 9, if the TMGI data reception is successful or a maximum number of eMBMS repetitions has been reached, the CIoT device can power down the modem if no other operations are pending (as shown in action 10).

[0056] FIG 7 illustrates an exemplary signaling procedure between a base station 740 and a user equipment (UE) 730 to update a bootstrap file. The bootstrap file can include enhanced multimedia broadcast and multicast services (eMBMS) configuration information for use at the UE 730. The UE 730 can be a cellular Internet of Things (CIoT) device or a machine type communication (MTC) device. The UE 730 can include eMBMS middleware 710 and a modem 720. The eMBMS middleware 710 can be executed on an application processor of the UE 730, and the modem 720 can be associated with a baseband processor (or transceiver) of the UE 730.

[0057] In one example, in action 1, the eMBMS middleware 710 can identify the bootstrap file that includes the eMBMS configuration information. The eMBMS configuration information can be associated with one or more TMGIs (or eMBMS services). The eMBMS configuration information can also be referred to as a list of TMGIs information. In addition, the bootstrap file can include eMBMS cell information.

[0058] In action 1.1, the modem 720 can receive multicast traffic channel (MTCH) data for the eMBMS service(s) from the base station 740. The MTCH data can be associated with the TMGI(s), or eMBMS service(s), of interest to the eMBMS middleware 710. In one example, as shown in action 2, the MTCH data can include TMGI metadata, which indicates whether the bootstrap file stored at the UE 730 is to be updated. In other words, the TMGI metadata can indicate whether eMBMS cell information or the list of TMGIs information has been updated in the eMBMS cellular network. In action 3, the eMBMS middleware 710 can determine to update the bootstrap file when an update bootstrap parameter in the TMGI metadata is set to true. In action 3.1, the base station 740 can send MTCH data for a bootstrap TMGI to the modem 720, and the modem 720 can forward the MTCH data for the bootstrap TMGI to the eMBMS middleware 710, thereby updating the bootstrap file that is stored at the UE 730. In other words, the base station 740 can transmit an updated bootstrap file containing updated eMBMS cell information and an updated list of TMGIs information to the modem 720, and the modem 720 can forward the updated bootstrap file to the eMBMS middleware 710.

[0059] As shown in FIG 7, when the bootstrap file is outdated or indicated by the base station 740 to be updated, the UE 730 can utilize a mechanism to update the bootstrap file. The base station 740 can globally fix the configuration of the bootstrap file (e.g., BS- TMGI, MBSFN-sub-frame configuration) using pre-stored information in the UE 730. In one example, the bootstrap file may be updated in the UE 730 by the base station 740 when the eMBMS cell information or TMGI configuration information has been updated as compared to a previous time. The base station 740 can transmit bootstrap TMGI data in one of the pre-assigned TMGIs for bootstrap updates. The base station 740 can indicate whether the bootstrap file has changed by another TMGI data, or the base station 740 can perform the indication in advance by using a flag indicating that the UE 730 is to update the bootstrap file.

[0060] In one configuration, the UE 730 can assume that the bootstrap file has been changed or updated (e.g., based on an age of the bootstrap file), and the UE 730 can execute a MTCH procedure for updating the bootstrap file, and then the UE 730 can receive MTCH data based on the updated bootstrap file. In other words, rather than receiving the TMGI metadata that indicates a current bootstrap file is outdated, the UE 730 can periodically initiate the procedure for updating the bootstrap file.

[0061] In one configuration, an Internet of Things (IoT) device can contain pre-stored or receives signaling information in a bootstrap file in order to avoid signaling overhead for eMBMS services. Since the configuration of eMBMS services utilized by the IoT device does not change frequently, the configuration for such eMBMS services can pre-stored in the IoT device itself (in the bootstrap file), and used at a subsequent time when the IoT device receives the eMBMS services. As a result, the IoT device can avoid unnecessary signaling overhead and reduce power consumption.

[0062] In one configuration, the IoT device can receive the eMBMS services less frequently (e.g., once in 6 months). Therefore, the IoT device can receive the bootstrap file at power-on (rather than utilizing a pre-stored bootstrap file), such that the IoT device can utilize the latest eMBMS configuration when receiving the eMBMS services.

[0063] In one configuration, the IoT device, which is receiving eMBMS services, can wake-up intermittently to check whether eMBMS configuration parameters have changed since a previous time. If one or more of the eMBMS configuration parameters have changed, the IoT device can receive the latest eMBMS configuration parameters, thereby reducing the eMBMS services reception latency.

[0064] In one configuration, the IoT device can receive a plurality of eMBMS services that may be desirable in the future when the IoT device is connected to a power source, or when the IoT device is within an area that provides free internet resources (e.g., free WiFi). As a result, the IoT device can avoid waking up in the future when resources like power consumption and cellular network connectivity are more crucial.

[0065] Another example provides functionality 800 of a user equipment (UE) operable to receive Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling from a base station, as shown in the flow chart in FIG 8. The UE can comprise one or more processors and memory configured to: identify, at the UE, a bootstrap file that includes eMBMS configuration information that enables the UE to receive eMBMS services from the base station, as in block 810. The UE can comprise one or more processors and memory configured to: establish, at the UE, a connection with the base station when a defined eMBMS service is to be received at the UE from the base station, as in block 820. The UE can comprise one or more processors and memory configured to: identify, at the UE, a defined set of multicast-broadcast single-frequency network (MBSFN) subframes to receive multicast traffic channel (MTCH) data for the defined eMBMS service based on the eMBMS configuration information included in the bootstrap file, as in block 830. The UE can comprise one or more processors and memory configured to: receive, at the UE from the base station, the MTCH data for the eMBMS service on the defined set of MBSFN subframes, as in block 840.

[0066] Another example provides functionality 900 of a base station operable to provide Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling to a cellular Internet of Things (CIoT) device, as shown in the flow chart in FIG. 9. The base station can comprise one or more processors and memory configured to: perform, at the base station, a connection establishment procedure with the CIoT device, wherein the CIoT device is configured to initiate the connection establishment procedure when a defined eMBMS service is to be received at the CIoT device from the base station, as in block 910. The base station can comprise one or more processors and memory configured to: communicate, to the CIoT device, multicast traffic channel (MTCH) data for the defined eMBMS service, wherein the CIoT device is configured to receive the MTCH data from the base station based on eMBMS configuration information in a bootstrap file that is pre- stored at the CIoT device, wherein the eMBMS configuration information enables the CIoT device to receive the defined eMBMS service from the base station, as in block 920.

[0067] Another example provides at least one machine readable storage medium having instructions 1000 embodied thereon for communicating Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling between a cellular Internet of Things (CIoT) device and a base station, as shown in the flow chart in FIG. 10. The instructions can be executed on a machine, where the instructions are included on at least one computer readable medium or one non-transitory machine readable storage medium. The instructions when executed perform: identifying, using at least one processor of the CIoT device, a bootstrap file that includes eMBMS configuration information that enables the CIoT device to receive eMBMS services from the base station, as in block 1010. The instructions when executed perform: establishing, using the at least one processor of the CIoT device, a connection with the base station when a defined eMBMS service is to be received at the UE from the base station, as in block 1020. The instructions when executed perform: identifying, using the at least one processor of the CIoT device, a defined set of multicast-broadcast single-frequency network (MBSFN) subframes to receive multicast traffic channel (MTCH) data for the defined eMBMS service based on the eMBMS configuration information included in the bootstrap file, as in block 1030. The instructions when executed perform: receiving, using the at least one processor of the CIoT device, the MTCH data for the eMBMS service from the base station on the defined set of MBSFN subframes, as in block 1040.

[0068] FIG. 11 provides an example illustration of a user equipment (UE) device 1100, such as a wireless device, a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a handset, or other type of wireless device. The UE device 1100 can include one or more antennas configured to communicate with a node 1120 or transmission station, such as a base station (BS), an evolved Node B (eNB), a baseband unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), a remote radio unit (RRU), a central processing module (CPM), or other type of wireless wide area network (WWAN) access point. The node 1120 can include one or more processors 1122 and memory 1124. The UE device 1100 can be configured to communicate using at least one wireless communication standard including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The UE device 1100 can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The UE device 1100 can communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WWAN.

[0069] In some embodiments, the UE device 1100 may include application circuitry 1102, baseband circuitry 1104, Radio Frequency (RF) circuitry 1106, front-end module (FEM) circuitry 1108 and one or more antennas 1110, coupled together at least as shown.

[0070] The application circuitry 1102 may include one or more application processors. For example, the application circuitry 1102 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include a storage medium, and may be configured to execute instructions stored in the storage medium to enable various applications and/or operating systems to run on the system.

[0071] The baseband circuitry 1104 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1104 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 1106 and to generate baseband signals for a transmit signal path of the RF circuitry 1106. Baseband processing circuity 1104 may interface with the application circuitry 1102 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1106. For example, in some embodiments, the baseband circuitry 1104 may include a second generation (2G) baseband processor 1104a, third generation (3G) baseband processor 1104b, fourth generation (4G) baseband processor 1104c, and/or other baseband processor(s) 1104d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6Q etc.). The baseband circuitry 1104 (e.g., one or more of baseband processors 1104a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1106. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 1104 may include Fast-Fourier Transform (FFT), precoding, and/or constellation

mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 1104 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality.

Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

[0072] In some embodiments, the baseband circuitry 1104 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol

(PDCP), and/or radio resource control (RRC) elements. A central processing unit (CPU) 1104e of the baseband circuitry 1104 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 1104f. The audio DSP(s) 104f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 1104 and the application circuitry 1102 may be implemented together such as, for example, on a system on a chip (SOC).

[0073] In some embodiments, the baseband circuitry 1104 may provide for

communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1104 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 1104 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0074] The RF circuitry 1106 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1106 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 1106 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1108 and provide baseband signals to the baseband circuitry 1104. RF circuitry 1106 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1104 and provide RF output signals to the FEM circuitry 1108 for transmission.

[0075] In some embodiments, the RF circuitry 1106 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 1106 may include mixer circuitry 1106a, amplifier circuitry 1106b and filter circuitry 1106c. The transmit signal path of the RF circuitry 1106 may include filter circuitry 1106c and mixer circuitry 1106a. RF circuitry 1106 may also include synthesizer circuitry 1106d for synthesizing a frequency for use by the mixer circuitry 1106a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 1106a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 1108 based on the synthesized frequency provided by synthesizer circuitry 1106d. The amplifier circuitry 1106b may be configured to amplify the down-converted signals and the filter circuitry 1106c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 1104 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 1106a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0076] In some embodiments, the mixer circuitry 1106a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1106d to generate RF output signals for the FEM circuitry 1108. The baseband signals may be provided by the baseband circuitry 1104 and may be filtered by filter circuitry 1106c. The filter circuitry 1106c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

[0077] In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a of the transmit signal path may include two or more mixers and may be arranged for quadrature down-conversion and/or up-conversion respectively. In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a may be arranged for direct down-conversion and/or direct up-conversion, respectively. In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a of the transmit signal path may be configured for super-heterodyne operation.

[0078] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these altemate embodiments, the RF circuitry 1106 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1104 may include a digital baseband interface to communicate with the RF circuitry 1106.

[0079] In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[0080] In some embodiments, the synthesizer circuitry 1106d may be a fractional-N synthesizer or a fractional N/N+l synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 1106d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0081] The synthesizer circuitry 1106d may be configured to synthesize an output frequency for use by the mixer circuitry 1106a of the RF circuitry 1106 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1106d may be a fractional N/N+l synthesizer.

[0082] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 1104 or the applications processor 1102 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 1102.

[0083] Synthesizer circuitry 1106d of the RF circuitry 1106 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0084] In some embodiments, synthesizer circuitry 1106d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 1106 may include an IQ/polar converter.

[0085] FEM circuitry 1108 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 1110, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1106 for further processing. FEM circuitry 1108 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1106 for transmission by one or more of the one or more antennas 1110.

[0086] In some embodiments, the FEM circuitry 1108 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1106). The transmit signal path of the FEM circuitry 1108 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1106), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1110.

[0087] FIG. 12 provides an example illustration of the wireless device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile

communication device, a tablet, a handset, or other type of wireless device. The wireless device can include one or more antennas configured to communicate with a node, macro node, low power node (LPN), or, transmission station, such as a base station (BS), an evolved Node B (eNB), a baseband processing unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), or other type of wireless wide area network (WWAN) access point. The wireless device can be configured to communicate using at least one wireless communication standard such as, but not limited to, 3 GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The wireless device can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The wireless device can communicate in a wireless local area network

(WLAN), a wireless personal area network (WPAN), and/or a WWAN. The wireless device can also comprise a wireless modem. The wireless modem can comprise, for example, a wireless radio transceiver and baseband circuitry (e.g., a baseband processor). The wireless modem can, in one example, modulate signals that the wireless device transmits via the one or more antennas and demodulate signals that the wireless device receives via the one or more antennas.

[0088] FIG. 12 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the wireless device. The display screen can be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities. A non-volatile memory port can also be used to provide data input/output options to a user. The non-volatile memory port can also be used to expand the memory capabilities of the wireless device. A keyboard can be integrated with the wireless device or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard can also be provided using the touch screen.

Examples

[0089] The following examples pertain to specific technology embodiments and point out specific features, elements, or actions that can be used or otherwise combined in achieving such embodiments.

[0090] Example 1 includes an apparatus of a user equipment (UE) operable to receive Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling from a base station, the apparatus comprising one or more processors and memory configured to: identify, at the UE, a bootstrap file that includes eMBMS configuration information that enables the UE to receive eMBMS services from the base station; establish, at the UE, a connection with the base station when a defined eMBMS service is to be received at the UE from the base station; identify, at the UE, a defined set of multicast-broadcast single- frequency network (MBSFN) subframes to receive multicast traffic channel (MTCH) data for the defined eMBMS service based on the eMBMS configuration information included in the bootstrap file; and receive, at the UE from the base station, the MTCH data for the eMBMS service on the defined set of MBSFN subframes.

[0091] Example 2 includes the apparatus of Example 1, wherein an application processor of the UE is configured to send, to a baseband processor of a modem of the UE, a request to receive an eMBMS service associated with a defined temporary mobile group identifier (TMGI) and the eMBMS configuration information, wherein the baseband processor is configured to sync up to the defined set of MBSFN subframes that correspond to the defined TMGI using the eMBMS configuration information and receive the MTCH data on the defined set of MBSFN subframes.

[0092] Example 3 includes the apparatus of any of Examples 1-2, wherein the bootstrap file includes eMBMS cell information and a list of temporary mobile group identities (TMGIs) information of interest to the UE, wherein each entry in the list is associated with a TMGI that identifies a defined eMBMS service, an eMBMS reception frequency, an eMBMS reception day and time start, a maximum number of eMBMS repetitions, and physical multicast channel (PMCH) information that indicates an MBSFN subframe configuration for a defined TMGI.

[0093] Example 4 includes the apparatus of any of Examples 1-3, wherein the bootstrap file includes a service announcement that contains a list of eMBMS services provided by the base station.

[0094] Example 5 includes the apparatus of any of Examples 1-4, wherein the bootstrap file is pre-stored at the UE.

[0095] Example 6 includes the apparatus of any of Examples 1-5, wherein the UE is configured to receive the bootstrap file from the eNodeB after powering on the UE.

[0096] Example 7 includes the apparatus of any of Examples 1-6, wherein a baseband processor of a modem of the UE is powered on only for receiving eMBMS services from the base station.

[0097] Example 8 includes the apparatus of any of Examples 1-7, wherein a baseband processor of a modem of the UE transitions to a sleep mode after the MTCH data for the eMBMS service is received from the base station.

[0098] Example 9 includes the apparatus of any of Examples 1-8, further configured to: receive, from the base station, metadata to indicate that the bootstrap file has been updated with respect to a previous version of the bootstrap file, wherein the metadata is included in the MTCH data for the eMBMS service; and receive, from the base station, an updated bootstrap file that includes updated eMBMS configuration information.

[0099] Example 10 includes the apparatus of any of Examples 1-9, wherein the UE is a machine type communication (MTC) device or an Internet of Things (IoT) device.

[00100] Example 11 includes the apparatus of any of Examples 1-10, wherein the UE includes at least one of an antenna, a touch sensitive display screen, a speaker, a microphone, a graphics processor, an application processor, a baseband processor, an internal memory, a non-volatile memory port, and combinations thereof.

[00101] Example 12 includes an apparatus of a base station operable to provide Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling to a cellular Internet of Things (CIoT) device, the apparatus comprising one or more processors and memory configured to: perform, at the base station, a connection establishment procedure with the CIoT device, wherein the CIoT device is configured to initiate the connection establishment procedure when a defined eMBMS service is to be received at the CIoT device from the base station; and communicate, to the CIoT device, multicast traffic channel (MTCH) data for the defined eMBMS service, wherein the CIoT device is configured to receive the MTCH data from the base station based on eMBMS configuration information in a bootstrap file that is pre-stored at the CIoT device, wherein the eMBMS configuration information enables the CIoT device to receive the defined eMBMS service from the base station.

[00102] Example 13 includes the apparatus of Example 12, wherein the base station is configured to communicate the MTCH data for the defined eMBMS service using a defined set of multicast-broadcast single-frequency network (MBSFN) subframes, wherein the defined set of MBSFN subframes for the defined eMBMS service is indicated in the eMBMS configuration information in the bootstrap file.

[00103] Example 14 includes the apparatus of any of Examples 12-13, wherein the bootstrap file includes eMBMS cell information and a list of temporary mobile group identities (TMGIs) information of interest to the UE, wherein each entry in the list is associated with a TMGI that identifies a defined eMBMS service, an eMBMS reception frequency, an eMBMS reception day and time start, a maximum number of eMBMS repetitions, and physical multicast channel (PMCH) information that indicates an MBSFN subframe configuration for a defined TMGI.

[00104] Example 15 includes the apparatus of any of Examples 12-14, further configured to: send, to the CIoT device, metadata to indicate that the bootstrap file has been updated with respect to a previous version of the bootstrap file, wherein the metadata is included in the MTCH data for the eMBMS service; and send, to the CIoT device, an updated bootstrap file for storage at the CIoT device, wherein the updated bootstrap file includes updated eMBMS configuration information.

[00105] Example 16 includes at least one machine readable storage medium having instructions embodied thereon for communicating Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling between a cellular Internet of Things (CIoT) device and a base station, the instructions when executed perform the following:

identifying, using at least one processor of the CIoT device, a bootstrap file that includes eMBMS configuration information that enables the CIoT device to receive eMBMS services from the base station; establishing, using the at least one processor of the CIoT device, a connection with the base station when a defined eMBMS service is to be received at the UE from the base station; identifying, using the at least one processor of the CIoT device, a defined set of multicast-broadcast single-frequency network (MBSFN) subframes to receive multicast traffic channel (MTCH) data for the defined eMBMS service based on the eMBMS configuration information included in the bootstrap file; and receiving, using the at least one processor of the CIoT device, the MTCH data for the eMBMS service from the base station on the defined set of MBSFN subframes.

[00106] Example 17 includes the at least one machine readable storage medium of Example 16, further comprising instructions which when executed perform the following: sending, from an application processor of the CIoT device to a baseband processor of a modem of the CIoT device, a request to receive an eMBMS service associated with a defined temporary mobile group identifier (TMGI) and the eMBMS configuration information, wherein the baseband processor is configured to sync up to the defined set of MBSFN subframes that correspond to the defined TMGI using the eMBMS configuration information and receive the MTCH data on the defined set of MBSFN subframes.

[00107] Example 18 includes the at least one machine readable storage medium of any of Examples 16-17, wherein the bootstrap file includes eMBMS cell information and a list of temporary mobile group identities (TMGIs) information of interest to the CIoT device, wherein each entry in the list is associated with a TMGI that identifies a defined eMBMS service, an eMBMS reception frequency, an eMBMS reception day and time start, a maximum number of eMBMS repetitions, and physical multicast channel (PMCH) information that indicates an MBSFN subframe configuration for a defined TMGI.

[00108] Example 19 includes the at least one machine readable storage medium of any of Examples 16-18, wherein the bootstrap file includes a service announcement that contains a list of eMBMS services provided by the base station.

[00109] Example 20 includes the at least one machine readable storage medium of any of Examples 16-19, wherein the bootstrap file is pre-stored at the CIoT device.

[00110] Example 21 includes the at least one machine readable storage medium of any of Examples 16-20, further comprising instructions which when executed perform the following: receiving the bootstrap file from the eNodeB after powering on the CIoT device.

[00111] Example 22 includes the at least one machine readable storage medium of any of Examples 16-21, further comprising instructions which when executed perform the following: powering on a baseband processor of a modem of the CIoT device only for receiving eMBMS services from the base station.

[00112] Example 23 includes the at least one machine readable storage medium of any of Examples 16-22, further comprising instructions which when executed perform the following: transitioning a baseband processor of a modem of the CIoT device to a sleep mode after the MTCH data for the eMBMS service is received from the base station.

[00113] Example 24 includes the at least one machine readable storage medium of any of Examples 16-23, further comprising instructions which when executed perform the following: receiving, from the base station, metadata to indicate that the bootstrap file has been updated with respect to a previous version of the bootstrap file, wherein the metadata is included in the MTCH data for the eMBMS service; and receiving, from the base station, an updated bootstrap file that includes updated eMBMS configuration information.

[00114] Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, compact disc-read-only memory (CD-ROMs), hard drives, non-transitory computer readable storage medium, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. A non-transitory computer readable storage medium can be a computer readable storage medium that does not include signal. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be a random-access memory (RAM), erasable

programmable read only memory (EPROM), flash drive, optical drive, magnetic hard drive, solid state drive, or other medium for storing electronic data. The node and wireless device may also include a transceiver module (i.e., transceiver), a counter module (i.e., counter), a processing module (i.e., processor), and/or a clock module (i.e., clock) or timer module (i.e., timer). One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

[00115] As used herein, the term "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

[00116] It should be understood that many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

[00117] Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module may not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

[00118] Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The modules may be passive or active, including agents operable to perform desired functions.

[00119] Reference throughout this specification to "an example" or "exemplary" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present technology. Thus, appearances of the phrases "in an example" or the word "exemplary" in various places throughout this specification are not necessarily all referring to the same embodiment.

[00120] As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present technology may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and altematives are not to be construed as defacto equivalents of one another, but are to be considered as separate and autonomous representations of the present technology.

[00121] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of layouts, distances, network examples, etc., to provide a thorough understanding of embodiments of the technology. One skilled in the relevant art will recognize, however, that the technology can be practiced without one or more of the specific details, or with other methods, components, layouts, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the technology.

[00122] While the forgoing examples are illustrative of the principles of the present technology in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the technology. Accordingly, it is not intended that the technology be limited, except as by the claims set forth below.

Claims

CLAIMS What is claimed is:

1. An apparatus of a user equipment (UE) operable to receive Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling from a base station, the apparatus comprising one or more processors and memory configured to:

identify, at the UE, a bootstrap file that includes eMBMS configuration information that enables the UE to receive eMBMS services from the base station; establish, at the UE, a connection with the base station when a defined eMBMS service is to be received at the UE from the base station;

identify, at the UE, a defined set of multicast-broadcast single-frequency network (MBSFN) subframes to receive multicast traffic channel (MTCH) data for the defined eMBMS service based on the eMBMS configuration information included in the bootstrap file; and

process, at the UE, the MTCH data received from the base station, wherein the MTCH data is received on the defined set of MBSFN subframes.

2. The apparatus of claim 1, wherein an application processor of the UE is

configured to send, to a baseband processor of a modem of the UE, a request to receive an eMBMS service associated with a defined temporary mobile group identifier (TMGI) and the eMBMS configuration information, wherein the baseband processor is configured to sync up to the defined set of MBSFN subframes that correspond to the defined TMGI using the eMBMS configuration information and receive the MTCH data on the defined set of MBSFN subframes.

3. The apparatus of any of claims 1 to 2, wherein the bootstrap file includes eMBMS cell information and a list of temporary mobile group identities (TMGIs) information of interest to the UE, wherein each entry in the list is associated with a TMGI that identifies a defined eMBMS service, an eMBMS reception frequency, an eMBMS reception day and time start, a maximum number of eMBMS repetitions, and physical multicast channel (PMCH) information that indicates an MBSFN subframe configuration for a defined TMGI.

4. The apparatus of claim 1, wherein the bootstrap file includes a service announcement that contains a list of eMBMS services provided by the base station.

5. The apparatus of claim 1, wherein the bootstrap file is pre-stored at the UE.

6. The apparatus of claim 1, wherein the UE is configured to receive the bootstrap file from the eNodeB after powering on the UE.

7. The apparatus of claim 1, wherein a baseband processor of a modem of the UE is powered on only for receiving eMBMS services from the base station.

8. The apparatus of claim 1, wherein a baseband processor of a modem of the UE transitions to a sleep mode after the MTCH data for the eMBMS service is received from the base station.

9. The apparatus of claim 1, further configured to:

receive, from the base station, metadata to indicate that the bootstrap file has been updated with respect to a previous version of the bootstrap file, wherein the metadata is included in the MTCH data for the eMBMS service; and

receive, from the base station, an updated bootstrap file that includes updated eMBMS configuration information.

10. The apparatus of claim 1 , wherein the UE is a machine type communication (MTC) device or an Internet of Things (IoT) device.

11. The apparatus of claim 1, wherein the UE includes at least one of an antenna, a touch sensitive display screen, a speaker, a microphone, a graphics processor, an application processor, a baseband processor, an internal memory, a non-volatile memory port, and combinations thereof.

12. An apparatus of a base station operable to provide Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling to a cellular Internet of Things (CIoT) device, the apparatus comprising one or more processors and memory configured to:

perform, at the base station, a connection establishment procedure with the CIoT device, wherein the CIoT device is configured to initiate the connection establishment procedure when a defined eMBMS service is to be received at the CIoT device from the base station; and

process, at the base station, multicast traffic channel (MTCH) data for communication to the CIoT device, wherein the MTCH data is for the defined eMBMS service, wherein the CIoT device is configured to receive the MTCH data from the base station based on eMBMS configuration information in a bootstrap file that is pre-stored at the CIoT device, wherein the eMBMS configuration information enables the CIoT device to receive the defined eMBMS service from the base station.

13. The apparatus of claim 12, wherein the base station is configured to communicate the MTCH data for the defined eMBMS service using a defined set of multicast- broadcast single-frequency network (MBSFN) subframes, wherein the defined set of MBSFN subframes for the defined eMBMS service is indicated in the eMBMS configuration information in the bootstrap file.

14. The apparatus of any of claims 12 to 13, wherein the bootstrap file includes

eMBMS cell information and a list of temporary mobile group identities (TMGIs) information of interest to the UE, wherein each entry in the list is associated with a TMGI that identifies a defined eMBMS service, an eMBMS reception frequency, an eMBMS reception day and time start, a maximum number of eMBMS repetitions, and physical multicast channel (PMCH) information that indicates an MBSFN subframe configuration for a defined TMGI.

15. The apparatus of claim 12, further configured to: send, to the CIoT device, metadata to indicate that the bootstrap file has been updated with respect to a previous version of the bootstrap file, wherein the metadata is included in the MTCH data for the eMBMS service; and

send, to the CIoT device, an updated bootstrap file for storage at the CIoT device, wherein the updated bootstrap file includes updated eMBMS configuration information.

16. At least one machine readable storage medium having instructions embodied thereon for communicating Evolved Multimedia Broadcast Multicast Service (eMBMS) signaling between a cellular Internet of Things (CIoT) device and a base station, the instructions when executed perform the following:

identifying, using at least one processor of the CIoT device, a bootstrap file that includes eMBMS configuration information that enables the CIoT device to receive eMBMS services from the base station;

establishing, using the at least one processor of the CIoT device, a connection with the base station when a defined eMBMS service is to be received at the UE from the base station;

identifying, using the at least one processor of the CIoT device, a defined set of multicast-broadcast single-frequency network (MBSFN) subframes to receive multicast traffic channel (MTCH) data for the defined eMBMS service based on the eMBMS configuration information included in the bootstrap file; and processing, using the at least one processor of the CIoT device, the MTCH data for the defined eMBMS service received from the base station on the defined set of MBSFN subframes.

17. The at least one machine readable storage medium of claim 16, further comprising instructions which when executed perform the following: sending, from an application processor of the CIoT device to a baseband processor of a modem of the CIoT device, a request to receive an eMBMS service associated with a defined temporary mobile group identifier (TMGI) and the eMBMS configuration information, wherein the baseband processor is configured to sync up to the defined set of MBSFN subframes that correspond to the defined TMGI using the eMBMS configuration information and receive the MTCH data on the defined set of MBSFN subframes.

18. The at least one machine readable storage medium of claim 16, wherein the

bootstrap file includes eMBMS cell information and a list of temporary mobile group identities (TMGIs) information of interest to the CIoT device, wherein each entry in the list is associated with a TMGI that identifies a defined eMBMS service, an eMBMS reception frequency, an eMBMS reception day and time start, a maximum number of eMBMS repetitions, and physical multicast channel (PMCH) information that indicates an MBSFN subframe configuration for a defined TMGI.

19. The at least one machine readable storage medium of claim 16, wherein the

bootstrap file includes a service announcement that contains a list of eMBMS services provided by the base station.

20. The at least one machine readable storage medium of claim 16, wherein the

bootstrap file is pre-stored at the CIoT device.

21. The at least one machine readable storage medium of claim 16, further comprising instructions which when executed perform the following: receiving the bootstrap file from the eNodeB after powering on the CIoT device.

22. The at least one machine readable storage medium of claim 16, further comprising instructions which when executed perform the following: powering on a baseband processor of a modem of the CIoT device only for receiving eMBMS services from the base station.

23. The at least one machine readable storage medium of claim 16, further comprising instructions which when executed perform the following: transitioning a baseband processor of a modem of the CIoT device to a sleep mode after the MTCH data for the eMBMS service is received from the base station.

24. The at least one machine readable storage medium of any of claims 16 to 23, further comprising instructions which when executed perform the following: receiving, from the base station, metadata to indicate that the bootstrap file has been updated with respect to a previous version of the bootstrap file, wherein the metadata is included in the MTCH data for the eMBMS service; and

receiving, from the base station, an updated bootstrap file that includes updated eMBMS configuration information.