Apparatus, method and computer program product providing for release, configuration and reconfiguration of E-RGCH/E-HICH at a serving cell change

Communications are received from a user equipment UE on an uplink enhanced dedicated channel E-DCH. The radio resources of at least one downlink channel that supports the E-DCH are either released or configured or reconfigured while the E-DCH is maintained for the UE. The downlink channels may be E-AGCH, E-HICH, or E-RGCH, and the radio resources may include a temporary identifier E-RNTI, signature sequence, and/or channelization codes. At a serving cell change of the UE, either or both of the serving cell and the non-serving cell can add/configure/reconfigure a supporting downlink channel, all without terminating the E-DCH. The UE and the SRNC are notified by an E-RGCH release indicator whether the E-RGCH is released or not at a serving cell change, and the UE deletes its stored E-RGCH parameters when the release indicator indicates it is released.

TECHNICAL FIELD

The exemplary and non-limiting embodiments of this invention relate generally to wireless communications systems and, more specifically, relate to methods and apparatus that provide packet data transfer capabilities in a digital wireless communications system.

BACKGROUND

The following abbreviations that appear in the ensuing description are defined as follows:3GPP Third Generation Partnership ProjectDCH Dedicated ChannelDL Downlink (Node B to UE)E-AGCH E-DCH Absolute Grant ChannelE-DCH Enhanced DCHE-HICH E-DCH HARQ Acknowledgment Indicator ChannelE-RGCH E-DCH Relative Grant ChannelE-RNTI E-DCH Radio Network Temporary IdentifierHARQ Hybrid Automatic Repeat reQuestHSUPA High Speed Uplink Packet AccessIE Information ElementNBAP Node B Application ProtocolNode B Base stationRNC Radio Network ControllerRNSAP Radio Network Subsystem Application ProtocolRRC Radio Resource ControlSRNC Serving RNCRL Radio LinkRoT Rise over ThermalUE User EquipmentUL Uplink (UE to Node B)VoIP Voice over Internet Protocol

For 3GPP it has been agreed that there are to be two scheduling methods. These are an Absolute Grant method that uses E-AGCH, and a Relative Grant method that uses E-RGCH. The E-AGCH is a shared downlink channel that is used to provide an absolute limitation on the amount of uplink resources the UE may use for the E-DCH, scheduling how much data the UE can send (data rate) and maximum power. The E-RGCH complements the E-AGCH, and is used to increase or decrease the scheduled rate and/or power the UE sends on the E-DCH as compared to the previous value granted (e.g., granted over the E-AGCH or by a previous command over the E-RGCH). The E-AGCH is sent from only one cell, referred to as the E-DCH serving cell. The E-RGCH may be sent from each cell in an E-DCH Active Set, i.e., E-RGCH is not mandated to be sent from all cells in the E-DCH Active Set. It is left to the Node B implementation for configuring the E-RGCH resource for the UE. The E-HICH is the Hybrid Automatic Repeat Request (HARQ) channel, a physical channel used by the HARQ process to acknowledge transmissions from the user equipment on the E-DCH. The makes the uplink more resilient to signal errors by allowing retransmissions of faulty packets, as requested by the Node B by acknowledgements or negative acknowledgements.

Respecting the E-RGCH, there can be a serving relative grant and a non-serving relative grant on that shared physical channel. Transmitted on the downlink E-RGCH, the serving relative grant is from any cell in the serving E-DCH RL service, and allows the Node B to adjust the granted rate of UE's under its control. Typically, the command for the serving relative grant is “UP”, “DOWN”, or “HOLD”. Also transmitted on the downlink E-RGCH is the non-serving relative grant. This allows neighboring Node B's to adjust the transmitting rate of UE's not under its control (e.g., in neighboring cells under control of the serving Node B) in order to avoid overload situations. Typically, the command for the non-serving relative grant is either “HOLD” or “DOWN”. Multiple non-serving relative grants can be sent to a UE at one time (since there may be multiple neighboring cells under control of different non-serving Node B's), whereas by definition there may be only one serving relative grant sent to a UE at any one time (from its serving cell as scheduled by the serving Node B).

