CN106664630B - Using client-specific RGS to improve performance of multi-SIM and multi-RAT devices - Google Patents

Abstract

Various embodiments provide methods implemented in a mobile communication device (e.g., a multi-RAT communication device) for maintaining at least one separate RGS value for each of a plurality of RATs operating on the mobile communication device. In particular, a device processor (e.g., crystal oscillator manager) operating on the mobile communication device may maintain separate, up-to-date RGS values for each of the plurality of RATs and may associate each of the plurality of RATs with its respective RGS value. By tracking the respective RGS values of the multiple RATs, the device processor may ensure that the appropriate RGS values are used to facilitate respective operations of each RAT, such as acquisition/reacquisition operations, sleep schedule calculations, and handover/inter-RAT measurement operations. Thus, various embodiments may improve the performance of each RAT as well as the overall performance of the mobile communication device.

Description

Using client-specific RGS to improve performance of multi-SIM and multi-RAT devices

RELATED APPLICATIONS

The present application claims priority to U.S. provisional application No.61/993,297 entitled "Using Client-Specific RGSTo improved Performance on Multi-SIM and Multi-RAT Devices", filed on 15/5 2014, which is incorporated herein by reference in its entirety.

Background

Some new designs of mobile communication devices, such as smart phones, tablet computers, and laptop computers, include two or more radio access technologies ("RATs"), to which a real device can connect. Examples of radio access networks include LTE, GSM, TD-SCDMA, CDMA2000, and WCDMA. Such mobile communication devices (sometimes referred to as "multi-RAT communication devices") may also include one or more Radio Frequency (RF) communication circuits or "RF resources" to provide users with directions to different networks via two or more RATs.

A multi-RAT communication device may include a mobile communication device (i.e., a multi-Subscriber Identity Module (SIM), multi-active, or "MSMA" communication device) having multiple SIM cards, each associated with a different RAT and using different RF resources to connect to different mobile phone networks. The multi-RAT communication device may also include a multi-SIM multi-idle or "MSMS" communication device that each includes two or more SIM cards/subscriptions, each associated with a separate RAT, and the separate RATs share one or more RF chains to communicate with multiple separate mobile telephone networks on behalf of their respective subscriptions. Further, the multi-RAT communication device may include a single SIM communication device, such as a single radio LTE ("SRLTE") communication device or a simultaneous GSM + LTE ("SGLTE") communication device, each including one SIM card/subscription associated with two RATs that share a single shared RF resource to connect to two separate mobile networks on behalf of one subscription.

Typically, conventional multi-RAT communication devices include, among other things, crystal oscillators used to provide stable clock signals for digital integrated circuits and to stabilize frequencies for radio transmitters and receivers used by each RAT on the device to enable the RATs to communicate with base stations. When the frequency is stabilized, the multi-RAT communication device typically performs adjustments to the operating frequency of the crystal oscillator to account for the natural deviation of the base station from its intended/standard frequency or timing (i.e., sometimes referred to collectively as the "frequency error" of the base station). For example, in response to determining a frequency error of a base station of a RAT, the multi-RAT communication device may adjust the frequency of the crystal oscillator to account for the determined frequency error of the base station, thereby enabling the RAT to acquire/maintain service with the base station using the corrected frequency.

Currently, the RATs on a multi-RAT communication device may each communicate with a variety of different base stations. In conventional networks, the timing mechanisms/clocks of base stations within the same network are typically synchronized to ensure consistent service of devices on the network, and as a result, the base stations within the networks typically have the same frequency error. However, base stations associated with different networks or service providers typically do not have comparable frequency errors because the separate networks are typically not synchronized with each other. Furthermore, in some rare cases, it is also possible that base stations within the same network have different frequency errors for various reasons, such as aged frequency generating components on some base stations.

Because multi-RAT communication devices must account for frequency errors of various different base stations and networks in order for each RAT in the plurality of RATs to communicate with and/or receive service from a corresponding base station, the potential differences in frequency errors between different base stations recently presents design and operational challenges for multi-RAT communication devices.

Disclosure of Invention

Various embodiments provide methods, devices, and non-transitory processor-readable storage media for improving performance of multiple Radio Access Technologies (RATs) on a mobile communication device. An embodiment method may include: obtaining a most Recent Good System (RGS) value for each of the plurality of RATs, associating the obtained RGS value with each of the plurality of RATs, and storing the obtained RGS value and the association of the obtained RGS values.

Some embodiment methods may include: associating the obtained RGS values with at least one attribute based on times at which the RGS values for the plurality of RATs were obtained. In some embodiments, the attribute may include one of a temperature of the mobile communication device, a temperature of a crystal oscillator of the mobile communication device, a base station identification, a subscription identification, a geographic location of the mobile communication device, a serving network identification, and a timestamp.

Some embodiment methods may include: the method includes identifying a RAT of the plurality of RATs associated with a request for an RGS value from a requesting entity, retrieving a stored RGS value associated with the identified RAT, and sending the retrieved RGS value to the requesting entity.

In some embodiments, retrieving the stored RGS value associated with the identified RAT may include: the method includes identifying a first set of RGS values associated with the identified RAT, determining a confidence value for each of the first set of RGS values, and retrieving a stored RGS value of the first set of RGS values having a highest confidence value in the first set of RGS values.

Some embodiment methods may include: adjusting the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS value, wherein sending the retrieved RGS value to the requesting entity may include sending the adjusted RGS value to the requesting entity.

In some embodiments, adjusting the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS value may include: the retrieved RGS value is adjusted based on a temperature change associated with the retrieved RGS value.

In some embodiments, retrieving the stored RGS value associated with the identified RAT may include: the method includes identifying a first set of RGS values associated with the identified RAT, determining whether at least one stored RGS value is in the first set of RGS values, and retrieving an alternate stored RGS value not associated with the identified RAT in response to determining that no RGS value is in the first set of RGS values.

Some embodiment methods may include: determining whether at least one RGS value of the first set of RGS values has a confidence value that satisfies a confidence threshold in response to determining that at least one RGS value is in the first set of RGS values, retrieving an alternate stored RGS value that is not associated with the identified RAT in response to determining that none of the first set of RGS values associated with the identified RAT has a confidence value that satisfies the confidence threshold, and retrieving the stored RGS value of the first set of RGS values that has a highest confidence value in the first set of RGS values in response to determining that an RGS value of the first set of RGS values associated with the identified RAT has a confidence value that satisfies the confidence threshold.

In some embodiments, retrieving alternate stored RGS values that are not associated with the identified RAT may include: the method includes identifying a subscription associated with the identified RAT, identifying a second set of RGS values associated with the identified subscription, and determining a confidence value for each stored RGS value of the second set of RGS values.

Some embodiment methods may include: the method further includes determining whether there is a stored RGS value in the second set of RGS values that satisfies a confidence threshold, and retrieving the stored RGS value in the second set of RGS values having the highest confidence value within the second set of RGS values in response to determining that there is a stored RGS value in the second set of RGS values that satisfies the confidence threshold.

Some embodiment methods may include: determining whether there are stored RGS values available on the mobile communication device in response to determining that there are no stored RGS values of the second set of RGS values associated with the identified subscription that satisfy the confidence threshold, retrieving a stored RGS value available on the mobile communication device having a highest confidence value in response to determining that there are stored RGS values available on the mobile communication device, and generating an RGS value approximation using a mathematical model in response to determining that there are no stored RGS values available on the mobile communication device.

Some embodiment methods may include: the method includes determining an updated RGS value for a RAT of the plurality of RATs based on current network conditions of the RAT, associating the updated RGS value with the RAT, and storing the updated RGS value and the association of the updated RGS value with the RAT.

Some embodiment methods may include: associating the updated RGS value with at least one current attribute based on the time at which the updated RGS value was determined, wherein storing the updated RGS value and the association of the updated RGS value with the RAT may include storing the updated RGS value and the association of the updated RGS value with the RAT and with the at least one current attribute.

Some embodiment methods may include: the method includes determining an updated RGS value for a RAT of the plurality of RATs based on current network conditions of the RAT, retrieving a stored RGS value associated with the RAT, and modifying the stored RGS value associated with the RAT based on the updated RGS value.

Some embodiment methods may include: identifying at least one attribute associated with the updated RGS value based on a time at which the updated RGS value was determined, and modifying at least one attribute associated with the modified RGS value based on the identified at least one attribute associated with the updated RGS value.

Some embodiment methods may include: retrieving an RGS value associated with a RAT of the plurality of RATs in response to receiving a sleep notification from the RAT, determining a period based on the sleep notification and the retrieved RGS value, and configuring the RAT to wake up upon expiration of the period.

Some embodiment methods may include: adjusting the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS value, wherein determining a period based on the sleep notification and the retrieved RGS value may comprise determining the period based on the sleep notification and the adjusted RGS value.

Some embodiment methods may include: the method generally includes determining that a RAT of the plurality of RATs is about to perform one of a network acquisition operation and a network reacquisition operation, retrieving an RGS value associated with the RAT, and configuring the RAT to perform the one of the network acquisition operation and the network reacquisition operation based on the retrieved RGS value.

Some embodiment methods may include: adjusting the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS value, wherein configuring the RAT to perform the one of the network acquisition operation and the network reacquisition operation based on the retrieved RGS value may include configuring the RAT to perform the one of the network acquisition operation and the network reacquisition operation based on the adjusted RGS value.

Some embodiment methods may include: retrieving an RGS value associated with a base station in response to determining that a RAT of the plurality of RATs is about to perform a handover operation to the base station, and configuring the RAT to perform the handover operation to the base station based on the retrieved RGS value.

Some embodiment methods may include: adjusting the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS value, wherein configuring the RAT to perform the handover operation to the base station based on the retrieved RGS value may include configuring the RAT to perform the handover operation to the base station based on the adjusted RGS value.

Some embodiment methods may include: retrieving an RGS value associated with a second RAT of the plurality of RATs in response to determining that the first RAT is about to perform an inter-RAT measurement of the second RAT, and configuring the first RAT to perform the inter-RAT measurement of the second RAT based on the retrieved RGS value.

Some embodiment methods may include: adjusting the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS value, wherein configuring the first RAT to perform the inter-RAT measurement of the second RAT based on the retrieved RGS value may include configuring the first RAT to perform the inter-RAT measurement of the second RAT based on the adjusted RGS value.

Various embodiments may include a mobile communication device configured with processor-executable instructions to perform the operations of the methods described above.

Various embodiments may include a mobile communication device having means for performing the functions of the operations of the method described above.

Various embodiments may include a non-transitory processor-readable medium on which processor-executable instructions are stored that are configured to cause a processor of a mobile communication device to perform operations of the method described above.

Drawings

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

Fig. 1 is a block diagram of a communication system for a mobile telephone network suitable for use in various embodiments.

Fig. 2 is a component block diagram of a mobile communication device in accordance with various embodiments.

Figure 3 is a signaling and call flow diagram illustrating conventional RGS value acquisition and updating by components of a mobile communication device.

Fig. 4 is a signaling and call flow diagram illustrating conventional RGS value acquisition and updating by components of a mobile communication device, in accordance with various embodiments.

Figures 5A and 5B are data tables illustrating RGS value associations for various embodiments.

Figure 6 is a process flow diagram illustrating a method for associating RGS values with RATs, in accordance with various embodiments.

Figure 7A is a process flow diagram illustrating a method for sending an RGS value associated with a RAT to a requesting entity, in accordance with various embodiments.

Figure 7B is a process flow diagram illustrating a method for obtaining an RGS value based on a confidence value for the RGS value, in accordance with various embodiments.

Figure 7C is a process flow diagram illustrating a method for obtaining an alternative RGS value for a RAT in response to determining that the RAT is not associated with any RGS value or with an RGS value that satisfies a confidence threshold, in accordance with various embodiments.

Figure 8A is a process flow diagram illustrating a method for updating an RGS value associated with a RAT in accordance with various embodiments.

Figure 8B is a process flow diagram illustrating a method for updating an RGS value associated with a RAT in accordance with various embodiments.

Figure 9 is a process flow diagram illustrating a method for configuring a RAT to sleep based on an RGS value associated with the RAT, in accordance with various embodiments.

Fig. 10 is a process flow diagram illustrating a method for configuring a RAT to perform network acquisition or reacquisition based on an RGS value associated with the RAT, in accordance with various embodiments.

Figure 11 is a process flow diagram illustrating a method for configuring a RAT to perform handover operations based on RGS values associated with base stations to which the RAT is transitioning, in accordance with various embodiments.

Fig. 12 is a process flow diagram illustrating a method for configuring a first RAT to perform inter-RAT measurements of a second RAT based on an RGS value associated with the second RAT, in accordance with various embodiments.

Figure 13 is a component block diagram of a mobile communication device suitable for implementing methods of some embodiments.

Detailed Description

Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to specific examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.

