System and method for battery conservation with assistance from the network and radio resource management

CROSS REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims priority from U.S. Provisional Application No. 60/454,081, filed Mar. 11, 2003, which is incorporated by reference as if fully set forth herein.

FIELD OF INVENTION

[0002] The present invention relates generally to wireless transmit/receive unit (WTRU) battery conservation in wireless communications systems, and more particularly, to a method of achieving WTRU battery conservation with assistance from the network and from radio resource management (RRM).

BACKGROUND

[0003] It is known that battery life for a WTRU is an important aspect of the quality of service that an end user perceives, and any measure that could achieve battery savings is a desirable accomplishment in wireless communication system design. Some of the existing systems and methods for conserving battery power relate to reducing the power of at least part of the WTRU to conserve battery life. For example, in U.S. Pat. No. 5,539,925, a base station sends a signal to a mobile station to turn off the mobile station for a length of time communicated in the message. At the end of the “off” period, the mobile station will automatically restart itself to determine whether it needs to remain active or whether it can be turned off for an additional period.

[0004] U.S. Pat. No. 6,463,042 relates to a method in which a wireless terminal receives a header packet and estimates the power level of the header packet. The wireless terminal then receives a portion of a following data packet, and estimates the power level of the data packet. A comparison is made between the power level of the header packet and the power level of the data packet. If the power levels are approximately equal, then the wireless terminal will receive and process the remainder of the data packet. If the power level of the header packet is greater than the power level of the data packet, then this is an indication that the base station is operating in quasi-discontinuous transmission (Q-DTX) mode and that the wireless terminal can ignore the remainder of the data packet and put some of the components into a low power mode.

[0005] In U.S. Pat. No. 6,463,307, a hibernation request is made by either the base station or the mobile terminal. Parameters relating to the hibernation period, including when to wake the mobile terminal to check for paging messages or whether the mobile terminal has a data packet to send, are then set by the base station and transmitted to the mobile terminal. Once the hibernating period has ended, if there are any waiting paging messages, the mobile terminal is awakened and the paging messages are checked. If there are no paging messages, then a determination is made whether the mobile terminal has any pending data packets to send. If there are pending data packets, then the mobile terminal is awakened and the packets are sent. If there are no pending packets, then the mobile terminal returns to the hibernation mode.

[0006] The systems and methods described above relate only to the powering-down of components to conserve battery power, and not to methods for conserving battery power while the WTRU is actively transmitting. It would, therefore, be desirable to achieve battery savings when the WTRU is active.

SUMMARY

[0007] The present invention enables the radio resource management (RRM) in the radio network side to reduce wireless transmit/receive unit (WTRU) battery consumption. The WTRU reports its battery level information to the network. The RRM in the network can then make informed decisions to maximize the battery life of the WTRU while still maintaining the required quality of service (QoS) and system capacity. Based on reported battery levels, different RRM actions can be taken relating to call admission control, congestion control, user link maintenance, handover, power control, block error rate (BLER) target, and application configuration. The invention is described making reference to a universal mobile telecommunication system (UMTS) frequency-division duplex (FDD)/time-division duplex (TDD) system, but is applicable to any wireless system, including IEEE 802.11 and global system for mobile communications (GSM).

[0008] A method for battery conservation in a wireless communication system in accordance with the present invention begins with requesting a battery level measurement from a wireless transmit/receive unit (WTRU) by a radio network controller (RNC). The battery level is measured at the WTRU and is reported to the RNC. The battery level measurement is stored in the RNC, where it can be accessed by RRM procedures. The battery level measurement is applied to the RRM procedures by making adjustments to the procedures based on the battery level measurement, whereby the battery of the WTRU is conserved.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more detailed understanding of the invention may be had from the following description of a preferred embodiment, given by way of example and to be understood in conjunction with the accompanying drawings wherein:

[0010]FIG. 1 illustrates radio network controller (RNC) RRM actions according to WTRU battery level;