In the current specification the E-RGCH is configured only when the E-DCH is setup, and there is no technique specified to release, configure and reconfigure the E-RGCH in the Node B after the setup of E-DCH, i.e., the Node B is required to use the same E-RGCH configuration until the E-DCH is released, or until the RL is deleted. Conversely, in the case that the Node B does not configure the E-RGCH at E-DCH setup, the Node B will not have the E-RGCH until the E-DCH is released.

As the E-DCH concept is a new feature for 3GPP, prior to this invention there were no satisfactory solutions to the foregoing problems.

SUMMARY

The foregoing and other problems are overcome, and other advantages are realized, in accordance with the presently described embodiments of these teachings.

In accordance with an exemplary embodiment of the invention, there is provided a method for managing radio resources in a wireless network. In the method, communications are received from a user equipment UE on an uplink enhanced dedicated channel E-DCH. Then, radio resources of at least one downlink channel that supports the E-DCH are either released, configured or reconfigured while the E-DCH is maintained for the UE.

In accordance with another exemplary embodiment of the invention, there is provided a program of machine-readable instructions, tangibly embodied on an information bearing medium and executable by a digital data processor, to perform actions directed toward reconfiguring control of a channel. The actions include receiving communications from a user equipment UE on an uplink enhanced dedicated channel E-DCH, and for at least one downlink channel that supports the E-DCH, one of releasing or configuring or reconfiguring radio resources of the at least one downlink channel while the E-DCH is maintained for the UE.

In accordance with another exemplary embodiment of the invention, there is provided a network element that includes a transceiver, a memory, and a data processor coupled to the memory and to the transceiver. The data processor as coupled operates to release, reconfigure, or configure radio resources of at least one downlink channel that supports an enhanced dedicated channel E-DCH for a user equipment UE without terminating the E-DCH. The data processor further operates to signal the releasing, configuring, or reconfiguring of the radio resources to one of a higher network element or to the UE.

In accordance with an exemplary embodiment of the invention, there is provided a mobile station that includes a transceiver, a memory, and a data processor coupled to the memory and to the transceiver. The transceiver, which may be one or more, is for transmitting data on an enhanced dedicated channel E-DCH and for receiving a first and a second message. The first message includes configuration parameters for at least one downlink channel that supports the E-DCH. The second message includes an instruction to cancel, change or add to the configuration parameters. The memory is for storing the configuration parameters. After receipt by the mobile station of the first message, the data processor is for configuring the transceiver to receive the at least one downlink channel according to the configuration parameters of the first message. After receipt by the mobile station of the second message, the data processor is for changing the stored configuration parameters according to the instruction, and also for re-configuring the transceiver to receive the at least one downlink channel according to the changed configuration parameters while maintaining the uplink E-DCH for the mobile station.

In accordance with another embodiment is a method for operating a network Node B. In this method, the Node B receives from a serving radio network controller SRNC a RADIO LINK RECONFIGURATION PREPARE message that relates to a serving cell change that involves the Node B and a user equipment UE. Responsive to receiving the PREPARE message, the Node B sends to the SRNC a RADIO LINK RECONFIGURATION READY message. In the method the Node B also receives from the SRNC a RADIO LINK RECONFIGURATION REQUEST message that is related to the serving cell change. Responsive to that REQUEST message, the Node B sends to the SRNC a RADIO LINK RECONFIGURATION RESPONSE message. At least one of the READY message and the RESPONSE message includes an information element E-RGCH RELEASE INDICATOR, which is indicative of whether an enhanced relative grant channel E-RGCH is released or not released. The Node B releases, configures, or reconfigures the E-RGCH in accordance with the RADIO LINK RECONFIGURATION RESPONSE message while maintaining an enhanced dedicated channel E-DCH for the UE.

In accordance with another embodiment, a network element includes means for receiving data from a user equipment UE over a dedicated traffic channel (such as for example a receiver), means for sending control messages to the UE over a downlink channel associated with the dedicated traffic channel (such as for example a transmitter. The network element further includes means for releasing or reconfiguring the downlink control channel, or for configuring an additional downlink control channel; either of which is without terminating the dedicated traffic channel. An example of the means for releasing/reconfiguring/configuring is a processor coupled to a computer program stored on a memory and coupled to the transmitter. The network element further includes means for communicating said releasing, reconfiguring, or configuring to the UE (such as for example the transmitter).

Further details as to these and other embodiments, implementations and variations are detailed below.

DETAILED DESCRIPTION

The inventor has realized that the above-described proposed scheduling implementations noted in the Background section may generate the following problems during and after a serving cell change by the UE.

1) In the case where the serving cell does not have the E-RGCH, and when it becomes a non-serving cell, the Node B, which the cell belongs to, would desire to configure the E-RGCH in order to reduce the RoT in the cell (RoT indicates the ratio between the total power received from wireless sources at a Node B and the thermal noise, and is known in the art). However, it is not possible to configure the E-RGCH, and thus the Node B cannot reduce the RoT generated by the UE in the cell.