As used herein, the terms "wireless device," "mobile communication device," and "multi-RAT communication device" are used interchangeably and refer to any or all of a cellular telephone, a smartphone, a personal or mobile multimedia player, a personal digital assistant, a laptop computer, a personal computer, a tablet computer, a smart book, a palmtop computer, a wireless email receiver, a multimedia internet enabled cellular telephone, a wireless game controller, and similar personal electronic devices that include a programmable processor, memory, and circuitry for connecting to at least two mobile communication networks. Various embodiments may be useful in mobile communication devices such as smartphones, and thus such devices are referred to as being referred to in the description of various embodiments. However, various embodiments may be useful in any electronic device that may each maintain multiple RATs utilizing one or more RF resources associated with one or more subscriptions/SIMs.

A conventional mobile communication device may include a crystal oscillator manager (e.g., a processor or controller) that obtains a current frequency error value for a base station (e.g., from a RAT on the device). This frequency error value is sometimes referred to as an "RGS value," which represents a "recently good system," and is typically utilized by the crystal oscillator manager to enable the RAT to perform network acquisition operations and/or network reacquisition operations by stabilizing the frequency and/or by adjusting the frequency of communications exchanged with the RAT's base station. The crystal oscillator manager also uses the RGS value to program a sleep cycle of the RAT by converting the RGS value from a frequency domain to a time domain value that is used to determine a period during which the RAT may perform sleep/idle mode operations. For example, to ensure that the RAT sleeps for an expected or desired amount of time, the crystal oscillator manager may use the RGS value to adjust the current frequency value of the crystal oscillator to determine an appropriate amount of time to permit the RAT to sleep.

In conventional multi-RAT communication devices, the crystal oscillator manager maintains only one RGS value (sometimes referred to as a "system RGS value") to serve all RATs operating on the multi-RAT communication device. In current practice, the crystal oscillator manager periodically receives updated RGS values from multiple RATs and retains only the most recent RGS values received from any of the multiple RATs. For example, the crystal oscillator manager may replace a first system RGS value received from a first RAT with a second system RGS value received from a second RAT, with the result simply replacing the second system RGS value with a third system RGS value received from a third RAT at a later time. Using only one system RGS value often results in errors in sleep duration calculations and problems when performing acquisition/reacquisition for many of the multiple RATs due to potential differences in frequency error between different networks (or even between respective base stations of the same network). Furthermore, in many scenarios, the respective pilot timing/slew errors (slew error) during slotted mode (slotted mode) have been observed in the mobile device to serve multiple RATs by using only one system RGS value.

In summary, various embodiments provide a method implemented in a mobile communication device (e.g., a multi-RAT communication device) for maintaining at least one separate RGS value for each of a plurality of RATs operating on the mobile communication device. In particular, a device processor (e.g., crystal oscillator manager) operating on the mobile communication device may maintain separate, up-to-date RGS values for each of the plurality of RATs and may associate each of the plurality of RATs with its respective RGS value. By tracking the respective RGS values of the multiple RATs, the device processor may ensure that the appropriate RGS values are used to facilitate respective operations of each RAT, such as acquisition/reacquisition operations, sleep schedule calculations, and handover/inter-RAT measurement operations. Thus, various embodiments may improve the performance of each RAT as well as the overall performance of the mobile communication device.

In various embodiments, the mobile communication device may include a crystal oscillator for stabilizing the frequency and performing timing calculations as described, and the characteristics of the oscillation frequency of the crystal may vary depending on the temperature. For example, the oscillation frequency of the crystal may be slower when exposed to relatively cooler temperatures and faster when exposed to relatively hotter temperatures. In some embodiments, a device processor operating at the mobile communication device may adjust the RGS value based on the effect of temperature on the operating frequency of the crystal oscillator. In the above example, the device processor may increase the RGS value to compensate for the cooler temperature or may decrease the RGS value to compensate for the warmer temperature. In some embodiments, the crystal oscillator may be a "temperature compensated" crystal oscillator, meaning that the oscillator is designed to reduce the effect of temperature on the oscillation frequency of the crystal. In other embodiments, the crystal oscillator may be a "non-temperature compensated" crystal oscillator, and the device processor may perform various operations of the embodiment methods to compensate for the relatively large effect of temperature on the operating frequency of the crystal oscillator.

In some embodiments, the mobile communication device processor may maintain a record of changes in temperature that may have an effect on the performance of the crystal oscillator for each of the plurality of RATs, and may adjust the specific RGS value for each RAT based on the temperature change specific to that RAT. In particular, the mobile communication device processor may associate the temperature of the mobile communication device with an RGS value at a time at which the RAT reports the RGS value to the device processor. Thus, at a later time, the mobile communication device processor may adjust the RGS value by comparing the stored temperature value associated with the RGS value to the current temperature of the mobile communication device and adjusting the RGS value based on the difference between the temperatures. Such embodiments may be useful, particularly in mobile communication devices that include crystal oscillators that are not temperature compensated, when useful in multiple mobile communication devices, since relatively high variations in the operating frequency of these crystal oscillators may be effectively accounted for by maintaining a record of temperature changes that may have an impact on the RGS value associated with a particular RAT.

The stored RGS value may reflect the factors and conditions of the particular combination experienced/observed on the mobile communication device at the initial time when the RGS value was received on the mobile communication device. Examples of factors and conditions experienced/observed on the mobile communication device may include temperature (as described), geographic location, time (e.g., timestamp), sign-up, etc. of a device/crystal oscillator associated with the RGS value at the time the RGS value was received/obtained. Thus, the stored RGS may be most useful in situations where the current condition of the mobile communication device is similar to the condition that existed at the time the RGS value was initially received/obtained.

In some embodiments, the mobile communication device processor may maintain a record of the conditions/circumstances surrounding the RGS values by storing and maintaining at least one "attribute" for each RGS value stored on the mobile communication device. In such embodiments, the attributes of the RGS value may describe aspects of the condition/environment at the time when the RGS value was initially obtained/received on the mobile communication device. In particular, the attributes associated with the RGS value may include one or more of: one RAT or multiple RATs associated with the RGS value; a subscription associated with one RAT or multiple RATs, a temperature of a mobile communication device; temperature of crystal oscillator, service network (e.g., GSM, WCDMA); geographic location/GPS coordinates of the mobile communication device; and the time at which the RGS value was obtained, e.g., in the form of a timestamp. In such embodiments, the mobile communication device processor may use these attributes to distinguish RGS values in order to select/use the stored RGS value that is most appropriate for the current conditions/environment of the mobile communication device. For example, the mobile communication device processor may determine a current geographic location of the mobile device and may retrieve a stored RGS value associated with the current geographic location.

In some embodiments, the mobile communication device processor may store and maintain each RGS value and the association/attributes of the RGS values in memory. The RGS values may be stored and maintained in a lookup table, a database, an associated list, and/or any other known data structure or storage mechanism.

In some embodiments, the mobile communication device processor may respond to the request by identifying a RAT associated with the request for RGS values from the requesting entity (e.g., RAT, sleep controller, GPS module/receiver, etc.) and sending the RGS values associated with the RAT associated with the request to the requesting entity. For example, the first RAT may request an RGS value to enable the first RAT to perform reacquisition activities upon exiting sleep mode, and the mobile communication device processor may recognize that the first RAT is associated with the request and may return the RGS value associated with the first RAT to the first RAT.

As described, the scenarios where RGS values may be best suited for use are: the current condition/environment of the mobile communication device is similar to the condition/environment that occurs when an RGS value is received/obtained on the mobile communication device. In other words, the RGS value is very useful (i.e., reliable) when the properties associated with the RGS value are consistent with the current conditions of the mobile communication device. In view of this, in some embodiments, the mobile communication device processor may retrieve the stored RGS value for the requesting entity based on a "confidence value" of the RGS value, which may be a measure of the reliability or accuracy of the prediction of the RGS value. For example, a RAT using an RGS value with a higher confidence value may acquire service faster than when using an RGS value with a lower confidence value because the higher confidence value may be more accurate or reliable, thereby requiring an overall shorter search window for acquiring service.

In some embodiments, the confidence value for the RGS value may be based on a comparison between the attribute associated with the stored RGS value and the current condition/environment of the mobile communication device. For example, a lower confidence value for a stored RGS value may indicate that the stored RGS value is associated with (i.e., applicable to) a condition/attribute that is substantially different from a condition currently experienced/observed on the mobile communication device. In another example, the stored RGS value may have a higher confidence value when its properties are similar to the current situation.

Thus, in some embodiments, in response to receiving a request for an RGS value of a first RAT from a requesting entity, the mobile communication device processor may initially attempt to retrieve a stored RGS value associated with the first RAT such that the stored RGS value has a sufficiently high confidence value. In such embodiments, the mobile communication device processor may determine whether there is a stored RGS value associated with the first RAT that satisfies (e.g., is greater than or equal to) a minimum confidence threshold and may retrieve the stored RGS value having a confidence that satisfies the confidence threshold. In response to determining that no stored RGS associated with a RAT satisfies the confidence threshold, the mobile communication device processor may attempt to retrieve a stored RGS value that satisfies the confidence threshold from a set of RGS values associated with a subscription of a first RAT (e.g., associated with a second RAT associated with the same subscription); if it fails, any other stored RGS values that meet the confidence threshold are retrieved. If no stored RGS value is available, the mobile communication device processor may use a mathematical model to generate an RGS value approximation (see FIG. 7C).

In some embodiments, the mobile communication device processor may monitor for changes in network conditions of the RAT related to frequency error. In response to detecting a change in frequency error (e.g., upon reselection of the RAT to another base station), the mobile communication device processor may determine an updated RGS value for the RAT based on current network conditions of the RAT and may associate the updated RGS value with the RAT. In some embodiments, the mobile communication device processor may also associate at least one attribute of the current condition/environment of the mobile communication device with the updated RGS value. For example, the current temperature of the crystal oscillator may be associated with the updated RGS value to ensure that future temperature corrections/compensations for the updated RGS value are accurate.

In some embodiments, the mobile communication device processor may modify the previously stored RGS value based on the updated value of RGS. In other words, rather than overwriting the previously stored RGS value with a potentially spurious updated RGS value, the mobile communication device processor may adjust the previously stored RGS value (e.g., by averaging the two RGS values) to prevent drastic changes in the RGS value that may negatively impact performance on the mobile communication device.

In some embodiments, a mobile communication device processor (e.g., a sleep controller) on the mobile communication device may determine a period of time based on an RGS value associated with a RAT to allow the RAT to remain in a sleep/idle mode. As a result, the mobile communication device processor may ensure that the calculated sleep duration of the RAT is accurate (i.e., not too long or too short). In some embodiments, the mobile communication device processor may adjust/compensate the RGS value based on a change in at least one stored property associated with the RGS value, such as by adjusting the RGS value based on a temperature change associated with the RGS value to avoid timing errors caused by changes in the operating frequency of the crystal oscillator of the mobile communication device.

In some embodiments, a mobile communication device processor on a mobile communication device may obtain an RGS value associated with a RAT and may provide the RGS value to the RAT to enable the RAT to perform network acquisition or reacquisition operations using the RGS value. In some embodiments, the mobile communication device processor may adjust/compensate the RGS value based on a change in at least one stored attribute associated with the RGS value. For example, the mobile communication device processor may adjust the RGS value based on a temperature change associated with the RGS value to provide the RAT with the correct frequency for the RAT to establish or reestablish service with the base station.

In some embodiments, in response to determining that a RAT is or is about to perform a handover operation to a base station, a mobile communication device processor on a mobile communication device may obtain an RGS value associated with the base station and may provide the RGS value to the RAT to enable the RAT to perform the handover operation using the RGS value.

In some embodiments, in response to determining that the first RAT will or is about to perform an inter-RAT measurement of the second RAT, the mobile communication device processor may obtain an RGS value associated with the measured second RAT and may provide the RGS value to the first RAT to enable the first RAT to perform the inter-RAT measurement using the RGS value.

Various embodiments may be implemented in a variety of communication systems 100, such as at least two mobile phone networks, an example of which is shown in fig. 1. The first mobile network 102 and the second mobile network 104 each typically include a plurality of cellular base stations (e.g., a first base station 130 and a second base station 140). The first mobile communication device 110 may communicate with the first mobile network 102 through a cellular connection 132 to the first base station 130. The first mobile communication device 110 may also communicate with the second mobile network 104 through a cellular connection 142 to the second base station 140. The first base station 130 may communicate with the first mobile network 102 over a wired connection 134. The second base station 140 may communicate with the second mobile network 104 through a wired connection 144.

The second mobile communication device 120 may similarly communicate with the first mobile network 102 through a cellular connection 132 to the first base station 130. The second mobile communication device 120 may also communicate with the second mobile network 104 through a cellular connection 142 to the second base station 140. The cellular connections 132 and 142 may be implemented by two-way wireless communication links such as 4G, 3G, CDMA, TDMA, WCDMA, GSM and other mobile telephone communication technologies.