[0011]FIG. 2 is a flow chart of the RNC RRM behavior upon receiving the WTRU battery level;

[0012]FIG. 3 is a flowchart of a call admission control procedure incorporating checking the WTRU battery level;

[0013]FIG. 4 is a flowchart of a congestion control procedure incorporating checking the WTRU battery level;

[0014]FIGS. 5<i>a</i>-<b>5</b><i>c </i>are flowcharts of user link maintenance procedures incorporating checking the WTRU battery level; and

[0015]FIG. 6 is a flowchart of a handover procedure incorporating checking the WTRU battery level.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0016] An implementation of the invention is described in the following preferred embodiment, which is applicable to a UMTS (FDD/TDD) system. The invention is, however, applicable to any wireless system including, e.g., IEEE 802.11 and GSM. Hereafter a WTRU includes, but is not limited to, a user equipment, a mobile station, a fixed or mobile subscriber unit, a pager, or any other type of device capable of operating in a wireless environment. When referred to hereafter, a base station includes, but is not limited to, a base station, a Node-B, a site controller, an access point, or other interfacing device in a wireless environment.

[0017]FIG. 1 shows the exchange of information in a UMTS system <b>100</b>, including a WTRU <b>102</b> and an RNC <b>104</b>. The WTRU <b>102</b> reports its battery level to the network as follows. The RNC <b>104</b> requests the WTRU <b>102</b> to report the battery level measurement by sending a Measurement Control Message <b>110</b> in the downlink. In the message <b>110</b>, the RNC <b>104</b> configures the WTRU <b>102</b> with the measurement reporting criteria, such as the frequency of reporting for periodic-based reporting or the threshold for threshold-based reporting. The WTRU <b>102</b> reports its battery level by sending a Measurement Report Message <b>112</b> according to the reporting criteria dictated by the RNC <b>104</b>. In order to conserve battery power, the report message <b>112</b> can be transmitted along with other measurements. For example, in UMTS networks, the battery level can be reported in a manner similar to any other measurement (i.e., via radio resource control (RRC) signaling).

[0018] The information contained in the report message <b>112</b> can include the number of remaining minutes of talk time and the number of remaining minutes of idle time. This number can be either an instantaneous value based on the current transmission environment and current type of service (e.g., voice or data), or an average value based on the conditions for the last X minutes. Alternatively, the reported battery level can be the percentage of available battery power remaining. The WTRU <b>102</b> can be set to send the report message <b>112</b> periodically, or to send the report message <b>112</b> when a threshold is reached. The periodic reporting can range from one second to ten minutes, with a preferred default value of one minute. For the threshold based reporting, the WTRU may take frequent measurements, but will only send a measurement report to the RNC when a certain threshold is crossed. The types of evaluated thresholds include low, medium, and high thresholds, and will be explained in detail below.

[0019] The RRM in the RNC <b>104</b> makes informed decisions based on the reported battery level of the WTRU <b>102</b>. In general, the measurements used by the RRM to make a decision are those typically used in the art in connection with each type of decision, with the battery level of the WTRU <b>102</b> being used as an additional criterion. Some of the other measurements used by the RRM include downlink interference signal code power (ISCP), received signal code power (RSCP), and pathloss.

[0020] The procedures affected by the battery level measurement will be discussed in greater detail below. Viewed as a signal exchange between the WTRU <b>102</b> and the RNC <b>104</b>, the admission control procedure <b>120</b> is triggered by an admission request <b>122</b> sent by the WTRU <b>102</b>. The admission control <b>120</b> indicates whether a call has been admitted by sending an admission response <b>124</b>. A congestion control procedure <b>130</b> will configure the WTRU <b>102</b> for a new transmission rate by sending a signal <b>132</b>. A link maintenance procedure <b>140</b> will configure the WTRU <b>102</b> for a new transmission rate by sending a signal <b>142</b>. A handover procedure <b>150</b> will configure the WTRU <b>102</b> for handover by sending a signal <b>152</b>. A power control procedure <b>160</b> will change the BLER target of the WTRU <b>102</b> by sending a signal <b>162</b>.