2) In the case where the serving cell has the E-RGCH, and when it becomes a non-serving cell, the Node B, which the cell belongs to, would desire to release the E-RGCH since the Node B does not support E-RGCH from the non-serving RL set. However, it is not possible to release the E-RGCH in this case, as the E-RGCH resource (code and signature sequence) must be reserved even if the E-RGCH is never sent to the UE.

3) In the case where the serving cell has the E-RGCH, and when it becomes the non-serving cell, the Node B, which the cell belongs to, would desire to reconfigure the E-RGCH from a “dedicated E-RGCH” condition, which code/signature sequence is allocated to one UE only, to a “common E-RGCH” condition, where the code/signature sequence is allocated to multiple UEs. However, it is not possible to configure the E-RGCH in this case, as the Node B must send a “dedicated” E-RGCH (overload indicator) for reducing the RoT, which is a waste of the E-RGCH resource and the DL radio resource.

4) In the case where the non-serving cell does not have the E-RGCH, and when it becomes the serving cell, the Node B, which the cell belongs to, would desire to have the E-RGCH that complements the E-AGCH in the serving Node B. However, it is not possible to configure E-RGCH in this case as the Node B must always use the E-AGCH, even if it supports E-RGCH from the serving RLS.

5) In the case where the non-serving cell has the E-RGCH, and when it becomes the serving cell, the Node B, which the cell belongs to, would desire to release E-RGCH. However, it is not possible to release the E-RGCH in this case as the E-RGCH resource must be reserved, even if the E-RGCH is never sent to the UE.

6) In case where the non-serving cell has the E-RGCH, and when it becomes the serving cell, the Node B, which the cell belongs to, would desire to reconfigure the E-RGCH from the “common E-RGCH” to the “dedicated E-RGCH”. However, it is not possible to reconfigure the E-RGCH in the current specification as the Node B must instead use the “common” E-RGCH.

The first and third problems discussed above are particularly critical problems. The exemplary embodiments of this invention address the first and third problems, as well as the other problems enumerated above.

It is noted that these and similar issues can arise for the E-AGCH/HICH, as the same channelization code and E-RNTI for the E-AGCH in the serving cell are to be used until the serving cell becomes the non-serving cell, or the E-DCH is released. The same channelization code and signature sequence for the E-HICH are to be used until the E-DCH is released. The reconfiguration of code and signature sequence for E-AGCH and E-HICH is required for a system that implements VoIP over HSUPA, since it may be expected that, for example, 100 UEs are in the cell and the reconfiguration could result in the benefits of saving the code and signature resources. In general, the term radio resources as used herein includes channelization codes, signature sequences, temporary network identifiers, and other parameters (channel configuration parameters or network identifiers for UE) for a radio link (e.g., the E-RGCH or E-HICH) between a UE and a Node B (or a RNC).

The exemplary embodiments of this invention relate generally to HSUPA and to enhancements to the uplink DCH (E-DCH) for packet data traffic. The exemplary embodiments of this invention may be used in, as a non-limiting example, Release 6 of 3GPP.

Reference is made first toFIG. 1for illustrating a simplified block diagram of various electronic devices that are suitable for use in practicing the exemplary embodiments of this invention. InFIG. 1a wireless network1includes a UE10, a Node B (base station)12and a RNC14(the RNC14may be referred to below as the SRNC14). The UE10includes a data processor (DP)10A, a memory (MEM)10B that stores a program (PROG)10C, and a suitable radio frequency (RF) transceiver10D for bidirectional wireless communications with the Node B12, which also includes a DP12A, a MEM12B that stores a PROG12C, and a suitable RF transceiver12D. The Node B12is coupled via a data path13(Iub/Iur interfaces) to the RNC14that also includes a DP14A and a MEM14B storing an associated PROG14C. The PROGs12C and14C are assumed to include program instructions that, when executed by the associated DP, enable the electronic device to operate in accordance with the exemplary embodiments of this invention, as will be discussed below in greater detail. Note that the implementation of the exemplary embodiments of this invention can be accomplished without requiring a change to the PROG10C of the UE10.