Although the mobile communication devices 110, 120 are shown connected to two mobile networks 102, 104, in some embodiments (not shown), the mobile communication devices 110, 120 may include two or more subscriptions to two or more mobile networks and may connect to these subscriptions in a manner similar to that described above.

In some embodiments, the first mobile communication device 110 may establish a wireless connection 152 with the peripheral device 150 for use in connection with the first mobile communication device 110. For example, the first mobile communication device 110 may be via bluetooth

The link communicates with a personal computing device (e.g., a "smart watch") having bluetooth functionality. In some embodiments, the first mobile communication device 110 may establish a wireless connection 162 with the wireless access point 160, such as over a Wi-Fi connection. Wireless access point 160 may be configured to connect to the internet 164 or another network through a wired connection 166.

Although not shown, the second mobile communication device 120 may similarly be configured to connect with the peripheral device 150 and/or the wireless access point 160 via a wireless link.

In some embodiments, each of the mobile communication devices 110, 120 may communicate with the first and second base stations 130, 140 using different RATs. For example, the first mobile communication device 110 may have a first RAT (e.g., CDMA RAT) for communicating with the first mobile network 102 (e.g., CDMA network) via the first base station 130 and may have a second RAT (e.g., GSM RAT) for communicating with the second mobile network 104 (e.g., GSM mobile network) via the second base station 140. In some embodiments, the RATs on the mobile communication devices 110, 120 may operate on behalf of the same subscription (e.g., in SRLTE communication devices) or on behalf of different subscriptions (e.g., in DSDS or DSDA communication devices).

Fig. 2 is a functional block diagram of a mobile communication device 200 suitable for implementing various embodiments. According to various embodiments, the mobile communication device 200 may be similar to one or more of the mobile communication devices 110, 120 as described with reference to fig. 1. Referring to fig. 1-2, a mobile communication device 200 may include a first SIM interface 202a, and the first SIM interface 202a may receive a first identity module SIM-1204 a associated with a first subscription. The mobile communication device 200 can also include a second SIM interface 202b, and the second SIM interface 202b can receive a second identity module SIM-2204 b associated with the second subscription.

The SIM in various embodiments may be a Universal Integrated Circuit Card (UICC) configured with SIM and/or USIM applications to enable access to GSM and/or UMTS networks. The UICC may also provide storage for phone books and other applications. Additionally, in a CDMA network, the SIM may be a UICC removable subscriber identity module (R-UIM) or a CDMA Subscriber Identity Module (CSIM) on the card. The SIM card may have a CPU, ROM, RAM, EEPROM, and I/O circuitry. An Integrated Circuit Card Identification (ICCID) SIM serial number may be printed on the SIM card for identification. However, the SIM may be implemented within a portion of the memory of the mobile communication device and, thus, need not be a separate or removable circuit, chip or card.

The SIM used in various embodiments may contain user account information, International Mobile Subscriber Identity (IMSI), SIM Application Toolkit (SAT) command set, and other network setup information, as well as provide storage space for a phonebook database for the user's contacts. As part of the network provisioning information, the SIM may store a home identifier (e.g., a system identification number (SID)/network identification Number (NID) pair, a local plmn (hplmn) code, etc.) to indicate the SIM card network operator provider. An Integrated Circuit Card Identification (ICCID) SIM serial number is printed on the SIM card for identification.

The mobile communication device 200 can include at least one controller, such as a general purpose processor 206, which can be coupled to a coder/decoder (CODEC) 208. The CODEC 208 may in turn be coupled to a speaker 210 and a microphone 212. The general purpose processor 206 may also be coupled to at least one memory 214. The memory 214 may be a non-transitory computer-readable storage medium that stores processor-executable instructions. For example, the instructions may include routing communication data associated with the first or second subscription through the corresponding baseband RF resource chain.

The memory 214 may store an Operating System (OS) as well as user application software and executable instructions. The memory 214 may also store application data, such as an array data structure. In some embodiments, the memory 214 may also store one or more lookup tables (e.g., as described with reference to fig. 5A-5B) that include RGS values associated with each of a plurality of RATs in which the mobile communication device 200 operates, as well as other information such as subscription, base station, network/service provider, geographic location, temperature, time/timestamp, and/or other information associated with the RGS values of each RAT. For example, the lookup table stored in memory 214 may include information useful in determining a particular RGS value to be used for a RAT currently representing a particular subscription and/or communicating with a particular base station.

The general purpose processor 206 and the memory 214 may each be coupled to at least one baseband modem processor 216. Each SIM and/or RAT in the mobile communication device 200 (e.g., SIM-1204 a and SIM-2204 b) may be associated with a baseband-RF resource chain. The baseband-RF resource chain may include a baseband modem processor 216, which baseband modem processor 216 may perform baseband/modem functions for communicating with/for controlling a RAT, and may include one or more amplifiers and radio units, which are generally referred to herein as RF resources (e.g., RF resource 218a and optional RF resource 218 b). In some embodiments, the baseband-RF resource chain may share a baseband modem processor 216 (i.e., a single device for performing baseband/modem functions for all RATs on the wireless device). In other embodiments, each baseband-RF resource chain may include a physically or logically separate baseband processor (e.g., BB1, BB 2).

The RF resources 218a, 218b may each be a transceiver associated with one or more RATs and may perform transmit/receive functions for the wireless device on behalf of its respective RAT. For example, a first RAT (e.g., a GSM RAT) may be associated with RF resource 218a and a second RAT (e.g., a CDMA or wcdma RAT) may be associated with RF resource 218 b. In another example, both the first RAT and the second RAT may be associated with RF resource 218 a. The RF resources 218a, 218b may include separate transmit and receive circuits, or may include transceivers that combine transmitter and receiver functionality. Each of the RF resources 218a, 218b may be coupled to a wireless antenna (e.g., a first wireless antenna 220a or an optional second wireless antenna 220 b). The RF resources 218a, 218b may also be coupled to the baseband modem processor 216.

In some embodiments, the general purpose processor 206, memory 214, baseband processor 216, and RF resources 218a, 218b may be included in the mobile communication device 200 as a system on a chip. In some embodiments, the first and second SIMs 204a, 204b and their corresponding interfaces 202a, 202b may be external to the system-on-chip. In addition, various input and output devices may be coupled to components on the system-on-chip, such as interfaces or controllers. Example user input components suitable for use in the mobile communication device 200 may include, but are not limited to, a keypad 224, a touch screen display 226, and a microphone 212.

In some embodiments, the keypad 224, the touch screen display 226, the microphone 212, or a combination thereof may perform the function of receiving a request to initiate an outgoing call. For example, the touch screen display 226 may receive a selection of a contact from a contact list or receive a telephone number. In another example, one or both of the touch screen display 226 and the microphone 212 may perform the function of receiving a request to initiate an outgoing call. For example, the touch screen display 226 may receive a selection of a contact from a contact list or receive a telephone number. As another example, the request to initiate an outgoing call may be in the form of a voice command received via microphone 212. Interfaces may be provided between various software modules and functions in the mobile communication device 200 to enable communication therebetween, as is known in the art.

When working in cooperation, the two SIMs 204a, 204b, baseband processors BB1, BB2, RF resources 218a, 218b, and wireless antennas 220a, 220b may constitute two or more RATs. For example, the SIM, baseband processor, and RF resources may be configured to support two different RATs. Multiple RATs may be supported at the mobile communication device 200 by adding more SIM cards, SIM interfaces, RF resources, and/or antennas for connecting to additional mobile networks.

The mobile communication device 200 can include a crystal oscillator manager 230 configured to manage RGS values associated with each of a plurality of RATs on the mobile communication device 200, such as by storing the RGS values in a lookup table in the memory 214, as described. The crystal oscillator manager 230 may be implemented as a software module implemented on the general purpose processor 206 or the baseband modem processor 216, as a separate hardware component, or as a combination of hardware and software. The crystal oscillator manager 230 may interact with other components on the mobile communication device 200, such as the sleep controller 232, to enable each RAT of the multiple RATs to perform various operations, such as sleep operations, acquisition and reacquisition operations, handover operations, and/or inter-RAT measurements, as described (e.g., with reference to fig. 4-12). For example, crystal oscillator manager 230 may receive temperature measurements of mobile communication device 200 (and/or temperature measurements of the crystal oscillator (not shown)) from temperature sensor 236, and crystal oscillator manager 230 may utilize these temperature measurements to adjust one or more RGS values.

In some embodiments, the sleep controller 232 may be configured to determine periods during which the RAT may perform sleep and/or idle mode operations in response to receiving sleep notifications from the RAT. Specifically, the sleep controller 232 may obtain an RGS value associated with the notifying RAT and may calculate a sleep procedure/sleep duration for the RAT based on the retrieved RGS value.

In some embodiments, the sleep controller 232 may convert the RGS value to the time domain and/or may adjust the RGS value in response to temperature changes on the mobile communication device 200 that may have occurred since the RGS value was initially stored. The sleep controller 232 may be implemented as a software module implemented on the general purpose processor 206 or the baseband modem processor 216 or the crystal oscillator manager 230, as a separate hardware component, or as a combination of hardware and software.

In some embodiments, the mobile communication device 200 can include a Global Positioning System (GPS) module 234 (e.g., a GPS receiver) configured to provide location information to the general purpose processor 206. As described, location information such as provided by the GPS module 234 may be used by the general purpose processor 206 to select RGS values stored in memory and/or to determine when stored RGS values are unreliable. In such embodiments, the GPS module 234 may obtain RGS values for the global positioning system associated with the GPS module 234.

Fig. 3 is a signaling and call flow diagram illustrating example communications between various components on a conventional mobile communication device in which various components rely on only one system RGS value to enable multiple RATs to perform sleep, acquisition, and/or reacquisition operations. Referring to fig. 1-3, a conventional communication device includes a first RAT302 (labeled "RAT 1" in fig. 3), a second RAT 308 (labeled "RAT 2" in fig. 3), a sleep controller 304 (e.g., sleep controller 232 of fig. 2), and a crystal oscillator manager 306 (e.g., crystal oscillator manager 230 of fig. 2).

In the example shown in fig. 3, the first RAT302 must obtain the RGS value in order to perform network acquisition because the first RAT302 must use the RGS value in order to get fromThe actual frequency of a nearby base station is determined for the purpose of acquiring service. Thus, upon power up (not shown), the first RAT302 sends a request to the crystal oscillator manager 306 and receives an RGS value (i.e., RGS) from the crystal oscillator manager 306 via signaling 310₀Value).

In conventional mobile communication devices, the crystal oscillator manager 306 stores only one RGS value (i.e., a system RGS value), such as the most recent or latest RGS value received from any of the plurality of RATs operating on the mobile communication device. Thus, in response to receiving a request for an RGS value from the first RAT302, the crystal oscillator manager sends a system RGS value to the first RAT 302.

Upon acquisition of RGS from the crystal oscillator manager 306₀In value, the first RAT302 uses RGS₀The value performs a fetch operation 312. In the example shown in diagram 300, RGS₀The value may be associated with the first RAT302 to enable the first RAT302 to successfully perform the acquisition operation 312.

During a procedure (not shown) of its communication with its base station, the first RAT302 determines and/or receives updated RGS values (i.e., RGS) from its base station₁Value). The first RAT302 reports the RGS via signaling 314₁The value is given to the crystal oscillator manager 306, and in response, the crystal oscillator manager 306 uses the RGS in operation 315₁Value covering RGS₀The value is obtained.

At a later time, the crystal oscillator manager 306 receives another updated RGS value (i.e., RGS) from the second RAT 308 via signaling 316₂Value). RGS₂The value may be specific to the base station of the second RAT 308 (i.e., the particular frequency error of the base station) and thus may be suitable for use only with the second RAT 308 and not with any other RAT on a legacy mobile communication device (e.g., the first RAT 302). However, according to conventional implementations, the crystal oscillator manager 306 only maintains the most recent RGS value and thus uses the RGS received from the second RAT 308 in operation 317₂The value covers the RGS received from the first RAT302₁The value is obtained.

Sometimes, multiple RATs on a mobile communication device may need to enter sleep/idle mode, e.g., to save power when those RATs are not performing receive or transmit operations. To enter the sleep/idle mode, the RAT may notify the sleep controller.

For example, in the example shown in diagram 300, the first RAT302 sends a sleep notification to the sleep controller 304 via signaling 318 shortly before entering the sleep or idle mode in operation 324. In response to receiving the sleep notification, sleep controller 304 sends a request for an RGS value to crystal oscillator manager 306 via signaling 320 and receives a stored system RGS value (i.e., RGS) from crystal oscillator manager 306₂Value).

In operation 322, the sleep controller 304 uses the RGS₂A value to determine a period of time (i.e., a sleep duration) that the first RAT302 should remain asleep/idle before being reactivated. Sleep controller 304 may do this by passing the RGS₂The frequency information in the value is converted to time domain/timing information that may be used to determine how long the first RAT302 should stay asleep before the first RAT302 must re-acquire service from its base station. Thus, after the first RAT302 enters the sleep mode in operation 324, the sleep controller 304 sends a wake-up signal 326 to the first RAT302 at the end of the sleep duration as calculated in operation 322.