[0021]FIG. 2 describes the RRM behavior <b>200</b> in the RNC <b>104</b> upon receiving the battery level report message <b>112</b> from the WTRU <b>102</b>. The RRM in the RNC <b>104</b> first receives the WTRU battery measurement report message <b>112</b> (step <b>202</b>). The RNC RRM then updates the WTRU battery level parameter and stores it in a database (step <b>204</b>). All other procedures have access to this parameter, since the procedure behavior changes according to the WTRU battery level as explained in connection with each procedure below. Three battery level thresholds are used as triggers: low, medium, and high. These thresholds are the same as those mentioned above in connection with the threshold-based battery level reporting. It should be understood by those of skill in the art that the specific battery levels and thresholds are design parameters that will vary with each implementation. Accordingly, these specific levels and thresholds will not be described hereinafter.

[0022] The WTRU battery level is checked to determine if it is below the low threshold (step <b>206</b>). If the battery level above the low threshold, then the WTRU battery level is checked (step <b>210</b>) to determine if it is above the medium threshold. The higher the BLER target is, the higher the transmission power that is needed and the battery will be drained faster. Therefore, it is desirable to adjust the BLER target based on the current battery level. If the battery level is below the medium threshold, the current BLER target is maintained (step <b>212</b>), and the procedure is terminated (step <b>214</b>).

[0023] If the battery level is above the medium threshold (step <b>210</b>), the BLER target is set to the “high quality BLER” target (step <b>220</b>). Next, the current level of compression is evaluated (step <b>222</b>). If the current level of compression is the highest level of compression, then switch to the lower level of compression (step <b>224</b>) and terminate the procedure (step <b>214</b>). Otherwise, maintain the current compression level and terminate the procedure (step <b>214</b>).

[0024] If the WTRU battery level is below the low threshold (step <b>206</b>), then the BLER target is set to the “low quality BLER” target (step <b>230</b>) to extend the battery life. Next, link maintenance is triggered (step <b>232</b>) to reduce the battery consumption rate, as explained below. The application configuration and the compression level are adjusted (step <b>234</b>) to conserve battery power, as explained below. The procedure then terminates (step <b>214</b>).

[0025] Call Admission Control

[0026] Referring now to FIG. 3, the Call Admission Control (CAC) procedure <b>300</b> begins by triggering CAC (step <b>302</b>), which is done when the WTRU <b>102</b> requests call admission from the RNC <b>104</b> (signal <b>122</b> in FIG. 1). Then the WTRU's battery level is checked (step <b>304</b>). The next step taken by the CAC procedure <b>300</b> depends directly upon the battery level and whether the current call is real time (shown as “RT” in FIG. 3) or non-real time (shown as “NRT” in FIG. 3).