The embodiments of this invention may be implemented by computer software executable by the DP12A of the Node B12and the DP14A of the RNC14, or by hardware, or by a combination of software and hardware.

The use of the exemplary embodiments of this invention enable the release, configuration and reconfiguration of the E-RGCH/HICH at a serving cell change and, more generally, at any desired time.

Discussed first are exemplary embodiments (A)-(D) for releasing the E-RGCH resource at a serving cell change.

A) The Node B12indicates to the SRNC14whether the E-RGCH is released or is not released (e.g., an E-RGCH release indicator) each time the serving E-DCH RL change is executed (the cell is changed from the serving cell to the non-serving cell or vice versa).

B) The Node B12indicates to the SRNC14that the E-RGCH is released (e.g., an E-RGCH release indicator) when the serving E-DCH RL change is executed. It should be noted that if the Node B12does not release the E-RGCH, then the Node B12does not need to indicate at all to the SRNC14.

C) The Node B12indicates to the SRNC14one of the following three items each time the serving E-DCH RL change is executed:a. E-RGCH is reconfigured and the new configuration parameters (e.g., channelization code and signature sequence) for the reconfigured E-RGCH;b. E-RGCH is maintained (e.g., a negative release indicator); orc. E-RGCH is released (e.g., a positive release indicator).

D) The Node B12indicates, at any time, to the SRNC14that the Node B desires to release the current E-RGCH, including at a time when the E-DCH RL change is executed.

It can be noted that there are no cases seen where the E-HICH is released and the E-AGCH is released in the serving cell.

After the reception of the request for the release from the Node B12at the SRNC14, the SRNC14sends the UE10the request to release.

Discussed now are exemplary embodiments (A) and (B) for configuring and reconfiguring the E-RGCH/E-HICH resource at a serving cell change.

A) The Node B12indicates to the SRNC14whether or not the E-RGCH/E-HICH is configured (and reconfigured) each time that the serving E-DCH RL change is executed. In addition, configuration parameters (e.g., channelization code and signature sequence) for the E-RGCH/E-HICH are sent to the SRNC14when the Node B12indicates that the E-RGCH/HICH is configured or reconfigured.

B) The Node B12indicates to the SRNC14that the Node B12desires to configure/reconfigure the E-RGCH/E-HICH/E-AGCH at anytime (including a time when the E-DCH RL change is executed). It can be noted that the reconfiguration of the E-AGCH is only made possible by the use of this embodiment.

After the reception of the request for the configuration/reconfiguration from the Node B12at the SRNC14, the SRNC14sends UE10the request to configure/reconfigure.

With regard to exemplary implementations of the foregoing, in particular the releasing of the E-RGCH at the serving cell change in embodiment (A), a new IE may be defined (for example, one referred to as “E-RGCH Release Indicator”), which indicates to the SRNC14whether or not the E-RGCH is released. This IE can be placed in a Response message (e.g., RNSAP/NBAP: RADIO LINK RECONFIGURATION READY and RADIO LINK RECONFIGURATION RESPONSE) for the message requests to execute the serving cell change. The new IE is preferably also introduced in a RRC message (as one non-limiting example, in a PHYSICAL CHANNEL RECONFIGURATION message) for informing the UE10.

An example of the use of the E-RGCH Release Indicator IE (designated as100) is shown inFIG. 2, in the context of Table 9.1.43 (page 212) of 3GPP TS 25.433 V6.6.0 (2005-06); 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iub Interface Node B Application Part (NBAP) signaling (Release 6).

FIG. 3shows an exemplary embodiment of the IE/Group Name and IE Type and Reference for the E-RGCH Release Indicator.

With regard to exemplary implementations of the embodiment (B) for releasing the E-RGCH resource at a serving cell change discussed above, a new IE which indicates that the E-RGCH is released can be introduced in the Response message (e.g., RNSAP/NBAP: RADIO LINK RECONFIGURATION READY and RADIO LINK RECONFIGURATION RESPONSE) for the message requests to execute serving cell change. The new IE is preferably also introduced in a RRC message (as one non-limiting example, in a PHYSICAL CHANNEL RECONFIGURATION message) for informing the UE10.