Since the sleep duration calculated in operation 322 is based on the RGS received from the second RAT 308₂Of a value other than based on an RGS value (e.g., RGS) associated with the first RAT302₁Value), the sleep duration may be incorrect for the first RAT. In other words, the sleep duration may not accurately reflect timing and/or frequency information for the network and/or base station of the first RAT302 because of RGS₂The value indicates frequency error information for the base station/network of the second RAT 308. Thus, the sleep controller 304 may send the wake-up signal 326 to the first RAT302 at times other than the expected or expected wake-up time for the first RAT302, potentially causing the first RAT302 to experience pilot timing errors or slew errors.

In addition, in order to perform a reacquisition operation,the first RAT302 requests and receives RGS from the crystal oscillator manager 306 via signaling 328₂The value is obtained. As described, RGS₂The value may only be available for operations related to the second RAT 308 because RGS₂The value reflects a frequency error of a base station of the second RAT 308, but not a base station associated with the first RAT 302. Thus, when the first RAT302 attempts to use RGS₂The first RAT302 may not be able to reacquire service when the reacquisition operations 330 are performed (i.e., block 332).

As seen in the example illustrated in diagram 300, conventional approaches store only one system RGS value to support sleep, acquisition, and reacquisition operations for multiple RATs operating at the mobile communication device, which may cause significant problems with sleep timing and acquisition/reacquisition operations when the system RGS value is received from one RAT (e.g., second RAT 308) for use by or on behalf of another RAT (e.g., first RAT 302). As a result, the overall performance of the mobile communication device may be affected.

Various embodiments address limitations of conventional mobile communication devices, such as those described with reference to fig. 3, by configuring a crystal oscillator manager to store separate RGS values for each of a plurality of RATs on the mobile communication device.

Fig. 4 is a signaling and call flow diagram 400 illustrating communication between various components on a mobile communication device (e.g., mobile communication device 200 of fig. 2), in accordance with various embodiments. Referring to fig. 1-4, a mobile communication device may include a first RAT302, a sleep controller 304, a crystal oscillator manager 306, and a second RAT 308.

In the illustrated example, the crystal oscillator manager 306 may previously stored an RGS value (i.e., RGS) associated with the first RAT302₀Value), which means that the first RAT302 may have previously reported RGS₀The value is given to the crystal oscillator manager 306 indicating the frequency error of the base station/network of the first RAT 302.

Upon power up or reactivation (not shown), the first RAT302 may need to obtain the latest RGS value from the crystal oscillator manager 306 in order to determine the actual frequency needed to communicate with nearby base stations associated with the first RAT302 or recently used by the first RAT 302. Accordingly, the first RAT302 may send a request for the latest RGS value to the crystal oscillator manager 306 via signaling 402. In some embodiments, the request may include information that may enable the crystal oscillator manager 306 to identify the requesting RAT.

In response to receiving the request from the first RAT302, the crystal oscillator manager 306 may identify the first RAT302 as being associated with the request and may return an RGS value (i.e., RGS) associated with the first RAT via signaling 402₀Value). In some embodiments, the crystal oscillator manager 306 may obtain the RGS from a data table stored in memory by performing a lookup operation in the data table (e.g., as described with reference to fig. 5A-5B) to find an RGS value associated with the first RAT302 based at least on the identity of the first RAT302₀A value (e.g., memory 214).

In response to receiving the RGS₀Value, RGS available to the first RAT302₀The values perform a get operation 312, as described. Because of RGS₀The value is associated with the first RAT302, so the first RAT302 may successfully perform the acquisition operation 312 because the first RAT302 may use RGS₀To determine the frequency needed to communicate with nearby base stations.

At a later time, the first RAT302 (or another component on the mobile communication device) may receive the RGS by receiving the RGS directly from the base station/network of the first RAT302₁The updated RGS value (i.e., RGS) is obtained either by determining the frequency error of the current base station of the first RAT302₁Value). For example, the first RAT302 may compare the frequency of communications received from its base station to the expected frequency of the base station and may determine RGS based on the difference₁The value is obtained. In some embodiments, RGS₁The value may reflect a current operating frequency of the crystal oscillator based on a current temperature of the mobile communication device.

The first RAT302 may send the updated RGS value (i.e., RGS) via signaling 403₁Value) to the crystal oscillator manager 306 and also sends information identifying the first RAT 302. As a soundAlternatively, the crystal oscillator manager 306 may update the current RGS value (i.e., RGS) associated with the first RAT302, e.g., by updating a look-up table₀Value) to RGS in operation 404₁The value is associated with the first RAT 302.

In some embodiments, the first RAT302 may send additional information to the crystal oscillator manager 306-via signaling 403-that further describes the updated RGS value or the context (i.e., one or more "attributes" related to the updated RGS value) at the time the updated RGS value is obtained. In such embodiments, crystal oscillator manager 306 may associate this accessory information with the updated RGS value (e.g., as described with reference to fig. 5B). For example, the first RAT302 may send a signal indicating RGS₁The value is related to the second subscription and/or base station having a particular ID number because the first RAT302 obtained the RGS at the first RAT302₁The time at which the value is representing the second subscription communicating with that particular base station.

The second RAT 308 may also obtain updated RGS values (i.e., RGS) as described with reference to the first RAT302₂Value) and may report RGS via signaling 405₂The value is given to the crystal oscillator manager 306. In response, the crystal oscillator manager 306 may update the RGS value associated with the second RAT 308 in operation 406, such as by updating the RGS value in the lookup table as described with reference to operation 404₂The value is associated with the second RAT 308.

In the illustrated example, the first RAT302 may send the sleep notification 318 to the sleep controller 304 before beginning the sleep/idle mode operation in operation 324 (e.g., as described with reference to fig. 3). In response to receiving the sleep notification 318, the sleep controller 304 may obtain the RGS value associated with the first RAT302 from the crystal oscillator manager 306 via signaling 407. For example, the sleep controller 304 may send a current RGS value (i.e., RGS) for the RGS associated with the first RAT302₁Value) to crystal oscillator manager 306. In this example, the crystal oscillator manager 306 may obtain for the first RAT30 by performing a lookup operation based on the identification of the first RAT302 in the data table of RGS valuesRGS of 2₁Value, and the crystal oscillator manager 306 may return the RGS via signaling 407₁To the sleep controller 304.

In operation 408, the sleep controller 304 may be based on the RGS received from the crystal oscillator manager 306 via signaling 407₁The value determines a sleep duration for the first RAT 302. The sleep controller 304 may associate a current RGS associated with the first RAT302₁The value is converted from the frequency domain to the time domain and this time domain value may be utilized to determine a period of time that the first RAT302 should remain in the sleep/idle mode before being activated. Furthermore, due to the current RGS₁The value is associated with the first RAT302, so the sleep controller 304 can accurately determine the sleep duration of the first RAT302, which causes the first RAT302 to avoid timing and slew errors with respect to the wakeup. Upon expiration of the sleep duration, the sleep controller 304 may send a wake-up signal 412 to the first RAT302 to cause the first RAT302 to resume normal operation.

When normal operation resumes, the first RAT302 may send identification information and a request for RGS values to the crystal oscillator manager 306 via signaling 414 in anticipation of performing a reacquisition operation. As described above, the crystal oscillator manager 306 may retrieve an RGS value (i.e., RGS) associated with the first RAT302₁Value) and may send RGS to the first RAT302 via signaling 414₁Value, and the first RAT302 may utilize RGS₁Value to successfully perform the reacquisition operation 416 because of RGS₁The value is associated with the first RAT302 and not with another RAT.

Fig. 5A-5B are data tables 500, 510 that illustrate various associations of RGS values that may be used to ensure that the RGS values used for sleep, acquisition, reacquisition, handover, and/or inter-RAT measurement operations for a RAT are actually associated with that RAT, or are useful in successfully performing these operations. In some embodiments, the data tables 500, 510 may be referenced by a device processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, the sleep controller 232, or another controller/processor of fig. 2) on a mobile communication device (e.g., the mobile communication device 200).

Referring to fig. 1, 2 and 4-5B, the data table 500 may be a relatively simple look-up table that the device processor may use to maintain a direct association between each RAT on the mobile communication device and its most recent RGS value (or values). For example, the device processor may receive an RGS value (i.e., RGS) from the first RAT₁Value) and may store the RGS value and its association with the first RAT in the data table 500. Likewise, the device processor may receive another RGS value (i.e., RGS) from the second RAT₂A value) and may store the RGS value in the data table 500 and store an association between the RGS value and the second RAT. Thus, rather than maintaining only one system RGS value for use by each RAT on the mobile communication device as is currently practiced in legacy devices, in various embodiments, the device processor may maintain at least one RGS value for each RAT. As a result, the device processor may ensure that various components (e.g., RAT, GPS unit/module, and/or sleep controller) on the mobile communication device are able to use the most relevant RGS values when performing various operations. For example, the device processor may send RGS₁The first RAT is given access to enable the first RAT to perform reacquisition operations (e.g., as described with reference to fig. 4).

In some embodiments, the device processor may store and maintain additional information related to the RGS value, as shown in data table 510. As noted, the contextual associations associated with RGS values may sometimes be collectively referred to as "attributes" of the RGS value.

In such embodiments, the device processor may store and associate RGS values with a particular RAT, as described with reference to data table 500. In addition, the device processor may associate RGS values with various other types of information/attributes that may be useful to the device processor in selecting the most appropriate RGS value given the current environment of the mobile communication device. For example, the identity of the RAT associated with the RGS value may describe, at least in part, the environment in which the RGS value is obtained. In such an example, the device processor may use the RGS value for a RAT based on its association with the RGS value.

In data table 510, the device processor may assign a first RGS value (i.e., RGS)₁Value) is associated with the first RAT, and is also associated with a first subscription (i.e., subscription) associated with the first RAT when the first RGS value is acquired₁) And (4) associating. The device processor may also associate the first RGS value with a base station (i.e., base station ID 123) and/or a serving network (i.e., serving network ID GSM) associated with the first RAT when the first RGS value is acquired. In some embodiments, the device processor may also associate the first RGS value with the temperature of the mobile communication device (and/or the temperature of the crystal oscillator) at the time the first RGS value was acquired (i.e., a mild X °).

In some embodiments, the device processor may determine a time/timestamp when the RGS value is received/reported from the RAT and associate the time with the RGS value. For example, the data table 510 may also include an entry for the first RGS value corresponding to the time when the RGS value was received (e.g., timestamp a). In such embodiments, at a later time, the device processor may utilize the time associated with the RGS value to select an RGS value to use. For example, because the RGS value may indicate a snapshot of the environment at a particular time, the device processor may attempt to get the most recently received or "freshest" RGS value, which may have the best chance of reflecting the current condition of the mobile communication device.

Also, in some embodiments, the device processor may associate the RGS value with GPS coordinates of the mobile communication device when the RGS value is received from/reported by the RAT. For example, the device processor may store the geographic location of the mobile communication device (e.g., location/GPS coordinates Q ° for the first RGS value) at the time the RGS value is received/stored. In such embodiments, the device processor may record RGS values for a particular geographic area that maintain particular network conditions or have particular frequency errors. Thus, if the requesting entity requests an RGS value (see, e.g., fig. 7A), the device processor may determine the current GPS coordinates of the mobile communication device and retrieve the RGS value with the associated GPS coordinate closest to the current GPS coordinates of the mobile communication device. The present embodiments may enable the mobile communication device to quickly receive a service by utilizing an RGS value associated with the mobile network in the current location.

Thus, by associating the RGS value with one or more attributes that may include the temperature, time, timestamp, geographic location, etc. of the RAT, subscription, base station, device, and/or crystal oscillator, the device processor is able to identify the most appropriate RGS value for a given situation based on the context information observed when the RGS was acquired (i.e., the stored attributes of the RGS value). For example, a RAT may communicate with two different service providers/networks representing two different subscriptions, and each network may have a different frequency error/RGS value. Thus, in such an example, the device processor may maintain separate entries in the data table for the RGS values associated with the RAT and the first subscription and also for separate RGS values associated with the RAT and the second subscription. Thus, the device processor may return one of the RGS values to the RAT based on the subscription to which the RAT is currently performing communication.

In some embodiments, the device processor may refer to various attributes of the RGS values stored in the data table 510 in order to adjust the RGS values to compensate for minor changes in the current conditions of the mobile communication device, mobile network, etc. For example, the device processor may use the temperature associated with the RGS value (i.e., the temperature of the mobile communication device at the time the RGS value is stored) as a reference point when determining the extent to which the RGS value must be adjusted for the RAT based on the current temperature of the mobile communication device and/or the crystal oscillator. In another example, because the performance of the crystal oscillator may vary over the lifetime, the device processor may use the time at which the RGS value was acquired/received to determine the extent to which it should be adjusted to account for the current lifetime of the crystal oscillator.

