Patent Application
20140334350
Acronym Full Text
Multimedia Broadcast Multicast Services (MBMS) is a point to multipoint interface that may be utilized to distribute multimedia services (e.g., television content) alongside traditional voice and data services in a cellular network. Single Frequency Network (SFN) is utilized in E-UTRAN to support MBMS. Multiple base stations are involved in Multimedia Broadcast Single Frequency Network (MBSFN) transmission in specific MBSFN subframes.
An MBSFN subframe includes a unicast part and an MBSFN part for which MCH is utilized. An example MBSFN subframe has cell specific reference signal (CRS) in the first one or two symbols and MBSFN reference signals (R4) in the rest of the subframe as shown in the
In E-UTRAN, a UE is provided with information about MBSFN subframe allocation of the serving cell and an indication of whether the allocation is applicable to neighboring cells. The UE utilizes the information to locate symbols carrying CRS for RRM measurement of neighbor cells in a E-UTRAN frequency to measure. For example, 4 symbols in non-MBSFN subframes and 1 symbol in the subframes configured as an MBSFN subframe. However, when a UE is camped on another radio access technology such as GERAN or UTRAN, System Information and measurement configuration do not indicate whether E-UTRA frequencies may have MBSFN configured. As a result when measurements of E-UTRA cells are taken from those RATs, the UE assumes that MBSFN may be configured in all subframes except the known non-MBSFN subframes. Because some of the assumed to be possibly MBSFN subframes, that carry fewer symbols carrying CRS may actually not be allocated for MBSFN, they are actually available for RRM measurement. For example, if an elapsed measurement duration is kept constant, the measurement accuracy is degraded because fewer symbols carrying CRS are used. Alternatively, if the measurement time is increased to maintain accuracy, power consumption by the UE increases.
Similarly, a configuration of an E-UTRA neighbor TDD cell (e.g., special subframe patterns and uplink and downlink configuration) is also not reported to a UE when camped in GERAN and UTRAN. The UE assumes the worst case when E-UTRA TDD cells are measured from the other RATs, which results in similar disadvantages to the MBSFN configuration.
Example methods and apparatus described herein facilitate apprising a UE of configuration information (e.g., MBSFN configuration, TDD configuration, etc.) for E-UTRA neighbor cells while camped on a RAT different than E-UTRA (e.g., GERAN, UTRAN, etc.). When the UE is informed of such configuration information, the UE can efficiently communicate with the network by using available resources (e.g., without mistakenly assuming that resources are assigned in a particular manner). For example, in UTRAN Idle mode, the measurement of neighbor cells can contribute a significant proportion of the average current draw from the battery. Reducing the time to measure an E-UTRAN cell by allowing UE to make use of all the available symbols carrying CRS of that cell may result in significant battery saving, more accurate measurements, or both.
Referring first to
The main processor 102 also interacts with additional subsystems such as a Random Access Memory (RAM) 106, a flash memory 108, a display 110, an auxiliary input/output (I/O) subsystem 112, a data port 114, a keyboard 116, a speaker 118, a microphone 120, short-range communications 122 and other device subsystems 124.
Some of the subsystems of the mobile device 100 perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. By way of example, the display 110 and the keyboard 116 may be used for both communication-related functions, such as entering a text message for transmission over the network 200, and device-resident functions such as a calculator or task list.
The mobile device 100 can send and receive communication signals over the wireless network 400 after required network registration or activation procedures have been completed. Network access is associated with a subscriber or user of the mobile device 100. To identify a subscriber, the mobile device 100 requires a USIM/RUIM card 126 (i.e. Universal Subscriber Identity Module or a Removable User Identity Module) to be inserted into a USIM/RUIM interface 128 in order to communicate with the network 400. The USIM card or RUIM 126 is one type of a conventional “smart card” that can be used to identify a subscriber of the mobile device 100 and to personalize the mobile device 100, among other things. Without the USIM card 126, the mobile device 100 is not fully operational for communication with the network 400. By inserting the USIM card/RUIM 126 into the USIM/RUIM interface 128, a subscriber can access all subscribed services. Services may include: web browsing and messaging such as e-mail, voice mail, Short Message Service (SMS), and Multimedia Messaging Services (MMS). More advanced services may include: point of sale, field service and sales force automation. The USIM card/RUIM 126 includes a processor and memory for storing information. Once the USIM card/RUIM 126 is inserted into the USIM/RUIM interface 128, it is coupled to the main processor 102. In order to identify the subscriber, the USIM card/RUIM 126 can include some user parameters such as an International Mobile Subscriber Identity (IMSI). An advantage of using the USIM card/RUIM 126 is that a subscriber is not necessarily bound by any single physical mobile device. The USIM card/RUIM 126 may store additional subscriber information for a mobile device as well, including datebook (or calendar) information and recent call information. Alternatively, user identification information can also be programmed into the flash memory 108.
The mobile device 100 is typically a battery-powered device and includes a battery interface 132 for receiving one or more rechargeable batteries 130. In at least some implementations, the battery 130 can be a smart battery with an embedded microprocessor. The battery interface 132 is coupled to a regulator (not shown), which assists the battery 130 in providing power V+ to the mobile device 100. Although current technology makes use of a battery, future technologies such as micro fuel cells may provide the power to the mobile device 100.
The mobile device 100 also includes an operating system 134 and software components 136 to 148 which are described in more detail below. The operating system 134 and the software components 136 to 148 that are executed by the main processor 102 are typically stored in a persistent store such as the flash memory 108, which may alternatively be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that portions of the operating system 134 and the software components 136 to 148, such as specific device applications, or parts thereof, may be temporarily loaded into a volatile store such as the RAM 106. Other software components can also be included, as is well known to those skilled in the art.
The subset of software applications 136 that control basic device operations, including data and voice communication applications, will normally be installed on the mobile device 100 during its manufacture. Other software applications include a message application 138 that can be any suitable software program that allows a user of the mobile device 100 to send and receive electronic messages. Various alternatives exist for the message application 138 as is well known to those skilled in the art. Messages that have been sent or received by the user are typically stored in the flash memory 108 of the mobile device 100 or some other suitable storage element in the mobile device 100. In at least some implementations, some of the sent and received messages may be stored remotely from the device 100 such as in a data store of an associated host system that the mobile device 100 communicates with.
The software applications can further include a device state module 140, a Personal Information Manager (PIM) 142, and other suitable modules (not shown). The device state module 140 provides persistence, i.e. the device state module 140 ensures that important device data is stored in persistent memory, such as the flash memory 108, so that the data is not lost when the mobile device 100 is turned off or loses power.
The PIM 142 includes functionality for organizing and managing data items of interest to the user, such as, but not limited to, e-mail, contacts, calendar events, voice mails, appointments, and task items. A PIM application has the ability to send and receive data items via the wireless network. PIM data items may be seamlessly integrated, synchronized, and updated via the wireless network with the mobile device subscriber's corresponding data items stored and/or associated with a host computer system. This functionality creates a mirrored host computer on the mobile device 100 with respect to such items. This can be particularly advantageous when the host computer system is the mobile device subscriber's office computer system.
The mobile device 100 also includes a connect module 144, and an IT policy module 146. The connect module 144 implements the communication protocols that are required for the mobile device 100 to communicate with the wireless infrastructure and any host system, such as an enterprise system, that the mobile device 100 is authorized to interface with.
The connect module 144 includes a set of APIs that can be integrated with the mobile device 100 to allow the mobile device 100 to use any number of services associated with the enterprise system. The connect module 144 allows the mobile device 100 to establish an end-to-end secure, authenticated communication pipe with the host system. A subset of applications for which access is provided by the connect module 144 can be used to pass IT policy commands from the host system to the mobile device 100. This can be done in a wireless or wired manner. These instructions can then be passed to the IT policy module 146 to modify the configuration of the device 100. Alternatively, in some cases, the IT policy update can also be done over a wired connection.
The IT policy module 146 receives IT policy data that encodes the IT policy. The IT policy module 146 then ensures that the IT policy data is authenticated by the mobile device 100. The IT policy data can then be stored in the flash memory 108 in its native form. After the IT policy data is stored, a global notification can be sent by the IT policy module 146 to all of the applications residing on the mobile device 100. Applications for which the IT policy may be applicable then respond by reading the IT policy data to look for IT policy rules that are applicable.
The IT policy module 146 can include a parser (not shown), which can be used by the applications to read the IT policy rules. In some cases, another module or application can provide the parser. Grouped IT policy rules, described in more detail below, are retrieved as byte streams, which are then sent (recursively, in a sense) into the parser to determine the values of each IT policy rule defined within the grouped IT policy rule. In at least some implementations, the IT policy module 146 can determine which applications are affected by the IT policy data and send a notification to only those applications. In either of these cases, for applications that aren't running at the time of the notification, the applications can call the parser or the IT policy module 146 when they are executed to determine if there are any relevant IT policy rules in the newly received IT policy data.
After the IT policy rules have been applied to the applicable applications or configuration files, the IT policy module 146 sends an acknowledgement back to the host system to indicate that the IT policy data was received and successfully applied.
The mobile device 100 also includes a configuration information handler 148. As described in conjunction with the remaining figures, the configuration information handler 148 determines configuration information about E-UTRA neighbor frequencies to measure while the mobile device 100 is camped on or connected to a RAT other than E-UTRA (e.g., GERAN or UTRAN). In some examples, the configuration information handler 148 receives the configuration information from the GERAN or UTRAN. In some examples, the configuration information handler 148 reads the information from the E-UTRA and reports the information to the GERAN or UTRAN. In some examples, the configuration information handler 148 stores the read information in a cache for later usage. While a single configuration information handler 148 illustrated, the recovery module may comprise multiple components and/or may be integrated with other components.
Other types of software applications can also be installed on the mobile device 100. These software applications can be third party applications, which are added after the manufacture of the mobile device 100. Examples of third party applications include games, calculators, utilities, etc.
The additional applications can be loaded onto the mobile device 100 through at least one of the wireless network, the auxiliary I/O subsystem 112, the data port 114, the short-range communications subsystem 122, or any other suitable device subsystem 124. This flexibility in application installation increases the functionality of the mobile device 100 and may provide enhanced on-device functions, communication-related functions, or both. For example, secure communication applications may enable electronic commerce functions and other such financial transactions to be performed using the mobile device 100.
The data port 114 enables a subscriber to set preferences through an external device or software application and extends the capabilities of the mobile device 100 by providing for information or software downloads to the mobile device 100 other than through a wireless communication network. The alternate download path may, for example, be used to load an encryption key onto the mobile device 100 through a direct and thus reliable and trusted connection to provide secure device communication.
The data port 114 can be any suitable port that enables data communication between the mobile device 100 and another computing device. The data port 114 can be a serial or a parallel port. In some instances, the data port 114 can be a USB port that includes data lines for data transfer and a supply line that can provide a charging current to charge the battery 130 of the mobile device 100.
The short-range communications subsystem 122 provides for communication between the mobile device 100 and different systems or devices, without the use of the wireless network. For example, the subsystem 122 may include an infrared device and associated circuits and components for short-range communication. Examples of short-range communication standards include standards developed by the Infrared Data Association (IrDA), Bluetooth, and the 802.11 family of standards developed by IEEE.
In use, a received signal such as a text message, an e-mail message, or web page download will be processed by the communication subsystem 104 and input to the main processor 102. The main processor 102 will then process the received signal for output to the display 110 or alternatively to the auxiliary I/O subsystem 112. A subscriber may also compose data items, such as e-mail messages, for example, using the keyboard 116 in conjunction with the display 110 and possibly the auxiliary I/O subsystem 112. The auxiliary subsystem 112 may include devices such as: a touch screen, mouse, track ball, infrared fingerprint detector, an optical navigation control or trackpad, or a roller wheel with dynamic button pressing capability. The keyboard 116 is preferably an alphanumeric keyboard and/or telephone-type keypad. However, other types of keyboards may also be used. A composed item may be transmitted over the wireless network through the communication subsystem 104.
For voice communications, the overall operation of the mobile device 100 is substantially similar, except that the received signals are output to the speaker 118, and signals for transmission are generated by the microphone 120. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, can also be implemented on the mobile device 100. Although voice or audio signal output is accomplished primarily through the speaker 118, the display 110 can also be used to provide additional information such as the identity of a calling party, duration of a voice call, or other voice call related information.
While an example manner of implementing the mobile device 100 including the configuration information handler 148 is illustrated in
In E-UTRA, MBSFN subframe configuration information may be signaled to the mobile device 100 in system information transmitted by the E-UTRAN. For example system information block type 2 (SIB2) may indicate MBSFN-SubframeConfigList. The list may comprise up to 8 configurations of MBSFN subframe allocation as shown below. For example, the list may represent MBSFN subframe allocation up to 32*6 subframes in up to 8 bitmaps.
MBSFN-SubframeConfig
The IE MBSFN-SubframeConfig defines subframes that are reserved for MBSFN in downlink.
MBSFN-SubframeConfig information element
When the mobile device 100 measures serving and neighbour cells, the UE may utilize the MBSFN allocation information to locate the symbols carrying CRS. For example, in a non-MBSFN subframe, the mobile device 100 may expect CRS from port 0 in symbols 0, 3, 7 and 10, and in an MBSFN subframe, the mobile device 100 may expect CRS from port 0 in the symbol 0 only. If the mobile device 100 does not have the MBSFN allocation information, the mobile device 100 is expected to assume that any subframe that can be an MBSFN may be an MBSFN subframe.
In order to facilitate neighbor cell measurements, system information block type 3 (SIB3) indicates NeighCellConfig (Neighbor Cell Configuration). For example, if it is set to 00, the mobile device 100 needs to assume that all subframes except non-MBSFN subframes may be MBSFN subframes. If it is set to 01, the mobile device 100 may assume that MBSFN subframe allocations are the same (or a subset) as PCell or the serving cell.
NeighCellConfig
The IE NeighCellConfig is used to provide the information related to MBSFN and TDD UL/DL configuration of neighbor cells.
NeighCellConfig Information Element
Similar to MBSFN subframes, TDD configuration (shown below) is taken into account when measuring neighbor cells. Only downlink and Downlink Pilot Time Slot (DwPTS) portions of special subframes contain symbols carrying CRS.
Special subframe configuration and uplink downlink configuration is indicated by specialSubframePatterns and subframeAssignment of TDD-Config, respectively in system information block type 1.
The IE TDD-Config is used to specify the TDD specific physical channel configuration.
While the foregoing descriptions providing notification of E-UTRAN configuration while the mobile device 100 is camped in a E-UTRAN cell, such communication is not provided to the mobile device 100 while camped in a cell utilizing a RAT other than E-UTRA. Accordingly, methods and apparatus disclosed herein facilitate informing the mobile device 100 of the E-UTRA configuration.
The GERAN 404 and the UTRAN 410 route packet data via a service general packet radio service (GPRS) support node (SGSN) 406. The E-UTRAN 412 routes packet data via a serving gateway 408 and communicates with the SGSN 406 via the mobile management entity 414. The SGSN 406, MME 414, and serving gateway 408 are well known in the art and, thus, are not described in further detail herein.
The GERAN 404, UTRAN 410, and E-UTRAN 412 are configured to facilitate informing the UE 402 of configuration information for the E-UTRAN while the UE 402 is camped on the GERAN 404 or the UTRAN 410.
Flowcharts of example processes performed by the GERAN 404 and/or UTRAN 410 are shown in
As mentioned above, the example processes of
The GERAN 404 and/or the UTRAN 410 transmits the configuration information per E-UTRA frequency received in block 502 (block 504). For example, a radio network controller (RNC) in, for example, the UTRAN 410, may include a MBSFN-SubframeConfigList in an E-UTRA frequency and priority information list carried in a system information block (e.g., system information block type 19), in an E-UTRA frequency list in a measurement control message, etc. The GERAN 404 may include an MBSFN-SubframeConfigList in an E-UTRAN Neighbor Cells information in a system information block (e.g., system information Type 2quater), in Measurement Information and Packet Measurement Information message, etc. For example, the GERAN 404 and/or the UTRAN 410 may determine that an MBSFN-SubframeConfigList received from the E-UTRAN 410 is common for all neighbor cells on a particular E-UTRAN frequency for an area of sufficiently large size. Additionally or alternatively, the RNC may include TDD configuration information (TDD-Config) if the corresponding E-UTRA frequency is for TDD in an E-UTRA frequency and priority information list carried in a system information block (e.g., system information block type 19), in an E-UTRA frequency list in a measurement control message, etc. The GERAN 404 may include a TDD-Config in an E-UTRAN Neighbor Cells information element in a system information block (e.g., system information Type 2quater), in Measurement Information and Packet Measurement Information message, etc.
An example E-UTRA frequency list transmitted by the UTRAN 410 to the mobile device 100 is shown in Table 3 below. The example E-UTRA frequency list includes MBSFN-SubframeConfig List and TDD-Config elements. Alternatively, only one of the MBSFN-SubframeConfigList and the TDD-Config elements may be included in a list.
Alternatively, the GERAN 404 and/or the UTRAN 410 may transmit the information to the mobile device 100 (block 504) utilizing a combined MBSFN subframe allocation. Transmitting the information utilizing a combined MBSFN subframe allocation avoids the mobile device 100 decoding PBCH to determine the SFN to apply the MBSFN-SubframeConfig List for RRM measurement of E-UTRAN neighbor cells. When MBSFN subframe allocation periodicity is larger than one radio frame, the mobile device 100 needs to know the SFN of an E-UTRAN cell to determine whether a current subframe is configured as an MBSFN subframe or not. In general, the mobile device 100 should not be required to read system information of another RAT. An example combined MBSFN subframe allocation indicates all the MBSFN subframes indicated in the MBSFN-SubframeConfigList within a single radio frame. For example, if subframe #6 and subframe #7 are assigned as MBSFN subframes in even radio frame and subframe #6 is assigned as an MBSFN subframe in odd radio frame, the combined allocation would be subframe #6 and subframe #7. The combined allocation may be repeated every radio frame so that the mobile device 100 does not have to know the SFN of the E-UTRA neighbor cell.
For example in FDD: The first/leftmost bit may define the allocation for subframe #1 of the radio frame indicated by mcch-RepetitionPeriod and mcch-Offset, the second bit for #2, the third bit for #3, the fourth bit for #6, the fifth bit for #7 and the sixth bit for #8. For example, in TDD: The first/leftmost bit may define the allocation for subframe #3 of the radio frame indicated by mcch-RepetitionPeriod and mcch-Offset, the second bit for #4, third bit for #7, fourth bit for #8, fifth bit for #9. Uplink subframes are not allocated. The last bit is not used.
Alternatively, a single bit may be indicated if MBSFN is used or not used. If the bit is indicated, the mobile device 100 may assume the all the subframes except the non-MBSFN subframes are assigned as MBSFN subframes during the measurement of E-UTRA neighbor cells. If the bit is not indicated, the mobile device 100 may assume none of the subframes are MBSFN subframes. Alternatively the bit, when present, may indicate that MBSFN is used. In such an example, legacy networks that do not support MBSFN will not transmit the bit and mobile devices will not assume that MBSFN is utilized when no bit is present.
The configuration information handler 148 then analyzes the received information to determine configuration information for E-UTRA neighbor frequencies or cells (block 606) for RRM measurement. According to the illustrated example, the example E-UTRA information includes at least one of MBSFN allocation information and/or TDD configuration information for E-UTRA neighbor frequencies or cells. For example, the configuration information handler 148 may access a MBSFN-SubframeConfigList and/or a TDD-Config element included in the E-UTRA information.
The configuration information handler 148 then causes the mobile device 100 to perform a measurement of the E-UTRAN 412 based on the extracted configuration information (block 608). For example, the configuration information reveals which subframes may be configured for MBSFN and which are not configured for MBSFN and can, thus, utilize all the symbols carrying CRS in the subframes not allocated for MBSFN and/or MBSFN subframes for performing measurements.
When it is not time to check for updates (block 708), the configuration information handler 148 determines if any of the configuration information in the cache has expired (block 710). For example, configuration information may expire when it is not updated after a period of time (e.g., 30 minutes). When configuration information has expired, the configuration information handler 148 deletes the expired information from the cache (block 712)
When the configuration information in the cache is not expired (block 710) and has not been deleted in block 712, the configuration information handler 148 measures E-UTRA neighbor cells based on the cached neighbor configuration information (block 714). For example, block 714 may be performed at any time that a measurement is desired and information in the cache may be utilized whenever it is available. Accordingly, by caching the configuration information, the configuration information handler 148 may take advantage of the semi-static nature of MBSFN allocations.
In response to the request from the GERAN 404 and/or the UTRAN 410, the first mobile device 100 reads information from the E-UTRA neighbor cell(s) and transmits the information to the GERAN 404 and/or the UTRAN 410 (e.g., using RRC Measurement Report message in UMTS). Accordingly, the GERAN 404 and/or the UTRAN 410 receives the report from the mobile station 100 (block 804). The GERAN 404 and/or the UTRAN 410 extracts the configuration information from the report sent by the first mobile station 100 (block 806) and transmits the configuration information to a second mobile device 100 (or several other mobile devices) (block 808) The GERAN 404 and/or the UTRAN 410 may request the configuration information from one or more mobile devices 100 to determine that MBSFN subframe configuration and/or TDD configuration is common for a sufficiently large area in GERAN or UTRAN per E-UTRA frequency (e.g., more than 20 macro GERAN or UTRAN cells). The GERAN 404 and/or the UTRAN 410 may provide the configuration information to the UEs when the above-condition is met. The GERAN 404 and/or the UTRAN 410 then determines if it is time to check for updates to the configuration information (block 810). If it is not time to check for updates, the GERAN 404 and/or the UTRAN 410 continues waiting until it is time to check for updates. If it is time to check for updates, the GERAN 404 and/or the UTRAN 410 selects another mobile device 100 (e.g., a mobile device 100 different than the first mobile device 100) (block 812) and control returns to block 802 to instruct the newly selected mobile device 100. By selecting different mobile devices 100 each time an update is performed, the GERAN 404 and/or the UTRAN 410 can reduce the amount of resource utilization of any given mobile device 100.
The GERAN 404 and/or the UTRAN 410 may optimize selection of mobile devices 100 for gathering E-UTRA information. For example, because reading multiple SIBs (SIB1, 2 and 3) in an E-UTRA frequency may take more time and may be more disruptive to on-going communication with a serving cell (e.g. in UTRAN frequency) than just reading SIB1 (e.g. reading and reporting global cell identity), the GERAN 404 and/or the UTRAN 410 may select a mobile station 100 that can perform the task without configuring measurement gap based on the measurement capability of the mobile station 100. For example, to obtain the configuration information for a specific E-UTRA frequency in a first band, the network may select a mobile device 100 that does not require a measurement gap or compressed mode to measure the first band while the mobile station 100 is engaging communication with the GERAN 404 and/or the UTRAN 410 in a second band.
Alternatively, the GERAN 404 and/or the UTRAN may instruct the mobile device 100 to read and report only one of TDD-Config in SIB1, MbsfnSubframeConfig in SIB2 and NeighbourCellConfig in SIB3 to minimize the possible disruption to the on-going communication of a mobile device 100. The GERAN 404 and/or the UTRAN may obtain the complete configuration information by instructing multiple mobile devices 100 to report the various information elements.
While the foregoing describes a network instructing the mobile device 100 to obtain MBSFN configuration information and/or TDD configuration information, the network may instruct the mobile device 100 to retrieve any other type of information for reporting to the network. For example, the GERAN 404, the UTRAN 410, and/or the E-UTRAN 412 may instruct the mobile device 100 to retrieve, read, measure, etc. information about any of the GERAN 404, the UTRAN 410, and/or the E-UTRAN 412 and report the information to the network.
While the foregoing describes an example block diagram implementations and processes for implementing the mobile device 100, the GERAN 404, the UTRAN 410, and the E-UTRAN 412 other implementations are possible. For example, additional blocks may be included and additional or different connections between the blocks may exist.
While the foregoing makes reference to GERAN and UTRAN and RATs other than E-UTRAN, the RATs other than E-UTRAN may include any other RATs such as CDMA2000 or any other RATS.
The present disclosure may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the disclosure is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