With regard to exemplary implementations of the embodiment (C) for releasing the E-RGCH resource at a serving cell change discussed above, a new IE to indicate one of the following:a. E-RGCH is configured or reconfigured;b. E-RGCH is maintained; orc. E-RGCH is released
may be introduced in the Response message (e.g., RNSAP/NBAP: RADIO LINK RECONFIGURATION READY and RADIO LINK RECONFIGURATION RESPONSE) for the message requests to execute the serving cell change. This new IE also preferably includes the IE that carries the configuration parameters (e.g., channelization code and E-RGCH Signature Sequence IE) for the reconfigured E-RGCH, or the existing E-DCH FDD DL Control Channel Information IE may carry the configuration parameters. The new IE is preferably also introduced in a RRC message (as one non-limiting example, in a PHYSICAL CHANNEL RECONFIGURATION message) for informing the UE10.

With regard to exemplary implementations of the embodiment (D) for releasing the E-RGCH resource at a serving cell change discussed above, a new IE may be introduced to indicate that the Node B12desires to release the E-RGCH. This IE can be placed in an existing NBAP/RNSAP RADIO LINK PARAMETER UPDATE message, or in a new RNSAP/NBAP message. The NBAP/RNSAP RADIO LINK PARAMETER UPDATE message is found at section 8.3.19 (page 140) of TS25.433, v6.6.0. For replying to the Node B12, another new IE may be introduced to indicate a SRNC14request to the Node B12to release the E-RGCH. This new IE may be introduced in an existing RNSAP/NBAP RADIO LINK RECONFIGURATION PREPARATION/REQUEST message specified in Tables 9.1.42 and 9.1.47 of TS25.433, v6.6.0. The new IE is preferably also introduced in a RRC message (as one non-limiting example, in a PHYSICAL CHANNEL RECONFIGURATION message) for informing the UE10.

With regard to exemplary implementations of the embodiment (A) for (re)configuring E-RGCH/HICH at serving cell change discussed above, a new IE, similar to that discussed above for embodiments A and C, can be used. The configuration parameters for E-RGCH/HICH configured/reconfigured may be carried in a new IE, or in the existing E-DCH FDD DL Control Channel Information.

With regard to exemplary implementations of the embodiment (B) for (re)configuring E-RGCH/HICH at serving cell change discussed above, a new IE, similar to that discussed above for embodiment D, can be used.

The use of the non-limiting and exemplary embodiments of this invention enable the release of unnecessary E-RGCH resources when the E-DCH RL Serving cell change is executed, and thus avoid wasting these resources. The use of the non-limiting and exemplary embodiments of this invention further enable the configuration or reconfiguration of necessary E-RGCH resources when an E-DCH RL Serving cell change is executed, and enable the Node B12to continue to use the E-RGCH. Further, no new procedures or messages need to be introduced in the RNSAP/NBAP signaling, as only one or more new IEs in existing messages need to be introduced in the specification (such as the E-RGCH Release Indicator IE that was discussed above and shown inFIGS. 2 and 3).

FIG. 4illustrates in a schematic diagram operation of an exemplary embodiment by the various nodes involved. The RNC14is as previously described. The Node B is represented by a first base station BS112(e.g., the serving Node B to the MS prior to the serving cell change) and a second base station BS212′ (e.g., the non-serving Node B prior to the serving cell change). Where the two base stations BS112and BS212′ represent different node B's, they may be under the control of a single RNC (serving RNC) or may be under control of different RNCs. A mobile station MS10moves from a first location31where it is under the control of the first BS112to a second location31′ where it is under the control of the second BS212′, representing a serving cell change for the MS10. Embodiments of this invention are not limited to serving cell changes, though that is a convenient occurrence to initiate the release, configuration, and/or reconfiguration of radio resources as described herein.