In some embodiments (see fig. 7B-7C), the device processor may compare one or more of the attributes of the RGS value to the current conditions to determine the likelihood that the RGS value is suitable/reliable when used to obtain service. In such embodiments, the device processor may determine or calculate a general "confidence" for each RGS value that will be used on the mobile communication device. In particular, the confidence value may indicate a likelihood that the RGS value is accurate for the current condition/network of the mobile communication device. In other words, the device processor may determine the confidence value associated with each RGS value by determining the difference between the stored characteristic associated with that RGS value and the current condition/characteristic of the mobile communication device.

For example, as described, the device processor may store information associated with the RGS value, which may include the current time, the device/crystal oscillator temperature, GPS coordinates, base station ID, subscription ID, and various other types of information when the RGS value is received/reported. Based on such stored information associated with the RGS value, the device processor may compare the stored information to the time currently being experienced by the mobile communication device, the device/crystal oscillator temperature, GPS coordinates, and the like. Based on this comparison, the mobile communication device may determine that the RGS value has a higher confidence in response to determining that there is a slight or no difference between the stored attribute associated with the RGS value and the current condition/characteristic of the mobile communication device. In contrast, the device processor may determine that the RGS value has a lower confidence when there is a significant difference between the stored attribute associated with the RGS value and the current characteristics of the mobile communication device. For example, when the temperature of the crystal oscillator at the time the RGS value is received is a few degrees above or below the current temperature of the crystal oscillator, the device processor may assign a lower confidence value to the RGS value due to potential frequency errors that may limit the usefulness of the value in obtaining service. In some embodiments, the device processor may utilize the confidence value of the RGS value to determine/adjust the length of time (i.e., the search window) for obtaining service. For example, the device processor may increase the duration of the search window to obtain service when the RGS value has a lower confidence and decrease the duration of the search window to obtain service when the RGS value has a higher confidence.

In some embodiments (e.g., fig. 7B-7C), the device processor may utilize the confidence value of the RGS value for various other purposes. For example, the device processor may select the RGS value to send to the requesting entity based on the RGS value having the highest confidence value to ensure that the requesting entity (e.g., RAT) can quickly acquire service.

Figure 6 illustrates a method 600 for associating RGS values with each of a plurality of RATs on a mobile communication device and storing the RGS values for later use by each of the plurality of RATs, in accordance with some embodiments. The method 600 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, a separate controller, and/or the like of a mobile communication device (e.g., the mobile communication device 200 of fig. 2).

Referring to fig. 1, 2, 6, and 4-6, after power up in block 602, the device processor may obtain RGS values for each of a plurality of RATs on the mobile communication device in block 604. In some embodiments, the device processor may receive RGS values from each RAT of the plurality of RATs over time, e.g., as a result of the RAT acquiring new or updated RGS values for its respective base station and network, and sending the acquired RGS values to the device processor, as described (e.g., with reference to fig. 4).

In block 606, the device processor may associate the obtained RGS value with each RAT in the plurality of RATs, such as by determining an identity of the RAT reporting the RGS value. In some embodiments of the operations performed in block 606, in response to receiving the RGS value from the RAT, the device processor may request, from the RAT, information that the device processor may use to identify the RAT in order to associate the RGS value with the RAT. In some embodiments, the RAT may include self-identifying information with RGS values reported to the device processor.

In optional block 608, the device processor may optionally associate the obtained RGS value with one or more attributes based on the time at which the RGS value was obtained in block 604. As described with reference to fig. 5A-5B, the device processor may identify context information/attributes regarding the RGS values based on various measurements, readings, etc., occurring at or near the time when the RGS values were obtained/received. For example, the attributes may include one or more of a temperature of the mobile communication device, a temperature of a crystal oscillator, a current subscription of a RAT associated with the RGS value, a base station ID used to receive/determine the RGS value, a time or timestamp at which the RGS value was received/obtained, a current location/GPS coordinates of the mobile communication device, and so forth.

In some embodiments, the RGS value may reflect the characteristics of the frequency error when the crystal oscillator of the mobile communication device is at a particular temperature. Because the operating frequency of the crystal oscillator may change based on the temperature of the mobile communication device, the device processor may determine the temperature of the mobile communication device when the RGS value is obtained and may associate the temperature with the RGS value, thereby enabling the device processor to make adjustments to the RGS value at a later time when the temperature of the mobile communication device has changed.

In block 610, the device processor may store the obtained RGS values and associations of RGS values, such as in a data table as described (e.g., with reference to fig. 5A-5B). Due to storing the RGS values and their associations/attributes, the device processor may quickly retrieve a particular RGS value associated with a particular RAT that would be most useful/appropriate for performing various operations related to the RAT. In particular, the device processor may utilize the stored attribute values associated with the RGS values to select the most appropriate/reliable RGS value for the requesting entity (e.g., RAT, sleep controller, GPS module, etc.) based on the current conditions of the mobile communication device and/or the network with which the mobile communication device is attempting to communicate. For example, in response to receiving a request for RGS values from a requesting entity (see fig. 7A-7C), the device processor may determine the current temperature of the crystal oscillator and the current GPS coordinates of the mobile communication device, and may retrieve the RGS value having a stored association that is closest to the currently observed conditions on the mobile communication device.

Figure 7A illustrates a method 700 for sending a stored RGS value associated with a RAT to a requesting entity, in accordance with some embodiments. The method 700 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, a separate controller, and/or the like in fig. 2) of a mobile communication device (e.g., the mobile communication device 200 of fig. 2). The operations of method 700 may implement various embodiments of the operations of method 600 (see fig. 6). Thus, referring to fig. 1, 2, and 4-7, the device processor may begin performing the operations of method 700 in response to storing the RGS value and its association in block 610 of method 600.

In block 702, the device processor may monitor for a request for an RGS value from a requesting entity on the mobile communication device. As described, the requesting entity may include: prepare a RAT for performing acquisition or reacquisition operations based on its associated RGS value, prepare a sleep controller (see fig. 10) for calculating a sleep duration for the RAT based on the RGS value associated with the RAT, and/or prepare a RAT for performing handover operations/inter-RAT measurements (see fig. 12-11). In some embodiments, the requesting entity may include a GPS receiver (e.g., GPS module 234) that may utilize RGS values when receiving signals from GPS satellites.

In determination block 704, the device processor may determine whether it has received a request for an RGS value from the requesting entity, and may continue to monitor for a request for an RGS value from the requesting entity in block 702 when no request for an RGS value is received (i.e., when determining block 704 is "no").

In response to determining that a request for an RGS value has been received from a requesting entity (i.e., determining that block 704 is yes), the device processor may identify a RAT associated with the request in block 706. In some embodiments, the device processor may determine an identification of a RAT associated with the request based on information contained in the request. For example, the request from the RAT may include self-identifying information, while the request from the sleep controller may include information indicating the RAT for which the sleep controller is attempting to calculate the sleep duration.

In some embodiments, the device processor may identify the RAT associated with the request based on the indirect information, such as by determining an operating state of each of a plurality of RATs on the mobile communication device. For example, the device processor may determine that a particular RAT has just been reactivated and may soon need to perform an acquisition/reacquisition operation, and may identify that RAT as likely to be request associated based on the determination.

In block 708, the device processor may retrieve the stored RGS value associated with the RAT identified in block 706, such as by performing a lookup in an associated data table (e.g., data table 500) related to the identified RAT. In some embodiments of the operations performed in blocks 706, 708, the device processor may identify a RAT associated with the request in addition to the current subscription of the RAT and/or at least one of a current temperature, geographic location of a base station, crystal oscillator, etc. The device processor may also retrieve at least one of a stored RGS associated with a RAT, and a current subscription of the RAT, a base station identification, etc., by performing a lookup in an associated extended data table (e.g., data table 510) that may indicate a particular RGS value.

In some embodiments of the operations performed in block 708, the device processor may retrieve the stored RGS value for use by the requesting entity such that the retrieved RGS value has a higher confidence value. In such embodiments, the device processor may compare the stored attributes associated with the stored RGS value (e.g., information associated with the RGS value at the time the RGS value was obtained) to currently observed/experienced/measured conditions on the mobile communication device and/or nearby mobile networks (see fig. 7B).

In optional block 710, the device processor may adjust the retrieved RGS value based on a change in at least one stored attribute associated with the RGS value retrieved in block 708. For example, when an RGS value may be particularly useful for a given temperature of the crystal oscillator, the device processor may reference the crystal temperature associated with the retrieved RGS value when the retrieved RGS value is stored (e.g., in optional block 608 of method 600), and calculate the difference between the current crystal temperature and the referenced crystal temperature. Based on the temperature difference, the device processor may adjust the RGS value to compensate for the effect of the temperature difference on the operating frequency of the crystal oscillator. Such adjustments to RGS may be particularly useful when the crystal oscillator is a non-temperature compensated crystal, since the operating frequency of these crystals may vary greatly depending on temperature.

The device processor may send the retrieved RGS value to the requesting entity in block 712, thereby ensuring that the requesting entity receives an RGS value that is highly correlated to and appropriate for the RAT identified in block 706. In some embodiments in which the device processor adjusts the RGS value in optional block 710, the device processor may send the adjusted RGS value to the requesting entity in block 712.

The device processor may repeat the above operations cyclically by again monitoring for requests for RGS values from the requesting entity in block 702.

In some embodiments, in addition to receiving RGS values from RATs, the device processor may also receive RGS values from a GPS module (e.g., GPS module 234) on the mobile communication device. In such embodiments, one or more RGS values may be associated with the GPS module and may be sent to the GPS module upon request, such as by performing operations similar to those described with reference to method 700. In some embodiments, the device processor may adjust the RGS value to reflect changes in time, temperature, geographic location, etc. prior to sending the RGS value to the GPS unit/module.

Figure 7B illustrates a method 720 for retrieving a stored RGS value associated with a RAT based on a confidence value of the stored RGS value, in accordance with some embodiments. The method 720 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, a separate controller, and/or the like of a mobile communication device (e.g., the mobile communication device 200 of fig. 2).

As described, the RGS value may reflect, among other things, a frequency error of the base station/network at the time when the RGS value was received/obtained according to a particular combination of environments and/or conditions observed at that time. For example, the RGS value may reflect the frequency error of a base station on a particular mobile network (e.g., GSM) at a particular geographic location and for a given crystal oscillator temperature. Thus, RGS values may be particularly useful in environments similar to or the same as those in which the RGS values were initially obtained/received. However, over time, the current conditions experienced/observed/measured on the mobile communication device may change, thereby affecting the likelihood or "confidence" that the RGS value will be appropriate/reliable for use with the changed conditions. In the above example, the device processor may determine that the RGS value has a lower confidence/likelihood that it is useful when the temperature of the crystal oscillator changes significantly.

As a result, in some embodiments, the device processor may account for changes in the condition/environment of the mobile communication device to determine the extent to which RGS values may be helpful or useful to the requesting entity in acquiring services, facilitating handover operations, performing sleep calculations, etc., based on the current condition/environment of the mobile communication device. The current environment of a mobile communication device.

Operations of method 720 may implement an embodiment of the operations in block 708 of method 700 (see fig. 7A). Thus, referring to fig. 1, 2, and 4-7B, the device processor may begin performing the operations of method 720 in response to identifying a RAT associated with the request for an RGS value in block 706 of method 700.

In block 721, the device processor may identify a set of RGS values associated with the RAT identified in block 706 of method 700, such as by referencing a data table (e.g., data tables 500, 510 in fig. 5A-5B) that stores, among other things, associations between RGS values and RATs, to identify any RGS values associated with the RAT identified in block 706 of method 700.

In determination block 722, the device processor may determine whether there is at least one stored RGS value in the set of RGS values associated with the identified RAT. In response to determining that there is at least one stored RGS value associated with the identified RAT (i.e., determining block 722 — yes), the device processor may determine a confidence value for each stored RGS value of the set of RGS values associated with the identified RAT in block 724. In some embodiments of the operations performed in block 724, the device processor may determine/observe/measure various current conditions/environments of the mobile communication device, such as the current time, crystal oscillator temperature, nearby base stations, accessible mobile networks, current geographic location/GPS coordinates, and compare the current conditions/environments to stored attributes associated with the RGS values that reflect the historical conditions/environments that existed when the RGS values were observed/received. The confidence value may be based on the comparison and may indicate the degree to which the current condition/environment matches or differs from the attribute associated with the RGS value. In other words, the confidence value may indicate how well/reliably the RGS value is used given a change in condition/environment as described, such that a lower confidence value may reflect a higher degree of change and a higher confidence may indicate a lower degree of change.