[0027] If the battery level is low, CAC will only allow handover into a cell at the guaranteed bit rate for real time calls, and will only allow handover into the cell at the lowest bit rate (TFC1) for non-real time calls (step <b>306</b>). If the battery level is medium, CAC will only admit calls at the guaranteed bit rate for real time calls, and will admit at TFC2 (the second lowest bit rate) or a lower bit rate for non-real time calls(step <b>308</b>). If the battery level is high, for both real time and non-real time calls, CAC will admit the call at the maximum bit rate or lower (step <b>310</b>). The CAC behavior according to the battery level is summarized in the following table. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 1</entry></row></thead><tbody valign="top"><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>CAC behavior according to battery level.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><colspec colname="3" colwidth="119PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>CAC behavior</entry><entry>CAC behavior</entry></row><row><entry>Battery level</entry><entry>(real time services)</entry><entry>(non-real time services)</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>1. Low</entry><entry>Only allow handover into the cell</entry><entry>Only allow handover into the cell</entry></row><row>&lt;entry /&gt;<entry>and consider the guaranteed bit</entry><entry>and consider TFC1 (lowest rate)</entry></row><row>&lt;entry /&gt;<entry>rate for the admission decision</entry><entry>for admission decision for</entry></row><row>&lt;entry /&gt;<entry>and physical resource assignment.</entry><entry>handover. Assign physical</entry></row><row>&lt;entry /&gt;<entry>No other types of accesses are</entry><entry>resources based on the accepted</entry></row><row>&lt;entry /&gt;<entry>admitted.</entry><entry>bit rate. No other types of accesses</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;<entry>are admitted.</entry></row><row><entry>2. Medium</entry><entry>Consider the guaranteed bit rate</entry><entry>Consider TFC2 (second lowest</entry></row><row>&lt;entry /&gt;<entry>only for the admission decision</entry><entry>rate) or lower for admission</entry></row><row>&lt;entry /&gt;<entry>and assign physical resources</entry><entry>decisions. Assign physical</entry></row><row>&lt;entry /&gt;<entry>based on the guaranteed bit rate.</entry><entry>resources based on the accepted</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;<entry>bit rate. (Where TFC4 bit rate &gt; TFC3</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;<entry>bit rate &gt; TFC2 bit rate &gt; TFC1</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;<entry>bit rate &gt; 0.)</entry></row><row><entry>3. High</entry><entry>Consider the maximum bit rate</entry><entry>Consider the maximum bit rate</entry></row><row>&lt;entry /&gt;<entry>and below for the admission</entry><entry>and below for the admission</entry></row><row>&lt;entry /&gt;<entry>decision and assign physical</entry><entry>decision and assign physical</entry></row><row>&lt;entry /&gt;<entry>resources based on the accepted</entry><entry>resources based on the accepted</entry></row><row>&lt;entry /&gt;<entry>bit rate.</entry><entry>bit rate.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0028] After the bit rate determination has been made according to the current WTRU battery level (steps <b>306</b>, <b>308</b>, or <b>310</b>), the CAC procedure <b>300</b> proceeds to step <b>312</b>, where the cell load is checked to determine the allowable call admission bit rate. The accepted bit rate for the call is chosen by selecting the lower admission rate as determined by the battery level and the cell load (step <b>314</b>). Lastly, the physical resources required for the call are allocated (step <b>316</b>) and the procedure terminates (step <b>318</b>).

[0029] Besides the traditional criteria used to decide whether or not to admit the user and the bit rate for admission (e.g., interference, carrier power, cell load), the RNC <b>104</b> also adjusts the assigned bit rate depending on the WTRU battery level. The criteria that are evaluated for CAC depend on the procedure design and can vary, per known CAC procedures.

[0030] Also, code fragmentation in TDD is minimized for WTRUs with a low battery level. There are usually multiple solutions to assign the Orthogonal Variable Spreading Factor (OVSF) codes required by a call, in terms of the number of timeslots used and which codes to use in the tree. The fewer timeslots that are used, the lower the code fragmentation is. To minimize code fragmentation, the RNC RRM should allocate the codes in as few timeslots as possible. This reduces the possibility that the WTRU <b>102</b> raises its power level when it is far from the base station. Once the call has been admitted, the RNC <b>104</b> sends a response message to the WTRU (signal <b>124</b> in FIG. 1).

[0031] Congestion Control

[0032] Congestion control performs rate reduction and rate recovery in both the uplink and the downlink. For the present invention, the WTRU's battery level is considered when performing rate recovery in the uplink and rate reduction in the downlink. FIG. 4 shows a flow chart of a congestion control procedure <b>400</b> in accordance with the present invention. It is noted that the criteria used in the congestion control procedure <b>400</b> depend upon the design of the procedure. FIG. 4 shows a slow congestion control procedure, which uses the average noise rise in the uplink and the average transmit power in the downlink as criteria to decide whether or not to trigger rate control. It is to be understood that the slow congestion control procedure is only an example, and that the present invention is equally applicable to any congestion control procedure.