Assume forFIG. 4that a dedicated channel E-DCH is set up by the serving BS112for the MS10prior to the serving cell change (though the MS10with the E-DCH already established may have previously been changed to the first BS112). The first BS112configures for the MS10(while it is the serving Node B) an absolute grant channel E-AGCH32and a relative grant channel E-RGCH34, which respectively set an absolute ceiling on data rate and power that the UE is allowed to use on the E-DCH, and a relative adjustment/increment to that ceiling that may be commanded to the UE from time to time by BS112based on changing conditions in the cell. Also shown inFIG. 4is the downlink E-HICH37,37′, which the BS12uses to prompt the MS10to re-send data that was not properly received at the BS12. Each of the E-AGCH, E-RGCH and E-HICH use radio resources, such as an enhanced radio network temporary identifier E-RNTI, channelization codes and/or signature sequences for those downlink channels, and the like, and such resources are limited for any particular base station. The SRNC14informs the MS10of these downlink configuration parameters (e.g., signature sequence, channelization codes, E-RNTI assigned to the MS10to identify it on these downlink channels) received from the BS12in order that the MS10can store the parameters and monitor those downlink channels. Each of those downlink channels are used in support of the E-DCH and may be considered to schedule the E-DCH, which is dedicated to the MS10for uplink data. Typically, these downlink parameters as well as those for the uplink E-DCH are sent to the MS10in one or more Physical Channel Configuration messages, as known in the art, though the manner in which the initial setup of an E-DCH may vary. These teachings are directed toward the downlink channels associated with and in support of the uplink E-DCH, and related aspects of those downlink channels.

Now the MS10moves to a second position31′, and the second BS212′ becomes the serving Node B following the serving cell change, and the E-DCH36for the MS10is maintained through the serving cell change. A serving cell change may be accomplished in any number of ways known in the art, and may include coordinating between the first Node B BS112and the second Node B BS212′. The specific instance illustrated inFIG. 4finds the RNC14releasing the E-AGCH used by the first Node B BS112and configuring a new E-AGCH for the second Node B BS212′, which may be done to change a E-AGCH for the same MS10when that MS undergoes a serving cell change from the first BS112to the second BS212′ Specifically, the SRNC14sends a request38to the first Node B BS112to release the E-AGCH, and also sends a request38′ to the second Node B BS212′ to configure a new E-AGCH. Each of those Node Bs respond40as appropriate. In an embodiment, the requests38,38′ may be a radio link reconfiguration prepare message, and the response40is a radio link reconfiguration ready message with the newly introduced E-RGCH release indicator as noted above with respect toFIGS. 2-3. The E-RGCH release indicator or similar information element may also be included in a physical channel reconfiguration message sent to the UE. WhileFIG. 4illustrates releasing the E-AGCH in one cell and configuring a new one in another cell, the E-RGCH can also be reconfigured with similar signaling between the BS.12,12′ and the MS10, in some embodiments also informing the SRNC14of any changes made to release, configure, or reconfigure the E-AGCH and/or the E-HICH, shown particularly atFIGS. 5-6. In the prior art, the second Node B that becomes the serving Node B would have to use the E-AGCH and E-RGCH that was used in the Node B that was serving prior to the serving cell change because there was no provision to release, change, or add any of those downlink channels after the E-DCH was setup; changes could only be made by terminating the E-DCH. Given that the radio resources used for that channel E-RGCH are limited, the E-RNTI, signature sequence or channelization codes allocated upon setup of the E-DCH may not be optimal for the second Node B (BS212′), which may use more or less downlink channel that supports the E-DCH (E-AGCH, E-HICH, E-AGCH) than the first Node B (BS112).

For a change to the E-AGCH, the SRNC14informs the MS10, such as in a Physical Channel Reconfiguration message, that the first E-AGCH32is released and a second E-AGCH32′ is to be used. Upon receipt of this reconfiguration message, the MS10deletes its previously stored parameters for the first E-AGCH32and stores those received either of the Node B's (BS112, BS212′) for the second E-AGCH32′. Similar changes may be made to the E-RGCH and the E-HICH, though those changes are typically initiated by the Node Bs rather than the SRNC14. The physical channel reconfiguration message sent to the MS10may include a field such as the E-RGCH release indicator illustrated inFIGS. 2-3that informs the MS10that the previous E-RGCH34is released, as well as new parameters for the new E-RGCH34′. Since the MS10then no longer has need for the parameters (channelization coding and signature sequence) for the now-released E-RGCH34that was used with the first Node B BS112, it deletes those parameters from any local memory in which they are stored. The radio resources for the now-released E-RGCH34may then be re-allocated by the network (the first Node B, BS1inFIG. 4) for other uses.