In some embodiments, the device processor may determine a confidence value for each attribute associated with the RGS value. For example, there may be an 80% confidence that an RGS value will be useful/reliable based on the current temperature of the crystal oscillator, while there may be a 20% confidence that an RGS value will be useful/reliable given the current geographic location of the mobile communication device.

In some embodiments, the confidence value may be a value that indicates the overall degree of change for all attributes associated with the RGS value considered together (i.e., a composite confidence value). For example, the confidence value may indicate: overall, the RGS value has a 90% confidence in usefulness/reliability given the current condition/environment of the mobile communication device. In such embodiments, the composite confidence value may be based on individual confidence values for conditions associated with RGS values given the current condition/environment.

In determination block 726, the device processor may determine whether the determined confidence value for at least one stored RGS value of the set of RGS values associated with the identified RAT satisfies a confidence threshold. In other words, the device processor may determine whether there are any RGS values associated with the identified RAT having a confidence value greater than or equal to the confidence threshold.

In some embodiments, the confidence threshold may be the minimum confidence value at which the RGS value may be expected to be reliable or useful in obtaining service. For example, RGS values with confidence values that do not meet a confidence threshold may be particularly useless in facilitating inter-RAT measurements, handover operations, acquisition/reacquisition of services, programming sleep times, and the like. For example, a RAT that uses RGS values associated with particularly old or outdated information may require a relatively long search window to acquire service because the RGS values may be inaccurate given the current environment/conditions of the mobile communication device.

In some embodiments performed in determination block 726, the confidence value may be an overall confidence threshold and the device processor may compare the confidence threshold to an overall or composite confidence value for the RGS value to determine if the RGS value may be expected to be very useful.

In some embodiments, the device processor may compare the confidence value for each attribute associated with the RGS value to a confidence threshold. In such embodiments, the device processor may determine that the RGS value satisfies the confidence threshold when each confidence value (or a certain percentage of confidence values) satisfies the confidence threshold.

In response to determining that the confidence of at least one stored RGS value of the set of RGS values associated with the identified RAT satisfies (e.g., is greater than or equal to) a confidence threshold (i.e., determining block 726 is yes), the device processor may retrieve, in block 728, the stored RGS value within the set of RGS values associated with the identified RAT having the highest confidence value. By retrieving the stored RGS value with the highest confidence value, the device processor may ensure that the most useful RGS value is provided to the requesting entity in block 712 of method 700, as described (see fig. 7A).

In response to determining that there are no stored RGS values associated with the identified RAT (i.e., determining block 722 no), or in response to determining that none of the stored RGS values associated with the identified RAT in the set of RGS values have a confidence value that satisfies the confidence threshold (i.e., determining block 726 no), the device processor may retrieve alternate stored RGS values that are not associated with the identified RAT in block 730. In other words, if there is no RGS value associated with the identified RAT, or if there is no RGS value associated with the identified RAT with a confidence value that satisfies the confidence threshold, then the device processor may attempt to find another RGS value associated with another RAT that may be useful to the requesting entity (see, e.g., fig. 7C).

Regardless of whether the RGS value associated with the identified RAT is retrieved in block 728 or an alternate stored RGS value associated with another RAT is retrieved in block 730, the device processor may optionally adjust the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS value in optional block 710 of method 700, as described. In some embodiments, by adjusting the retrieved RGS value, the device processor may increase the likelihood that the RGS value will be useful to the requesting entity (i.e., the confidence value of the RGS value).

Figure 7C illustrates a method 740 for retrieving a stored RGS value associated with a subscription of an identified RAT when there is no RGS value directly associated with the identified RAT, in accordance with some embodiments. The method 740 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, a separate controller, and/or the like of a mobile communication device (e.g., the mobile communication device 200 of fig. 2). Operations of method 740 may implement embodiments of operations of block 730 of method 720 (see fig. 7B). Referring to fig. 1, 2, and 4-7C, the device processor may begin performing operations of method 740 in response to determining that there are no stored RGS values associated with the identified RAT (determination block 722 — no). In some embodiments, the device processor may begin performing operations of method 740 in response to determining that there are no RGS values associated with the identified RAT that satisfy the confidence threshold (i.e., determination block 726 of "no").

In block 742, the device processor may attempt to identify the subscription associated with the RAT identified in block 706 of method 700, such as by performing a lookup operation in an associated data table (e.g., data tables 500, 510 of fig. 5A-5B) of RGS values. In some embodiments, in response to determining that there is no RGS value associated with the identified RAT (or no RGS value with a sufficient confidence value), the device processor may attempt to retrieve an RGS value associated with the same subscription associated with the identified RAT. In such embodiments, it may be that RGS values associated with the same subscription but different RATs may be useful for the requesting entity in performing acquisition/reacquisition services, inter-RAT measurements, handover operations, sleep scheduling, GPS signal reception, and the like. For example, RGS values from different RATs that support the same subscription as the subscription of the identified RAT may share similar associations and thus may be satisfactory RGS values, even though there may be no RGS value associated with the identified RAT or only a lower confidence RGS value associated with the identified RAT. Thus, in block 744, the device processor may identify a set of RGS values associated with the subscription identified in block 742.

In block 746, the device processor may determine a confidence value for each stored RGS value of the set of RGS values associated with the identified subscription, such as by performing operations similar to those described with reference to block 724 of method 720 (see fig. 7B). In other words, the device processor may determine how likely each RGS value within the group will be useful to the requesting entity, such as based on a comparison of stored attributes associated with each RGS value to a current condition/environment observed or measured on the mobile communication device, as described.

In determination block 748, the device processor may determine whether there are stored RGS values in the set of RGS values that satisfy a confidence threshold associated with the identified subscription, such as by performing operations similar to those described with reference to determination block 726 of method 720 (see fig. 7B). In response to determining that there is an RGS value in the set of RGS values associated with the identified subscription that satisfies the confidence threshold (i.e., determining that block 748 is "yes"), the device processor may retrieve the stored RGS value in the set of RGS values associated with the identified subscription that has the highest confidence value in the set at block 756, thereby ensuring that the RGS value sent to the requesting entity in block 712 of method 700 has the highest likelihood of being useful to the requesting entity.

In response to determining that there are no RGS values in the set of RGS values associated with the identified subscription that satisfy the confidence threshold (i.e., determination block 748 no), the device processor may determine in determination block 750 whether any stored RGS values are available on the mobile communication device. In other words, in response to determining that there are no RGS values in the set of RGS values associated with the identified subscription, the device processor may attempt to identify any other RGS values stored on the mobile communication device.

In response to determining that a stored RGS value is available (i.e., determining that block 750 is yes), the device processor may fetch the stored RGS value with the highest confidence in block 754. In some embodiments, if no RGS value associated with the identified subscription with the higher confidence value satisfies the confidence threshold, the device processor may select from any stored RGS values (i.e., which are associated or not associated with the identified subscription) to retrieve the stored RGS value with the highest confidence value available. For example, the device processor may retrieve RGS values that are not associated with the identified subscription (and/or the identified RAT), but are associated with conditions similar to those currently observed/measured on the mobile communication device.

In response to determining that no stored RGS value is available on the mobile communication device (i.e., determining that block 750 ═ no), the device processor may generate an RGS value approximation using a mathematical model in block 752. In some embodiments, the device processor may rely on a mathematical model that is used to predict the frequency error based on the current temperature of the crystal oscillator using known methods. The device processor may rely on a mathematical model, for example, when no stored RGS values are available on the mobile communication device).

In response to retrieving the stored RGS value in blocks 756 or 754, the device processor may adjust the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS in optional block 710 of method 700 (see fig. 7A), as described. Alternatively, in response to generating the RGS value approximation using the mathematical model in block 752, the device processor may send the approximated RGS value to the requesting entity in block 712 of method 700, as described.

Figure 8A illustrates a method 800 for associating an updated RGS value with a RAT and storing the updated RGS value for later use by or for the RAT, in accordance with some embodiments. Method 800 may be implemented with a processor (e.g., general processor 206, baseband modem processor 216, crystal oscillator manager 230, a separate controller, and/or the like of fig. 2) on a mobile communication device (e.g., mobile communication device 200 of fig. 2). Operations of method 800 may implement an embodiment of operations of method 600 (see fig. 6). Thus, referring to fig. 1, 2, and 4-8A, the device processor may begin performing the operations of method 800 in response to storing the RGS value and its association in block 610 of method 600.

In block 802, the device processor may monitor for a change in network conditions of the RAT related to the frequency error, such as by detecting when the RAT performs a reselection operation to camp on a different cell/base station that may have a different frequency error. In some embodiments of the operations of block 802, the device processor may monitor communications or signals (e.g., signaling 403, 405 in fig. 4) received directly from a particular RAT, indicating that the RAT has received or determined an updated RGS value.

In determination block 804, the device processor may determine whether there is a change in the network conditions of the RAT associated with the frequency error and may continue to monitor for a change in the network conditions of the RAT in block 802 as long as there is no change in the network conditions of the RAT associated with the frequency error (i.e., when determining block 804 to be "no").

In response to determining that there has been a change in network conditions for the RAT related to the frequency error (i.e., determining that block 804 is yes), the device processor may determine an updated RGS value for the RAT based on the current network conditions of the RAT in block 806. For example, the device processor may compare the frequency of communications received from a base station of a RAT to an expected frequency and, based on the comparison, may derive an updated RGS value that reflects the current frequency error of the base station. In some embodiments, the device processor may calculate the updated RGS value by determining frequency errors for the current base station of the RAT and adjusting these frequency errors based on the operating frequency of the crystal oscillator at the current temperature of the mobile communication device.

In block 808, the device processor may associate the updated RGS value with the RAT, such as by replacing a previous RGS value associated with the RAT with the updated RGS value in a data table associated with RGS values. In some embodiments, for example, the device processor may also associate the updated RGS value with the current subscription of the RAT and with the current base station of the RAT. Further, in optional block 810, the device processor may associate the updated RGS value with the at least one current attribute based on the time at which the updated RGS value was determined in block 806. For example, the device processor may determine the current temperature of the mobile communication device and may associate the temperature with the updated RGS value to enable adjustment of the updated RGS value at a later time when the temperature of the device has changed and has affected the operating frequency of the crystal oscillator.

In block 812, the device processor may store the updated RGS value and its association with the RAT (and optionally its association with the at least one current attribute), such as by storing the updated RGS value in memory and updating the association of the updated RGS value maintained in a data table maintained in memory (e.g., memory 214).

The device processor may repeat the above operations cyclically by again monitoring for changes in network conditions of the RAT associated with the frequency error in block 802.

Figure 8B illustrates a method 820 for modifying a stored RGS value based on an updated RGS value determined from current network conditions, in accordance with some embodiments. The method 820 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, a separate controller, and/or the like of a mobile communication device (e.g., the mobile communication device 200 of fig. 2).

In some embodiments (e.g., as described with reference to fig. 8A), the device processor may receive/determine an updated RGS value for a RAT based on current network conditions. However, the updated RGS value may occasionally reflect spurious or inaccurate information that may not be useful for compensating for the frequency error of the base station. For example, the base station may instantaneously report inaccurate frequency error measurements due to processing errors in the mobile network. To prevent the possibility that the updated RGS values include inaccurate or spurious information, the device processor may perform the operations of method 820 to modify existing stored RGS values with updated RGS values, rather than automatically replacing these existing RGS values (e.g., as described with reference to fig. 8A).

Referring to fig. 1, 2, and 4-8B, the operations of method 820 may implement an embodiment of the operations of method 600 (see fig. 6). Thus, the device processor may begin performing the operations of method 800 in response to storing the RGS value and its association in block 610 of method 600.

The device processor may perform the same or similar operations in blocks 802-806 as described with reference to blocks 802-806 of method 800 (see fig. 8A). In other words, the device processor may monitor for a change in network conditions of the RAT related to the frequency error in block 802, determine whether there is a change in network conditions of the RAT related to the frequency error in block 804, and in response to determining that there is a change (i.e., determining that block 804 is "yes"), the device processor may determine an updated RGS value for the RAT based on the current network conditions in block 806.

In block 822, the device processor may retrieve the stored RGS value associated with the RAT, such as by accessing an associated data table and performing a lookup operation in the data table to identify the RGS value associated with the RAT.

In block 824, the device processor may modify the stored RGS value based on the updated value of RGS. In some embodiments of the operations performed in block 824, the device processor may adjust the value of the retrieved RGS, such as by replacing the retrieved RGS value with an average of the retrieved RGS and the updated RGS value, which thereby limits the likelihood that the usefulness of the RGS value will be greatly reduced with respect to the updated RGS value (i.e., due to inaccuracies introduced by the updated RGS value).

In some embodiments, the device processor may maintain one or more previous versions of the RGS value, including the most recently received/determined value of RGS. In response to determining the updated RGS value in block 806, the device processor may retrieve one or more previous versions of the RGS value and may calculate a new RGS value for use by one or more components on the mobile communication device based on the previously stored version of the RGS value and the updated RGS value. For example, the new RGS value may be the updated RGS and the average of four previously stored versions of the RGS value. By utilizing multiple previously stored versions of the RGS value, the device processor may further reduce the likelihood that the usefulness of the RGS version will be greatly impaired with respect to the updated RGS version.