[0033] Referring now to FIG. 4, the congestion control procedure <b>400</b> begins by receiving measurement reports for interference and transmission power for each user (step <b>402</b>). Next, the average noise rise in the uplink and the transmit power in the downlink are calculated for all users (step <b>404</b>). These measurements are stored at the RNC, and are used several times during this procedure. When evaluating the uplink, a determination is made whether the average noise rise exceeds the threshold for rate reduction (step <b>406</b>). If the average noise rise is above the rate reduction threshold, then rate reduction is performed for the user with the highest interference level (step <b>408</b>) and the procedure terminates (step <b>409</b>).

[0034] If the average noise rise is below the rate reduction threshold (step <b>406</b>), a separate determination is made comparing the average noise rise to the threshold for rate recovery (step <b>410</b>). If the average noise rise is above the rate recovery threshold, then there is no need to invoke rate recovery (step <b>412</b>) and the procedure terminates (step <b>409</b>). If the average noise rise is below the rate recovery threshold, then the user with the lowest measured interference is selected (step <b>414</b>). As noted above, the interference is measured for all users in step <b>402</b>, and can be sorted either in step <b>402</b> or step <b>414</b>. Next, the selected user's WTRU battery level is checked to determine whether it is below the low battery level (step <b>416</b>). If the battery level is above the low level, then rate recovery is performed for the selected user (step <b>418</b>) and the procedure terminates (step <b>409</b>). If the battery level is below the low level, then the next user in the candidate list for rate recovery is selected (step <b>420</b>) and step <b>416</b> is repeated.

[0035] On the downlink, the average transmit power is compared to the threshold for rate reduction (step <b>430</b>). If the average transmit power is below the rate reduction threshold, a separate determination is made comparing the average transmit power to the threshold for rate recovery (step <b>432</b>). If the average transmit power is above the rate recovery threshold, then there is no need to invoke rate control (step <b>434</b>) and the procedure terminates (step <b>409</b>). If the average transmit power is below the rate recovery threshold, then rate recovery is performed for the user with the lowest transmit power (step <b>436</b>) and the procedure terminates (step <b>409</b>). As noted above, the transmission power for each user is stored in step <b>402</b>, and can be sorted either in step <b>402</b> or step <b>436</b>.

[0036] If the average transmit power is above the rate reduction threshold (step <b>430</b>), then the user with the highest transmit power is selected (step <b>438</b>). Next, the selected user's WTRU battery level is checked to determine whether it is below the low battery level (step <b>440</b>). If the battery level is above the low level, then rate reduction is performed for the selected user (step <b>442</b>) and the procedure terminates (step <b>409</b>). If the battery level is below the low level, then the next user in the candidate list for rate reduction is selected (step <b>444</b>) and step <b>440</b> is repeated.

[0037] In the procedure <b>400</b> on the uplink, if the RNC <b>104</b> has detected that the congestion situation has been relieved (the average noise rise is lower than the threshold for rate recovery), the RNC <b>104</b> uses the battery level of the WTRU <b>102</b> as an additional criterion. Increasing the uplink transmission rate drains the battery faster, because a higher transmission rate uses more power than a lower transmission rate. The congestion control ranks the WTRUs <b>102</b> according to their interference level from low interference to high interference. The congestion control then selects the WTRU <b>102</b> with the lowest interference level. If the selected WTRU's battery level is below the low threshold, the congestion control should pick the next WTRU <b>102</b> in the candidate list. If the battery level of the WTRU <b>102</b> is greater than the low level, then rate recovery can be performed.