The two different Node B's12,12′ may be under the control of different RNCs without departing from these teachings. Where the serving cell change uses soft techniques in which the cells12,12′ coordinate among each other prior to control of the MS10actually being changed, signaling as detailed above may be done by the non-serving Node B BS112, the serving Node B BS212′, or by some combination of them so that the eventual release, configuration, or reconfiguration of the E-RGCH takes place upon the serving cell change or soon before or after control passes. These same procedures apply equally to reconfiguring the E-HICH, where the MS10sends its automatic repeat requests on the reconfigured E-HICH37′ and the original E-HICH37that was set up with the E-DCH36is released so that the first Node B BS112might use those now-released radio resources for other purposes.

FIG. 5illustrates a process diagram for various exemplary embodiments of the invention. As stated above, there are instances where the Node B that becomes the non-serving Node B from serving Node B. As an initial starting position at block502, assume that the MS10is under control of a serving Node B that becomes a non-serving Node B after a serving cell change. The E-DCH is supported by at least the E-AGCH and the E-HICH; alternatives for the E-RGCH are detailed below. The serving cell change is initiated at block504when the serving Node B receives a request (from the SRNC) for a serving cell change. For the case506where the E-RGCH is already configured, the serving Node B may decide to release the E-RGCH508, reconfigure the E-RGCH510such as from dedicated to common, or retain the current configuration of the E-RGCH unchanged512. For the case514where the E-RGCH is not configured prior to the serving cell change, the serving Node B may decide to retain the current configuration of the E-RGCH unchanged512or to configure an E-RGCH516. At block518the SRNC14is informed of the decision, and the serving cell change is then executed where the serving Node B described inFIG. 5becomes the non-serving Node B.

FIG. 6illustrates process steps in accordance with exemplary embodiments of the invention where the downlink channel E-RGCH that support the uplink E-DCH is either released or reconfigured (or kept unchanged) while the E-DCH is maintained for the MS10.FIG. 6is the complement toFIG. 5, in thatFIG. 6illustrates what may occur at the non-serving Node B that becomes the serving Node B after the serving cell change. As an initial starting point forFIG. 6, block602shows that the non-serving Node B supports the MS10(user equipment UE) uplink E-DCH with the downlink E-HICH. At some point the non-serving Node B receives a request604from the SRNC to become a serving Node B to the UE. For the case606where the E-RGCH is already configured prior to the serving cell change, the non-serving Node B may decide to release the E-RGCH608, reconfigure the E-RGCH610such as from common to dedicated, or to retain the current configuration of the E-RGCH unchanged612. For the case614where the E-RGCH is not configured prior to the serving cell change, the non-serving Node B may decide to retain the current configuration of the E-RGCH unchanged612or to configure a new E-RGCH616. At block618the SRNC14is informed of the decision, and the serving cell change is then executed where the non-serving Node B described inFIG. 6then becomes the serving Node B.

Note that the actions ofFIG. 5may be coordinated with the actions ofFIG. 6for a smoother serving cell change, but they need not be. For example, theFIG. 6non-serving Node B that becomes the serving Node B may not have the E-RGCH, and decide to configure a new one. TheFIG. 5serving Node B that becomes the non-serving Node B may not know until after the serving cell change occurs that the E-RGCH it was using previously is no longer needed, and only then release it. Many other such variances are possible becauseFIGS. 5 and 6are not necessarily linked, though in some embodiments the actions of the serving and non-serving Node Bs are coordinated for efficient deployment of radio resources without delay. As such, the release/configuration/reconfiguration of the described channels described as taking place at a serving cell change need not occur exactly simultaneous with the instant when control over the UE changes, but may occur soon before or after that control change occurs and still be “at a serving cell change”.

Based on the foregoing it should be apparent that the exemplary embodiments of this invention provide a method, apparatus and computer program product(s) to provide enhanced Node B/RNC signaling that enables the release of unnecessary E-RGCH resources (advantageously when the E-DCH RL Serving cell change is executed), and to further enable the configuration and reconfiguration of E-RGCH/HICH resources (in certain embodiments when an E-DCH RL Serving cell change is executed).

Various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications of the teachings of this invention will still fall within the scope of the non-limiting embodiments of this invention.