In optional block 826, the device processor may identify at least one attribute associated with the updated RGS value based on the time at which the updated RGS value was determined in block 806. As described, the device processor may identify the at least one attribute based on various factors or circumstances currently experienced on the mobile communication device, such as a temperature, a geographic location, an activation subscription, a base station, etc., of a device/crystal oscillator associated with the RAT when the updated RGS value is determined.

In optional block 828, the device processor may modify at least one attribute value associated with the modified RGS value based on the at least one attribute associated with the updated RGS value identified in optional block 826. In some embodiments, modifying the association of the stored RGS value may include modifying an entry in an associated data table, such as by replacing a device temperature value associated with the stored RGS value with an average device temperature of a previously stored device temperature value and a device temperature value associated with the updated RGS value. By modifying (rather than replacing/overwriting) the conditions, characteristics, environment, etc. associated with the stored RGS value, the device processor can ensure that spurious information related to the updated RGS value does not substantially affect the usefulness of the stored RGS value.

The device processor may cyclically repeat the above operations of method 820 by again monitoring for changes in network conditions of the RAT associated with the frequency error in block 802.

Fig. 9 illustrates a method 900 for configuring a RAT to sleep for a period of time based on an RGS value associated with the RAT, in accordance with some embodiments. The method 900 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, a separate controller, and/or the like of a mobile communication device (e.g., the mobile communication device 200 of fig. 2). Referring to fig. 1, 2, and 4-9, operations of method 900 may implement embodiments of operations of method 600 (see fig. 6). Thus, the device processor may begin performing operations of method 900 in response to storing the RGS value and its association in block 610 of method 600.

In block 902, the device processor may monitor for sleep notifications from the RAT. In some embodiments, the sleep notification may be a signal or other indication sent from a RAT to indicate that the RAT is about to enter a sleep or idle mode. For example, to temporarily interrupt access by a first RAT to shared RF resources on a DSDS communication device to support a second RAT, the first RAT may send a notification to a device processor indicating that the first RAT may be entering a sleep/idle mode when the second RAT accesses the shared RF resources. In some embodiments, instead of receiving sleep notifications directly from the RAT, the device processor may determine when the RAT may need to perform sleep/idle mode operations, such as by monitoring execution scheduling of the RAT and/or by determining when circumstances occurring on the mobile communication device indicate that the RAT may need to perform sleep operations.

In determination block 904, the device processor may determine whether a sleep notification has been received from a RAT, and may continue to monitor for sleep notifications from a RAT in block 902 as long as no sleep notifications have been received from a RAT (i.e., when determining block 904 — no).

In response to determining that a sleep notification has been received from a RAT (i.e., determining that block 904 is yes), the device processor may retrieve an RGS value associated with the notified RAT in block 906. In some embodiments, the device processor may identify the notification RAT based on the request and/or based on indirect information received from other components on the mobile communication device identifying the notification RAT.

In optional block 710, the device processor may adjust the received RGS value based on a change in at least one stored attribute associated with the retrieved RGS value by performing operations similar to those described in optional block 710 of method 700. For example, the device processor may adjust the received RGS value based on a temperature change of the mobile communication device to compensate for the effect of the temperature change on the operating frequency of the crystal oscillator.

In block 910, the device processor may determine a period based on the sleep notification and the received RGS value. In some embodiments where operations are performed in block 910, the device processor may convert the RGS value obtained in block 906 (and optionally adjusted in block 908) to a time domain value and may determine a sleep duration for informing the RAT based on the time domain value. In some embodiments, the device processor may configure the notifying RAT to sleep for the period of time determined in block 910. In some embodiments, instead of configuring the notifying RAT to sleep for the determined period of time, the notifying RAT may initiate sleep operations on its own as part of its normal operation without specific instructions or assistance from the device processor.

In block 912, the device processor may configure the RAT to wake up upon expiration of the determined period of time, such as by counting down from a time when the RAT is notified to begin sleep operation until the period of time determined in block 910 has elapsed.

The device processor may repeat the above operations of method 900 cyclically by again monitoring for sleep notifications from the RAT in block 902.

Fig. 10 illustrates a method 1000 for configuring a RAT to perform an acquisition or reacquisition operation by utilizing an RGS value associated with the RAT, in accordance with some embodiments. The method 1000 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, a separate controller, and/or the like of a mobile communication device (e.g., the mobile communication device 200 of fig. 2). Referring to fig. 1, 2, and 4-10, operations of method 1000 may implement embodiments of operations of method 600 (see fig. 6). Thus, the device processor may begin performing operations of method 1000 in response to storing the RGS value and its association in block 610 of method 600.

In block 1002, the device processor may monitor the RAT about to perform network acquisition or reacquisition. In some embodiments, the device processor may monitor for a signal indicating that a RAT was recently activated, indicating that the RAT may soon need to perform an acquisition operation to establish service with the base station, or monitor for a signal indicating that a RAT was recently activated from a sleep or idle mode, indicating that the RAT may need to perform a reacquisition operation to reestablish service with the base station that was lost during the sleep/idle mode.

In determination block 1004, the device processor may determine that a RAT is about to perform a network acquisition or reacquisition operation, and may continue monitoring the RAT in block 1002 for the network acquisition or reacquisition operation as long as the RAT is not about to perform the network acquisition or reacquisition operation (i.e., determination block 1004 — no).

In response to determining that a RAT is about to perform a network acquisition or reacquisition operation (e.g., determining block 1004 — yes), the device processor may obtain a stored RGS value associated with the RAT about to perform the network acquisition or reacquisition operation in block 1006. As described, the device processor may perform a lookup in an associated data table (e.g., data tables 500, 510 described with reference to fig. 5A-5B) stored in memory to identify an RGS value associated with the RAT on which the acquisition/reacquisition operations are to be performed, and the device processor may retrieve the RGS value from memory.

In optional block 710, the device processor may adjust the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS value, such as by performing operations similar to those described in optional block 710 of method 700 (see fig. 7). For example, the device processor may adjust the RGS value retrieved in block 1006 to compensate for any changes in the temperature of the mobile communication device that may have occurred since the RGS value was initially obtained (see, e.g., block 604 of method 600) and associated with the RAT.

In block 1010, the device processor may configure the RAT to perform network acquisition or reacquisition operations based on the RGS value obtained in block 1006 (and optionally adjusted in block 1008). In some embodiments, the device processor may utilize the obtained RGS values to determine the frequencies needed for the RAT to communicate with and receive service from the nearby base station.

The device processor may again monitor for sleep notifications from the RAT in block 1002, cyclically repeating the above operations of method 1000.

Fig. 11 illustrates a method 1100 for configuring a RAT to perform a handover operation to an identified base station by utilizing an RGS value associated with the identified base station, in accordance with some embodiments. The method 1100 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, a separate controller, and/or the like of a mobile communication device (e.g., the mobile communication device 200 of fig. 2). Referring to fig. 1, 2, and 4-11, operations of method 1100 may implement embodiments of operations of method 600 (see fig. 6). Thus, the device processor may begin performing the operations of method 1100 in response to storing the RGS value and its association in block 610 of method 600.

In block 1102, the device processor may monitor for a handover notification from a RAT. In some embodiments, the device processor may monitor for a signal indicating that a RAT is or is about to perform a handover operation from a first base station to a second base station (e.g., from the first base station 130 to the second base station 140 of fig. 1). In some embodiments, the device processor may additionally or alternatively monitor for signals or conditions that may indicate a likelihood of performing a handover operation with respect to a RAT, such as a lower received signal strength or a poor quality of service from the first base station.

In determination block 1104, the device processor may determine whether a notification from a RAT has been received and continue to monitor for a handover notification from a RAT in block 1102 as long as the handover notification is not received from a RAT (i.e., determination block 1104 is no).

In response to determining that a handover notification is received from a RAT (i.e., determination block 1104 — yes), the device processor may identify a base station associated with the handover operation in block 1106. In some embodiments, the device processor may identify the base station directly from the handover notification, such as may occur when the RAT directly identifies the base station that it is about to or is about to acquire service. In some embodiments, the device processor may identify the base station based on a result of the inter-RAT measurement indicating that a particular base station using a particular RAT is able to provide better service.

In block 1108, the device processor may retrieve the stored RGS value associated with the base station identified in block 1106, such as by performing a lookup in an associated data table (e.g., data tables 500, 510 described with reference to fig. 5A-5B) stored in memory to identify the RGS value associated with the identified base station, and retrieving the RGS value associated with the base station from memory (e.g., memory 214).

In optional block 710, the device processor may adjust the retrieved RGS value based on a change in at least one stored attribute associated with the retrieved RGS value, such as by performing operations similar to those described in optional block 710 of method 700 (see fig. 7). In other words, the device processor may adjust the RGS value retrieved in block 1108 to compensate for any changes in the condition/environment of the mobile communication device that may have occurred since the RGS value was initially obtained and stored. For example, the device processor may adjust the retrieved RGS value based on a change in the temperature of the crystal oscillator.

In block 1110, the device processor may configure the notifying RAT to perform a handover operation to the identified base station using the RGS value retrieved in block 1108 (and optionally adjusted in optional block 710). In some embodiments, the device processor may utilize the obtained RGS value to determine the frequencies needed to inform the RAT to communicate with and receive service from the identified base station.

The device processor may cyclically repeat the above operations of method 1100 by again monitoring for sleep notifications from the RAT in block 1102.