[0038] In the procedure <b>400</b> on the downlink, the RNC <b>104</b> detects congestion based on the average value of recently received measurements. Once congestion is detected (the average transmit power is greater than the threshold for rate reduction), the RNC <b>104</b> chooses the user with highest transmit power for rate reduction. Decreasing the downlink receiving bit rate drains the battery faster because the WTRU <b>102</b> requires additional time to receive the same amount of data. Therefore, the RNC <b>104</b> uses the battery level of the WTRU <b>102</b> as an additional criterion for deciding whether to implement rate reduction. If the selected WTRU's battery level is below the low threshold, the congestion control should pick the next WTRU <b>102</b> in the candidate list. Otherwise, rate reduction can be performed for the selected WTRU. If the average transmit power is lower than the threshold for rate recovery, rate recovery should be conducted. Increasing the downlink receiving bit rate reduces the time for WTRU <b>102</b> to receive the same amount of data, thus extending battery life. Therefore, WTRU <b>102</b> battery level is not a criterion for rate recovery in the downlink.

[0039] Once the rate reduction or rate recovery is performed at the RNC <b>104</b>, the RNC <b>104</b> reconfigures the WTRU <b>102</b> for the new rate (signal <b>132</b> in FIG. 1).

[0040] User Link Maintenance

[0041] Referring now to FIGS. 5<i>a</i>-<b>5</b><i>c</i>, the user link maintenance procedure can be triggered by three different events: (1) upon receipt of a battery level measurement report at the RNC, (2) upon receipt of the WTRU transmit power measurement on the uplink, and (3) upon receipt of the code transmit power measurement on the downlink.

[0042]FIG. 5<i>a </i>shows a user link maintenance procedure <b>500</b> that is performed upon receipt of a battery level measurement report (step <b>502</b>). A determination is made whether the WTRU battery level is below the low level (step <b>504</b>). If the battery level is below the low level, then the user's bit rate is decreased if operating in the uplink and the bit rate is increased if operating in the downlink (step <b>506</b>) and the procedure terminates (step <b>507</b>).

[0043] If the battery level is above the low level (step <b>504</b>), then a separate determination is made whether the battery level is above the high level (step <b>508</b>). If the battery level is below the high level, then there is no need to invoke link rate control (step <b>510</b>) and the procedure terminates (step <b>507</b>). If the battery level is above the high level, then a separate determination is made whether the user link rate was reduced by another rate reduction procedure due to the triggering of a battery level measurement report (step <b>512</b>). If the link rate was not previously reduced, then there is no need to invoke link rate control (step <b>510</b>) and the procedure terminates (step <b>507</b>). If the link rate was previously reduced, then a determination is made whether the transmission power and the measured interference are low (step <b>514</b>). If both the transmission power and the measured interference are not low, then there is no need to invoke link rate control (step <b>510</b>) and the procedure terminates (step <b>507</b>). If both the transmission power and the measured interference are low, then rate recovery is performed, in which the uplink and downlink rates for the user are restored to the last rates used before the rate reduction (step <b>516</b>) and the procedure terminates (step <b>507</b>).

[0044]FIG. 5<i>b </i>shows a user link maintenance procedure <b>520</b> that is performed upon receipt of the WTRU transmit power in the uplink (step <b>522</b>). The WTRU transmit power is checked to determine if it is above the threshold for rate reduction (step <b>524</b>). If the transmit power is above the rate reduction threshold, then rate reduction is performed (step <b>526</b>) and the procedure terminates (step <b>527</b>). If the transmit power is below the rate reduction threshold (step <b>524</b>), then a separate determination is made whether the WTRU transmit power is below the threshold for rate recovery (step <b>528</b>). If the transmit power is below the rate recovery threshold, then another determination is made whether the WTRU battery level is below the low level (step <b>530</b>). If the battery level is above the low level, then rate recovery is performed (step <b>532</b>) and the procedure terminates (step <b>527</b>). If the battery level is below the low level, then rate recovery is not performed (step <b>534</b>) and the procedure terminates (step <b>527</b>). If the transmission power is above the threshold for rate recovery (step <b>528</b>), then rate recovery is not performed (step <b>534</b>) and the procedure terminates (step <b>527</b>).

[0045]FIG. 5<i>c </i>shows a user link maintenance procedure <b>540</b> that is performed upon receipt of the code transmit power measurement in the downlink (step <b>542</b>). The code transmit power is checked to determine if it is above the threshold for rate reduction (step <b>544</b>). If the code transmit power is below the rate reduction threshold, a determination is made whether the code transmit power is below the threshold for rate recovery (step <b>546</b>). If the code transmit power is above the rate recovery threshold, then there is no need to invoke link rate control (step <b>548</b>) and the procedure terminates (step <b>549</b>). If the code transmit power is above the rate recovery threshold, then rate recovery is performed (step <b>550</b>) and the procedure terminates (step <b>549</b>).

[0046] If the code transmit power is above the rate reduction threshold (step <b>544</b>), then the WTRU battery level is checked to determine if it is below the low level (step <b>552</b>). If the battery level is above the low level, then rate reduction is performed (step <b>554</b>) and the procedure terminates (step <b>549</b>). If the battery level is below the low level, then rate reduction is not performed (step <b>556</b>) and the procedure terminates (step <b>549</b>).

[0047] The WTRU battery measurement report can be a trigger of the user link maintenance procedure. If the RNC <b>104</b> receives a battery report message <b>112</b> indicating a low battery level, the WTRU bit rate in the uplink is decreased to reduce the battery consumption rate, which is especially useful for long calls. The RNC <b>104</b> configures the WTRU <b>102</b> for a lower bit rate (signal <b>142</b> in FIG. 1). In the downlink, the RNC <b>104</b> increases the bit rate transmitting to the WTRU <b>102</b>, thus shortening the power-on time of the WTRU <b>102</b>. If the RNC <b>104</b> receives a battery report message <b>112</b> indicating a battery level above the low level, and if the bit rate was reduced before due to low battery, the link rate in uplink and downlink will be restored to the previous rate before the last rate reduction.

[0048] In the downlink, if user link maintenance is triggered by another measurement, for example, by code transmit power, the RNC <b>104</b> uses the battery level of the WTRU <b>102</b> as an additional criterion for rate reduction. The criteria used depends on the design of the link maintenance control procedure <b>500</b>, <b>520</b>, <b>540</b>. Different approaches in performing link maintenance control may use different criteria. For example, the link maintenance control procedures described above use uplink WTRU transmit power and downlink code transmit power. If the WTRU's battery level is below the low threshold, decreasing the downlink receiving bit rate increases the time for the WTRU <b>102</b> to receive the same amount of data, thus draining the WTRU <b>102</b> battery faster. Therefore, the link maintenance should not decrease the receiving bit rate for the WTRU <b>102</b>.

[0049] In the uplink, if the user link maintenance is triggered by another measurement, for example, by the WTRU transmit power, the RNC <b>104</b> uses the battery level of the WTRU <b>102</b> as an additional criterion for rate recovery. If the WTRU's battery level is below the low threshold, increasing the uplink transmission bit rate drains the battery faster. Thus, the link maintenance should not increase the transmission bit rate for the WTRU <b>102</b>.

[0050] Handover

[0051]FIG. 6 shows a handover procedure <b>600</b> in accordance with the present invention. The RNC first receives a handover request (step <b>602</b>) and then checks if there are additional handover requests waiting to be processed (step <b>604</b>). If there are additional handover requests, the WTRU with the lowest battery level is selected (step <b>606</b>). Next, the number of soft handover legs are determined, and the number is kept as low as possible when operating in FDD (step <b>608</b>). If, at step <b>604</b>, there are no additional requests, step <b>606</b> is skipped, and the procedure continues with step <b>608</b>. Lastly, the handover is performed (step <b>610</b>) and the procedure terminates (step <b>612</b>).