Fig. 12 illustrates a method 1200 for configuring a first RAT to perform an inter-RAT measurement of a second RAT by utilizing an RGS value associated with the second RAT, in accordance with some embodiments. The method 1200 may be implemented with a processor (e.g., the general processor 206, the baseband modem processor 216, the crystal oscillator manager 230, a separate controller, and/or the like of a mobile communication device (e.g., the mobile communication device 200 of fig. 2). Referring to fig. 1, 2, and 4-12, operations of method 1200 may implement embodiments of operations of method 600 (see fig. 6). Thus, the device processor may begin performing the operations of method 1200 in response to storing the RGS value and its association in block 610 of method 600.

In block 1202, the device processor may monitor for an inter-RAT measurement notification from the first RAT, such as by monitoring for an indication or direct notification from a RAT that an inter-RAT measurement is to be or is about to be performed by the first RAT.

In determination block 1204, the device processor may determine whether an inter-RAT measurement notification from the first RAT has been received and continue to monitor for an inter-RAT measurement notification from the first RAT in block 1202 as long as the inter-RAT measurement notification is not received from the first RAT (i.e., determination block 1204 — no).

In response to determining that an inter-RAT measurement notification has been received from the first RAT (i.e., determining that block 1204 is yes), the device processor may identify a second RAT in block 1206 that the first RAT is to measure as part of the inter-RAT measurement. In some embodiments, the device processor may identify the second RAT directly from the inter-RAT measurement notification.

In block 1208, the device processor may retrieve a stored RGS value associated with the second RAT identified in block 1206, such as by performing a lookup in an associated data table (e.g., data tables 500, 510 described with reference to fig. 5A-5B) stored in memory to identify an RGS value associated with the second RAT, and retrieving the RGS value associated with the base station from memory (e.g., memory 214).

In optional block 710, the device processor may adjust the retrieved RGS value based on a change in at least one stored attribute associated with the RGS value retrieved in block 1208, such as by performing operations similar to those described in optional block 710 of method 700 (see fig. 7). In other words, the device processor may adjust the RGS value retrieved in block 1208 to compensate for any changes in the condition/environment of the mobile communication device that may have occurred since the RGS value was initially obtained and stored. For example, the device processor may adjust the retrieved RGS value based on a change in the temperature of the crystal oscillator.

In block 1210, the device processor may configure the first RAT to perform inter-RAT measurements of the second RAT using the RGS value retrieved in block 1208 (and optionally adjusted in optional block 710).

The device processor may cyclically repeat the above operations of method 1200 by again monitoring for sleep notifications from the RAT in block 1202.

The various embodiments may be implemented in various mobile communication devices, an example of which is illustrated in fig. 13 (e.g., mobile communication device 1300). According to various embodiments, the mobile communication device 1300 may be similar to the mobile communication devices 110, 120, 200 as described above with reference to fig. 1-2. Thus, the mobile communication device 1300 may implement the methods 600, 700, 720, 740, 820, 900, 1000, 1100, 800, 1200 in fig. 6-12.

The mobile communication device 1300 may include a processor 1302 coupled to a touchscreen controller 1304 and an internal memory 1306. The processor 1302 may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory 1306 may be volatile or non-volatile memory, and may also be secure and/or encrypted memory, or unsecure and/or unencrypted memory, or any combination thereof. The touch screen controller 1304 and processor 1302 can also be coupled to a touch screen 1312, such as a resistive sensing touch screen, a capacitive sensing touch screen, an infrared sensing touch screen, and the like. Additionally, the display of the mobile communication device 1300 does not require the capabilities of a touch screen.

The mobile communication device 1300 may have one or more wireless signal transceivers 1308a, 1308b (e.g., peanout, bluetooth, ZigBee, Wi-Fi, radio frequency radio units) and one or more antennas 1310, 1311 for sending and receiving communications, coupled to each other and/or to the processor 1302. The transceivers 1308a, 1308b and antennas 1310, 1311 may be used with the above-described circuitry to implement various wireless transmission protocol stacks and interfaces. The mobile communication device 1300 may include one or more SIM cards (e.g., SIM card 1319) coupled to the transceivers 1308a, 1308b and/or the processor 1302 and configured as described above. The mobile communication device 1300 may include one or more cellular network wireless modem chips 1316 coupled to the processor 1302 and antennas 1310, 1311 to enable communication over two or more cellular networks via two or more radio access technologies.

The mobile communication device 1300 may include a peripheral device connection interface 1318 coupled to the processor 1302. The peripheral device connection interface 1318 may be configured to accept only one type of connection, or may be configured to accept multiple types of physical and communication connections, common or proprietary, such as USB, FireWire, Thunderbolt, or PCIe. Peripheral device connection interface 1318 may also be coupled to a similarly configured peripheral device connection port (not shown).

The mobile communication device 1300 may also include a speaker 1314 for providing audio output. The mobile communication device 1300 may also include a housing 1320, constructed of plastic, metal, or a combination of materials, for containing all or a portion of the components discussed herein. The mobile communication device 1300 may include a power supply 1322, such as a disposable or rechargeable battery, coupled to the processor 1302. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the mobile communication device 1300. The mobile communication device 1300 may also include physical buttons 1324 for receiving user input. The mobile communication device 1300 may also include a power button 1326 for turning the mobile communication device 1300 on and off.

The above method descriptions and process flow diagrams are provided as illustrative examples only and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As one skilled in the art will recognize, the order of the steps in the above embodiments may be performed in any order. Words such as "after," "then," "next," etc. are not intended to limit the order of the steps; these words are simply used to guide the reader in understanding the description of the method. Furthermore, reference to claim elements in any singular form, for example, using the articles "a," "an," or "the" is not intended to be construed as limiting the element to the singular form.

The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

A general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein may implement or execute the hardware used to implement the various exemplary logic units, logic blocks, modules, and circuits described in connection with the aspects disclosed herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Further, some steps or methods may be performed by circuitry that is specific to a given function.

In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in processor-executable instructions residing on non-transitory computer-readable or processor-readable storage media. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that is accessible by a computer or processor. By way of example, and not limitation, such non-transitory computer-readable or processor-readable storage media can comprise RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc (disc), as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of non-transitory computer-readable or processor-readable storage media. Additionally, the operations of a method or algorithm may reside as one or any collection or combination of codes and/or instructions on a non-transitory processor-readable storage medium and/or computer-readable storage medium, which may be incorporated into a computer program product.

The online description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and principles and the novel features disclosed herein.

Claims (30)

1. A method implemented by a mobile communication device for improving performance of a plurality of Radio Access Technologies (RATs) on the mobile communication device, comprising:

obtaining a frequency error value for each RAT of the plurality of RATs;

associating, with each of the plurality of RATs and with at least one attribute, an obtained frequency error value based on a time at which the obtained frequency error values for the plurality of RATs are obtained, wherein an attribute comprises one of a temperature of the mobile communication device or a temperature of a crystal oscillator of the mobile communication device; and

storing the obtained frequency error value and the association of the obtained frequency error values.

2. The method of claim 1, wherein attributes further comprise one of a base station identification, a subscription identification, a geographic location of the mobile communication device, a serving network identification, and a timestamp.

3. The method of claim 1, further comprising:

identifying a RAT of the plurality of RATs that is associated with a request for a frequency error value from a requesting entity;

retrieving a stored frequency error value associated with the identified RAT; and

sending the obtained frequency error value to the requesting entity.

4. The method of claim 3, wherein retrieving the stored frequency error value associated with the identified RAT comprises:

identifying a first set of frequency error values associated with the identified RAT;

determining a confidence value for each frequency error value in the first set of frequency error values; and

retrieving a stored frequency error value of the first set of frequency error values having a highest confidence value in the first set of frequency error values.

5. The method of claim 3, further comprising: adjusting the retrieved frequency error value based on a change in at least one stored attribute associated with the retrieved frequency error value, wherein sending the retrieved frequency error value to the requesting entity comprises sending the adjusted frequency error value to the requesting entity.

6. The method of claim 5, wherein adjusting the derived frequency error value based on a change in at least one stored property associated with the derived frequency error value comprises adjusting the derived frequency error value based on a temperature change associated with the derived frequency error value.

7. The method of claim 3, wherein retrieving the stored frequency error value associated with the identified RAT comprises:

identifying a first set of frequency error values associated with the identified RAT;

determining whether at least one stored frequency error value is in the first set of frequency error values; and

retrieving an alternate stored frequency error value not associated with the identified RAT in response to determining that no frequency error value is in the first set of frequency error values.

8. The method of claim 7, further comprising:

determining whether at least one frequency error value in the first set of frequency error values has a confidence value that satisfies a confidence threshold in response to determining that at least one frequency error value is in the first set of frequency error values;

retrieving an alternative stored frequency error value not associated with the identified RAT in response to determining that none of the first set of frequency error values associated with the identified RAT has a confidence value that satisfies the confidence threshold; and

retrieving a stored frequency error value of the first set of frequency error values having a highest confidence value in the first set of frequency error values in response to determining that a frequency error value of the first set of frequency error values associated with the identified RAT has a confidence value that satisfies the confidence threshold.

9. The method of claim 7, wherein retrieving the alternative stored frequency error value that is not associated with the identified RAT comprises:

identifying a subscription associated with the identified RAT;

identifying a second set of frequency error values associated with the identified subscription; and

determining a confidence value for each stored frequency error value in the second set of frequency error values.

10. The method of claim 9, further comprising:

determining whether there is a stored frequency error value in the second set of frequency error values that satisfies a confidence threshold; and

in response to determining that there are stored frequency error values in the second set of frequency error values that satisfy the confidence threshold, retrieving a stored frequency error value in the second set of frequency error values that has a highest confidence value within the second set of frequency error values.

11. The method of claim 10, further comprising:

determining whether there are stored frequency error values available on the mobile communication device in response to determining that there are no stored frequency error values in the second set of frequency error values associated with the identified subscription that satisfy the confidence threshold;

retrieving a stored frequency error value having a highest confidence value available on the mobile communication device in response to determining that there are stored frequency error values available on the mobile communication device; and

generating a frequency error value approximation using a mathematical model in response to determining that no stored frequency error values are available on the mobile communication device.

12. The method of claim 1, further comprising:

determining an updated frequency error value for a RAT of the plurality of RATs based on current network conditions of the RAT;

associating the updated frequency error value with the RAT; and

storing the updated frequency error value and an association of the updated frequency error value with the RAT.

13. The method of claim 12, further comprising:

associating the updated frequency error value with at least one current attribute based on a time at which the updated frequency error value was determined, wherein storing the updated frequency error value and the association of the updated frequency error value with the RAT comprises storing the updated frequency error value and the association of the updated frequency error value with the RAT and with the at least one current attribute.

14. The method of claim 1, further comprising:

determining an updated frequency error value for a RAT of the plurality of RATs based on current network conditions of the RAT;

retrieving a stored frequency error value associated with the RAT; and

modifying the stored frequency error value associated with the RAT based on the updated frequency error value.

15. The method of claim 14, further comprising:

identifying at least one attribute associated with the updated frequency error value based on a time at which the updated frequency error value was determined; and

modifying at least one attribute associated with the modified frequency error value based on the identified at least one attribute associated with the updated frequency error value.

16. The method of claim 1, further comprising:

retrieving a frequency error value associated with a RAT of the plurality of RATs in response to receiving a sleep notification from the RAT;

determining a period based on the sleep notification and the derived frequency error value; and

configuring the RAT to wake up upon expiration of the period.

17. The method of claim 16, further comprising:

adjusting the derived frequency error value based on a change in at least one stored attribute associated with the derived frequency error value, wherein determining a period of time based on the sleep notification and the derived frequency error value comprises determining the period of time based on the sleep notification and the adjusted frequency error value.

18. The method of claim 1, further comprising:

determining that a RAT of the plurality of RATs is about to perform one of a network acquisition operation and a network reacquisition operation;

obtaining a frequency error value associated with the RAT; and

configuring the RAT to perform the one of the network acquisition operation and the network reacquisition operation based on the derived frequency error value.

19. The method of claim 18, further comprising:

adjusting the retrieved frequency error value based on a change in at least one stored attribute associated with the retrieved frequency error value, wherein configuring the RAT to perform the one of the network acquisition operation and the network reacquisition operation based on the retrieved frequency error value comprises configuring the RAT to perform the one of the network acquisition operation and the network reacquisition operation based on the adjusted frequency error value.

20. The method of claim 1, further comprising:

retrieving a frequency error value associated with a base station in response to determining that a RAT of the plurality of RATs is about to perform a handover operation to the base station; and

configuring the RAT to perform the handover operation to the base station based on the derived frequency error value.

21. The method of claim 20, further comprising:

adjusting the retrieved frequency error value based on a change in at least one stored attribute associated with the retrieved frequency error value, wherein configuring the RAT to perform the handover operation to the base station based on the retrieved frequency error value comprises configuring the RAT to perform the handover operation to the base station based on the adjusted frequency error value.

22. The method of claim 1, further comprising:

retrieving a frequency error value associated with a second RAT of the plurality of RATs in response to determining that an inter-RAT measurement of the second RAT is about to be performed by a first RAT; and

configuring the first RAT to perform the inter-RAT measurement of the second RAT based on the derived frequency error value.

23. The method of claim 22, further comprising:

adjusting the retrieved frequency error value based on a change in at least one stored attribute associated with the retrieved frequency error value, wherein configuring the first RAT to perform the inter-RAT measurement of the second RAT based on the retrieved frequency error value comprises configuring the first RAT to perform the inter-RAT measurement of the second RAT based on the adjusted frequency error value.

24. A mobile communication device, comprising:

a memory;

a Radio Frequency (RF) resource; and

a processor coupled to the memory, the RF resources, and at least one Subscriber Identity Module (SIM), wherein the processor is configured to:

obtaining a frequency error value for each of a plurality of Radio Access Technologies (RATs);

associating, with each of the plurality of RATs and with at least one attribute, an obtained frequency error value based on a time at which the obtained frequency error values for the plurality of RATs are obtained, wherein an attribute comprises one of a temperature of the mobile communication device or a temperature of a crystal oscillator of the mobile communication device; and

storing the obtained frequency error value and the association of the obtained frequency error value in the memory.

25. The mobile communication device of claim 24, wherein attributes further comprise one of a base station identification, a subscription identification, a geographic location of the mobile communication device, a serving network identification, and a timestamp.

26. The mobile communication device of claim 24, wherein the processor is further configured to:

identifying a RAT of the plurality of RATs that is associated with a request for a frequency error value from a requesting entity;

retrieve, from the memory, a stored frequency error value associated with the identified RAT; and

sending the obtained frequency error value to the requesting entity.

27. The mobile communication device of claim 26, wherein the processor is further configured to:

adjusting the derived frequency error value based on a change in at least one stored attribute associated with the derived frequency error value; and

sending the adjusted frequency error value to the requesting entity.

28. The mobile communication device of claim 24, wherein the processor is further configured to:

determining an updated frequency error value for a RAT of the plurality of RATs based on current network conditions of the RAT;

associating the updated frequency error value with the RAT; and

storing, in the memory, the updated frequency error value and an association of the updated frequency error value with the RAT.

29. A non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a mobile communication device to perform operations for improving performance of a plurality of Radio Access Technologies (RATs) on the mobile communication device, the operations comprising:

obtaining a frequency error value for each RAT of the plurality of RATs;

associating, with each of the plurality of RATs and with at least one attribute, an obtained frequency error value based on a time at which the obtained frequency error values for the plurality of RATs are obtained, wherein an attribute comprises one of a temperature of the mobile communication device or a temperature of a crystal oscillator of the mobile communication device; and

storing the obtained frequency error value and the association of the obtained frequency error values.

30. A mobile communication device, comprising:

means for obtaining a frequency error value for each of a plurality of Radio Access Technologies (RATs);

means for associating, with each of the plurality of RATs and with at least one attribute, an obtained frequency error value based on a time at which the frequency error values for the plurality of RATs were obtained, wherein an attribute comprises one of a temperature of the mobile communication device or a temperature of a crystal oscillator of the mobile communication device; and

means for storing the obtained frequency error value and the association of the obtained frequency error value.

Images