[0052] A higher priority for handover is given to a WTRU <b>102</b> with a low battery level (signal <b>152</b> in FIG. 1). The battery level can be used to decide the number of soft handover legs for FDD, where the lower the battery level, the fewer the number of handover legs that should be assigned. In FDD, the WTRU <b>102</b> can have simultaneous radio link connections (soft handover legs) in different cells. The more handover legs that are established, the faster the WTRU's battery will be consumed due to the extra processing needed for the extra handover legs.

[0053] Power Control

[0054] The BLER target is changed according to the WTRU battery level. At call admission, the RNC RRM checks the service and determines the BLER target based upon the service type. The service type is the quality of service class, for example, conversational, streaming, interactive/background, signaling AM/UM, or other service type. For each service type, there are two possible BLER targets for the RNC RRM when considering WTRU battery level.

[0055] The first possible BLER target is the “low quality BLER,” which is the minimum BLER acceptable by the network and can be used by the WTRU <b>102</b> when its battery level is below the low threshold. The second possible BLER target is the “high quality BLER,” which is better than the low quality BLER and can be used by the WTRU <b>102</b> when its battery level is above the medium threshold. A WTRU needs to transmit with higher power in order to meet a high quality BLER target, so the battery needs to have sufficient power to prevent a rapid depletion.

[0056] During a call, the power control is triggered based on the WTRU battery level (signal <b>162</b> in FIG. 1). An example of the numerical values both of the BLER target for several different service types is shown in Table 2. These values should be operations, administration, and maintenance (OA&amp;M) configurable. The power control procedure can be triggered by the battery level measurement report, as shown in steps <b>220</b> and <b>230</b> of FIG. 2. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 2</entry></row></thead><tbody valign="top"><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>BLER target for different battery levels.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="77PT" align="left" /><colspec colname="1" colwidth="70PT" align="center" /><colspec colname="2" colwidth="70PT" align="center" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Uplink BLER</entry><entry>Downlink BLER</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="77PT" align="left" /><colspec colname="2" colwidth="35PT" align="center" /><colspec colname="3" colwidth="35PT" align="center" /><colspec colname="4" colwidth="35PT" align="center" /><colspec colname="5" colwidth="35PT" align="center" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Low</entry><entry>High</entry><entry>Low</entry><entry>High</entry></row><row><entry>Traffic Class</entry><entry>Quality</entry><entry>Quality</entry><entry>Quality</entry><entry>Quality</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>Conversational</entry><entry>10⁻²</entry><entry>5 × 10⁻²</entry><entry>10 ⁻²</entry><entry>5 × 10⁻²</entry></row><row><entry>Streaming</entry><entry>10⁻²</entry><entry>5 × 10⁻²</entry><entry>10⁻²</entry><entry>5 × 10⁻²</entry></row><row><entry>Interactive/Background</entry><entry>10⁻³</entry><entry>5 × 10⁻³</entry><entry>10⁻³</entry><entry>5 × 10⁻³</entry></row><row><entry>Signaling AM/UM</entry><entry>10⁻³</entry><entry>5 × 10⁻³</entry><entry>10⁻³</entry><entry>5 × 10⁻³</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0057] Application Configuration

[0058] For non-real time (NRT) calls, compression layers can be configured to provide multiple levels of coding compression. Application configuration uses the battery level of the WTRU <b>102</b> as the only criterion to determine the compression level. The lower the battery level, the higher the level of compression that will be configured. At the application level, i.e., outside the UMTS terrestrial radio access network (UTRAN), the application can be optimized to provide different levels of information. For example, in the case of a low battery level during Web browsing, the application can be configured to only allow the download of text and not pictures. The battery level measurement report can trigger the application configuration procedure as described above in connection with steps <b>224</b> and <b>234</b> of FIG. 2.

[0059] While this invention has been particularly shown and described with reference to preferred embodiments, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the scope of the invention as described hereinabove.