Abstract:
User equipment (UE) can detect a Radio Link Control (RLC) unrecoverable error and a Radio Link (RL) failure. The two errors are handled differently while the UE is in a dedicated channel (DCH) state. The RL failure leads to execution of Radio Access Bearer (RAB) release steps, characterized by utilizing respective timer values to determine if associated RABs should be released. The RLC unrecoverable error is not permitted to execute the RAB release steps. This prevents unnecessary dropping of services. The UTRAN can optionally include and set the indicators to command the UE to perform the indicated RLC re-establishmentprocedure.

Description:
CROSS REFERENCE To RELATED APPLICATIONS  
       [0001]     This application claims the benefit of U.S. Provisional Application No. 60/319,465, filed Aug. 13, 2002, and included herein by reference. 
     
    
     BACKGROUND OF INVENTION  
       [0002]     1. Field of the Invention  
         [0003]     The present invention relates to a wireless communications device. More particularly, the present invention relates to discriminating between the handling of a layer  2  unrecoverable error and a layer  1  radio link failure.  
         [0004]     2. Description of the Prior Art  
         [0005]     The 3rd Generation Partnership Project (3GPP) specifications 3GPP TS 25.331 V3.11.0 (2002-06) “Radio Resource Control (RRC) Protocol Specification” and 3GPP TS 25.322 V3.11.0 (2002-06) “Radio Link Control (RLC) protocol specification”, both of which are included herein by reference, provide technical description of a Universal Mobile Telecommunications System (UMTS). The UMTS discloses a device (typically a mobile device), termed user equipment (UE), in wireless communications with one or more base stations. These base stations (so-called Node Bs) with Radio Network Controllers (RNCs) are collectively termed the UMTS Terrestrial Radio Access Network, or UTRAN for short.  
         [0006]     Please refer to  FIG. 1 .  FIG. 1  is a simple block diagram of a 3GPP wireless communications network  10 . The wireless communications network  10  comprises a plurality of radio network subsystems (RNSs)  20  in communications with a core network (CN)  30 . The CN  30  includes a packet switch (PS) domain  30   p  and a circuit switch (CS) domain  30   c.  The plurality of RNSs  20  form a UTRAN  20   u.  Each RNS  20  comprises one RNC  22  that is in communications with a plurality of Node Bs  24 . Each Node B  24  is a transceiver, which is adapted to send and receive wireless signals, and which defines a cell region. A number of cells (i.e., a number of Node Bs  24 ) taken together defines a UTRAN Registration Area (URA). In particular, the wireless communications network  10  assigns a UE  40  to a particular RNS  20 , which is then termed the serving RNS (SRNS)  20   s  of the UE  40 . Data destined for the UE  40  is sent by the CN  30  (or UTRAN  20   u ) to the SRNS  20   s.  It is convenient to think of this data as being sent in the form of one or more packets that have a specific data structure, and which travel along one of a plurality of radio bearers (RBs)  28 ,  48 . An RB  48  established on the UE  40  will have a corresponding RB  28  established on the UE SRNS  20   s.  The RBs are numbered consecutively, from RB 0  to RBn. Typically, RB 0  to RB 4  are dedicated signaling RBs (SRBs), which are used for passing protocol signals between the UTRAN  20   u  and the UE  40 , and will be described in some more detail below. RBs  28 ,  48  greater than four (i.e., RB 5 , RB 6 , etc.) are typically used to carry user data. The RNC  22  utilizes a Node B  24 , which may be assigned to the UE  40  by way of a Cell Update procedure, to transmit data to, and receive data from, the UE  40 . The Cell Update procedure is initiated by the UE  40  to change a cell as defined by a Node B  24 . Selection of a new cell region will depend, for example, upon the location of the UE  40  within the domain of the SRNS  20   s.  The UE  40  sends data to the wireless communications network  10 , which is then picked up by the SRNS  20   s  and forwarded to the CN  30 . Occasionally, the UE  40  may move close to the domain of another RNS  20 , which is termed a drift RNS (DRNS)  20   d.  A Node B  24  of the DRNS  20   d  may pick up the signal transmitted by the UE  40 . The RNC  22  of the DRNS  20   d  forwards the received signal to the SRNS  20   s.  The SRNS  20   s  uses this forwarded signal from the DRNS  20   d,  plus the corresponding signals from its own Node Bs  24  to generate a combined signal that is then decoded and finally processed into packet data. The SRNS  20   s  then forwards the received data to the CN  30 . Consequently, all communications between the UE  40  and the CN  30  must pass through the SRNS  20   s.    
         [0007]     Please refer to  FIG. 2  in conjunction with  FIG. 1 .  FIG. 2  is a simple block diagram of a UMTS radio interface protocol architecture, as used by the communications network  10 . Communications between the UE  40  and the UTRAN  20   u  is effected through a multi-layered communications protocol that includes a layer  1 , a layer  2  and a layer  3 , which together provide transport for a signaling plane (C-plane)  92  and a user plane (U-plane)  94 . Layer  1  is the physical layer  60 , and in the UTRAN  20   u  is responsible for combining signals received from the DRNS  20   d  and SRNS  20   s.  Layer  2  includes a packet data convergence protocol (PDCP) layer  70 , a Radio Link Control (RLC) layer  72 , and a Medium Access Control (MAC) layer  74 . Layer  3  includes a Radio Resource Control (RRC) layer  80 . The U-plane  94  handles user data transport between the UE  40  and the UTRAN  20   u  (RBs  28 ,  48  from five and upwards), whereas the C-plane  92  handles transport for signaling data between the UE  40  and the UTRAN  20   u  (RBs  28 ,  48  from zero to four). The RRC  80  sets up and configures all RBs  28 ,  48  between the UTRAN  20   u  and the UE  40 . The PDCP layer  22  provides header compression for Service Data Units (SDUs) received from the U-plane  94 . The RLC layer  72  provides segmentation of PDCP  70  SDUs and RRC  80  SDUs into RLC protocol data units (PDUs). The RLC layer  72  is composed of one or more RLC entities  76 . Each RLC entity  76  is individually associated with an RB  28 ,  48 . For an RB  28  on the UTRAN  20   u  side, there exists an RLC entity  76  dedicated solely to that RB  28 . For the same RB  48  on the UE  40  side, there similarly exists a corresponding RLC entity  76 . These two corresponding RLC entities  76  for the same RB  28 ,  48  are termed “RLC peer entities”. Under acknowledged mode (AM) transfers, the RLC layer  72  can provide upper layers (such as the PDCP layer  70  or the RRC layer  80 ) with a confirmation that RLC PDUs have been successfully transmitted and received between the RLC peer entities  76  on the UTRAN  20   u  and the UE  40 . The MAC layer  74  provides scheduling and multiplexing of RLC PDUs onto the transport channel, interfacing with the physical layer  60 .  
         [0008]     Please refer to  FIG. 3  with reference to  FIG. 1  and  FIG. 2 .  FIG. 3  is a state diagram of the RRC layer  80 . The RRC layer  80  has two primary states: an idle mode  81  and a UTRA RRC Connected Mode  86 . While in idle mode, the RRC layer  80  has no lines of communication open with its peer RRC layer  80 . That is, there are no available SRBs  28 ,  48  that enable communications between peer entity RRC layers  80 , except for RB 0 , which is a common channel available to all UEs  40  in the UTRAN  20   u.  Utilizing the UE  40  as an example platform, once the RRC layer  80  of the UE  40  establishes a connection (i.e., SRBs  28 ,  48  from one to four) with its peer RRC layer  80  on the UTRAN  20   u,  the RRC layer  80  of the UE  40  switches into the UTRA RRC Connected Mode  86 . This connection is typically initiated along RB 0 , which is a shared channel. Internally, the UTRA RRC Connected Mode  86  has four unique states: CELL_DCH  82 , CELL_FACH  83 , CELL_PCH  84  and URA_PCH  85 . The CELL_DCH state  82  is characterized in that a dedicated channel is allocated to the UE  40  for uplink (UE  40  to UTRAN  20   u ) and downlink (UTRAN  20   u  to UE  40 ) communications. The CELL_FACH state  83  is characterized in that no dedicated channel is allocated to the UE  40 , but instead the UE  40  is assigned a default common or shared transport channel for uplink. The CELL_PCH state  84  is characterized in that no dedicated physical channel is allocated to the UE  40 , no uplink activity is possible for the UE  40 , and the position of the UE  40  is known by the UTRAN  20   u  on a cell level (i.e., a node B basis  24 ). The URA_PCH state  85  is characterized in that no dedicated physical channel is allocated to the UE  40 , no uplink activity is possible for the UE  40 , and the position of the UE  40  is known by the UTRAN  20   u  on a URA basis.  
         [0009]     A number of reconfiguration procedures are available to the RRC layer  80  to setup and configure RBs  28 ,  48 . These procedures involve the UTRAN  20   u  sending a specific message to the UE  40  along an RB  28 ,  48  in the C-plane  92 , and the UE  40  responding in turn with a corresponding message, also along the C-plane  92 . Typically, the message is sent along RB 2 . The messages include Radio Bearer Setup, Radio Bearer Reconfiguration, Radio Bearer Release, Transport Channel Reconfiguration and Physical Channel Reconfiguration, as indicated in the above-indicated 3GPP specification TS 25.331, subclause 8.2.2. For each of these reconfiguration messages, the UE  40  has a corresponding “Complete” or “Failure” response message indicating success or failure of the procedure on the UE  40  side, and which may provide the UTRAN  20   u  any necessary information for the UTRAN  20   u  to complete the procedure. The reconfiguration message and the response message may all carry optional information elements (IEs), which are fields of data that hold ancillary information. In addition to these reconfiguration procedures, there also exists a Cell Update procedure, which originates with a Cell Update message from the UE  40  and which is responded to by the UTRAN  20   u.  The Cell Update procedure is used by the UE  40  to indicate a change of cell location (i.e., Node B  24 ), of connection state  82 ,  83 ,  84 ,  85 , and is also used to indicate radio link (RL) failures and RLC unrecoverable errors. An RL failure is a connection failure that occurs in the physical layer, i.e., in layer  1   60 . An RLC unrecoverable error occurs in the RLC layer  72 , and may have many causes.  
         [0010]     For AM connections, when a sender RLC entity  76  detects one of the following situations, it shall senda RESET PDU to its peer RLC entity  76  to reset these two RLC peer entities  76 :  
         [0011]     1)“No_Discard after MaxDAT number of retransmissions” is configured and VT(DAT) equals the value MaxDAT (see subclause 9.7.3.4 of TS 25.322);  
         [0012]     2)VT(MRW) equals the value MaxMRW;  
         [0013]     3)A STATUS PDU including “erroneous Sequence Number” is received (see clause 10 of TS 25.322);  
         [0014]     stop transmitting any AMD PDU or STATUS PDU;  
         [0015]     increment VT(RST) by 1;  
         [0016]     if VT(RST)=MaxRST:  
         [0017]     the Sender may submit to the lower layer a RESET PDU;  
         [0018]     perform the actions specified in subclause 11.4.4a of TS 25.322.  
         [0019]     else (if VT(RST)&lt;MaxRST):  
         [0020]     submit a RESET PDU to the lower layer;  
         [0021]     start the timer Timer_RST.  
         [0022]     Please refer to subclause 11.4 of the above-indicated 3GPP specification TS 25.322 for more details. When the maximum number of attempts to send a RESET PDU is reached, the sender RLC entity  76  shall terminate the on-going RLC RESET procedure and indicate an unrecoverable error to the upper layer (RRC layer  80 ).Whenthe RRC layer  80  receives the indicated unrecoverable error from the AM RLC entity  76 , the UE  40  shall perform a Cell Update procedure using the cause “RLC unrecoverable error”, i.e. the UE  40  shall send a CELL UPDATE message with an IE “AM_RLC error indication (RB 2 , RB 3  or RB 4 )” or “AM_RLC error indication (RB&gt;4)” set to “TRUE” to indicate the RLC unrecoverable errorhasoccurred in control plane  92  or in the user plane  94 . Please refer to TS 25.331, subclause 8.3.1 for more details of the Cell Update procedure, which is discussed briefly in the following.  
         [0023]     For an RLC unrecoverable error in the user plane  94 , after reception of a CELL UPDATE/URA UPDATE message from UE  40 , the UTRAN 20   u  should optionally include the IE “RLC re-establish indicator (RB 5  and upwards)” in the CELL UPDATE CONFIRM message to request an RLC re-establishment procedure in the UE  40 , in which case the corresponding RLC entities  76  should also be re-established in UTRAN  20   u.    
         [0024]     For an RLC unrecoverable error in the control plane  92 , after reception of a CELL UPDATE/URA UPDATE message from UE  40 , the UTRAN 20   u  should optionally include the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” in the CELL UPDATE CONFIRM message to request an RLC re-establishment procedure in the UE  40 , in which case the corresponding RLC entities  76  should also be re-established in UTRAN  20   u,  or initiate an RRC connection release procedure by transmitting an RRC CONNECTION RELEASE message on the downlink CCCH.  
         [0025]     If an RL failure or an RLC unrecoverable errortakes place on a dedicated channel (i.e. the RRC layer  80  is in the CELL_DCH state  82 ), before sending a CELL UPDATE message, the UE  40  shouldperform radio access bearer (RAB) release steps, and then select a suitable cell  24 . The RAB release steps release the RABs for which the associated timer T 314 /T 315  is equal to zero.A RAB can comprise one or more RBs, but normally there is a one-to-one relationship between RABs and RBs. While performing the RLC re-establishment procedure, if eithertimer T 314  or T 315  expires, the UE  40  should also release the RABs associated with the expired timer. Instructions as given by subclause 8.3.1.2 of TS 25.331, as relates to the above, are provided below. All subclauses indicated in the steps below are from TS 25.331.  
         [0026]     When initiating the URA update or cell update procedure, the UE shall:  
         [0027]     1&gt;stop timer T 305 ;  
         [0028]     1&gt;if the UE isin CELL_DCH state:  
         [0029]     2&gt;Perform RAB release steps;  
         [0030]     1&gt;set the variables PROTOCOL_ERROR_INDICATOR, FAILURE_INDICATOR, UNSUPPORTED_CONFIGURATION and INVALID_CONFIGURATION to FALSE;  
         [0031]     1&gt;set the variable CELL_UPDATE_STARTED to TRUE;  
         [0032]     1&gt;if the UE is not already in CELL_FACH state:  
         [0033]     2&gt;move to CELL_FACH state;  
         [0034]     2&gt;select PRACH according to subclause 8.5.17;  
         [0035]     2&gt;select Secondary CCPCH according to subclause 8.5.19;  
         [0036]     2&gt;use the transport format set given in system information as specified in subclause 8.6.5.1.  
         [0037]     1&gt;if the UE performs cell re-selection:  
         [0038]     2&gt;clear the variable C_RNTI; and  
         [0039]     2&gt;stop using that C_RNTI just cleared from the variable C_RNTI in MAC.  
         [0040]     1&gt;set CFN in relation to SFN of current cell according to subclause 8.5.15;  
         [0041]     1&gt;in case of a cell update procedure:  
         [0042]     2&gt;set the contents of the CELL UPDATE message according to subclause 8.3.1.3;  
         [0043]     2&gt;submit the CELL UPDATE message for transmission on the uplink CCCH.  
         [0044]     1&gt;in case of a URA update procedure:  
         [0045]     2&gt;set the contents of the URA UPDATE message according to subclause 8.3.1.3;  
         [0046]     2&gt;submit the URA UPDATE message for transmission on the uplink CCCH.  
         [0047]     1&gt;set counter V 302  to 1;  
         [0048]     1&gt;start timer T 302  when the MAC layer indicates success or failure in transmitting the message.  
         [0049]     The prior art RAB release steps are given below. Again, subclauses mentioned in the steps below are from TS 25.331.  
         [0050]     For the RAB release steps, the UE shall:  
         [0051]     2&gt;in the variable RB_TIMER_INDICATOR, set the IE “T 314  expired” and the IE “T 315  expired” to FALSE;  
         [0052]     2&gt;if the stored values of the timer T 314  and timer T 315  are both equal to zero; or  
         [0053]     2&gt;if the stored value of the timer T 314  is equal to zero and there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT 315 ”:  
         [0054]     3&gt;release all its radio resources;  
         [0055]     3&gt;indicate release (abort) of the established signalling connections (as stored in the variable ESTABLISHED_SIGNALLING_CONNECTIONS) and established radio access bearers (as stored in the variable ESTABLISHED_RABS) to upper layers;  
         [0056]     3&gt;clear the variable ESTABLISHED_SIGNALLING_CONNECTIONS;  
         [0057]     3&gt;clear the variable ESTABLISHED_RABS;  
         [0058]     3&gt;enter idle mode;  
         [0059]     3&gt;perform other actions when entering idle mode from connected mode as specified in subclause 8.5.2;  
         [0060]     3&gt;and the procedure ends.  
         [0061]     2&gt;if the stored value of the timer T 314  is equal to zero:  
         [0062]     3&gt;release all radio bearers, associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT 3   14 ”;  
         [0063]     3&gt;in the variable RB_TIMER_INDICATOR set the IE “T 314  expired” to TRUE.  
         [0064]     2&gt;if the stored value of the timer T 315  is equal to zero:  
         [0065]     3&gt;release all radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT 315 ”;  
         [0066]     3&gt;in the variable RB_TIMER_INDICATOR set the IE “T 315  expired” to TRUE.  
         [0067]     2&gt;if the stored value of the timer T 314  is greater than zero:  
         [0068]     3&gt;if there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT 314 ”:  
         [0069]     4&gt;start timer T 314 .  
         [0070]     3&gt;if there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT 314 ” or “useT 315 ”:  
         [0071]     4&gt;start timer T 314 .  
         [0072]     2&gt;if the stored value of the timer T 315  is greater than zero:  
         [0073]     3&gt;if there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT 315 ”:  
         [0074]     4&gt;start timer T 315 .  
         [0075]     2&gt;for the released radio bearer(s):  
         [0076]     3&gt;delete the information about the radio bearer from the variable ESTABLISHED_RABS;  
         [0077]     3&gt;when all radio bearers belonging to the same radio access bearer have been released:  
         [0078]     4&gt;indicate local end release of the radio access bearer to upper layers using the CN domain identity together with the RAB identity stored in the variable ESTABLISHED_RABS;  
         [0079]     4&gt;delete all information about the radio access bearer from the variable ESTABLISHED_RABS.  
         [0080]     2&gt;select a suitable UTRA cell according to [4];  
         [0081]     2&gt;set the variable ORDERED_RECONFIGURATION to FALSE.  
         [0082]     For example, if the stored value of the timer T 314  is equal to zero and the stored value of the timer T 315  is greater than zero, then the UE  40  shouldrelease locally all radio bearers  48  which are associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT 314 ”, andstart timer T 315 . If timer T 315  expires, the UE  40  should also release locally all radio bearers  48  which are associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “use T 315 ”, and enter idle mode  81 .  
         [0083]     The prior art UE 40 , as detailed in TS 25.331, subclause 8.3.1.2, treats the cases of both RL failure and RLC unrecoverable error while the RRC  80  is in theCELL_DCH state  82  inthe same manner. That is, both error conditions while in the CELL_DCH state  82  will lead to the execution of the RAB release steps. However, RL failures and RLC unrecoverable errors have some essential differences.For example,an RLC unrecoverable error can be potentially “fixed” by returning to initial conditions by way of an RLC re-establishment procedure.An RL failure cannot, however, be “fixed” by a re-establishment procedure, as it is fundamentally a physical problem with the radio connection. Therefore, the usage of the timers T 314  and T 315  for RLC unrecoverable errors(as performed by the RAB release steps) on a dedicated channel is unwarranted, and may lead to some normally-functioning RABs (i.e. services or applications) being released before the RLC is re-established if the timers T 314 /T 315  are shorter than the time required to perform the RLC re-establishment procedure.  
         [0084]     By way of example, consider the situation in which the UE  40  is in the CELL_DCH state  82 , and has U-plane  94  RABs  6  to  10  that comprise RBs  48   6  to  10  with a one-to-one mapping. Furtherassume that the timer T 314  is set to zero seconds, and that the timer T 315  is set to 10 seconds, and that all RABs except RABs  6  and  7  are associated with T 314 . If an RLC unrecoverable error occurs only on RB  6 , the UE  40  sends a CELL UPDATE message with the IE “AM_RLC error indication (RB&gt;4)” set to “TRUE” to the UTRAN  20   u.  The UTRAN  20   u  responds with a CELL UPDATE CONFIRM message that includes the IE “RLC re-establish indicator (RB 5  and upwards)” to request a RLC re-establishment for all RABs  6  to  10  in the UE  40 . The RABs  8 , 9  and  10  (i.e. RB  8 , 9  and  10 ) that are running correctly will be released before re-establishment is completed, since the timer T 314  (at zero seconds) is shorter than the time required to perform the RLC re-establishment procedure. The malfunctioning RB  6  (i.e. RAB  6 )is restored to operational order after performing the RLC re-establishment procedure, but the correctly functioning RBs  8 , 9  and  10  (i.e. RABs  8 , 9 , 10 ) are released before performing the RLC re-establishment procedure. The unnecessary release of correctly functioning RABs (i.e. services or applications) by the RAB release steps leads to areduction in the radio utilization capacity, and increases the services drop rate, which is a great inconvenience to the user of the UE  40 .  
         [0085]     Finally, according to subclause 8.3.1.6 of TS 25.331, the UE  40  shall handle both the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” and IE “RLC re-establish indicator (RB 5  and upwards)” if received in the CELL UPDATE CONFIRM message. However, according to subclause 8.3.1.5 of TS 25.331, the UTRAN  20   u  may only include the IE “RLC re-establish indicator (RB 5  and upwards)” in the CELL UP-DATE CONFIRM message. Hence, the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” is actually a useless procedural indicator, as it is impossible to be included in the CELL UPDATE CONFIRM message by the UTRAN  20   u.    
       SUMMARY OF INVENTION  
       [0086]     It is therefore a primary objective of this invention to provide an improved method for handling an unrecoverable error on a dedicated channel so as to avoid the above-indicated problems.  
         [0087]     In a preferred embodiment, the present invention discloses a method, and associated wireless device, for handling an unrecoverable error on a dedicated channel. Briefly, if it is determined that the wireless device is in the CELL_DCH state and that a layer one radio link failure has occurred, improved radio access bearer (RAB) release steps are performed to release radio bearers. However, if it is determined that the wireless device is in the CELL_DCH state and that layer one radio link failure has not occurred, the RAB release steps are not performed.  
         [0088]     Additionally, the present invention method explicitly permits the UTRAN to transmit a CELL UPDATE CONFIRM message to the UE that contains the information element (IE) “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )”.  
         [0089]     It is an advantage of the present invention that by performing the RAB release steps only when a layer one radio link failure is detected on the dedicated channel, unnecessary releasing of RABs is avoided, and thus theunnecessary dropping of services if avoided. By avoiding use of the timer T 314  and T 315  for RLC unrecoverable errors, the UE is ensured to be provided enough time to re-establish the RLC connections, and thus restore services with dropping the RABs.  
         [0090]     It is yet another advantage of the present invention that the UTRAN may explicitly include the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” in the CELL UPDATE CONFIRM message sent to the UE, and hence give relevance to the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” initially transmitted by the UE to the UTRAN.  
         [0091]     These and other objectives of the present invention will no doubt become obvious to those of ordinary skill in the art after reading the following detailed description of the preferred embodiment, which is illustrated in the various figures and drawings. 
     
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0092]      FIG. 1  is a simple block diagram of a wireless communications system.  
         [0093]      FIG. 2  is a simple block diagram of a UMTS radio interface protocol architecture.  
         [0094]      FIG. 3  is a state diagram of a Radio Resource Control (RRC) RRC layer shown in  FIG. 2 .  
         [0095]      FIG. 4  is a block diagram of a wireless device according to the present invention.  
         [0096]      FIG. 5  is a flowchart for determining how the UE of  FIG. 4  performs a cell or URA update procedure according to the present invention.  
         [0097]      FIG. 6  is a flowchart of a present invention procedure that the UTRAN of  FIG. 1  executes after receiving a CELL UP-DATE or URA UPDATE message. 
     
    
     DETAILED DESCRIPTION  
       [0098]     In the following description, user equipment (UE) is a wireless communications device, and may be a mobile telephone, a handheld transceiver, a personal data assistant (PDA), a computer, or any other device that requires a wireless exchange of data. It is assumed that this wireless exchange of data conforms to 3GPP-specified protocols.  
         [0099]     Please refer to  FIG. 4 .  FIG. 4  is a block diagram of a user equipment (UE)  100  according to the present invention. In most respects, the present invention UE  100  is identical to a UE of the prior art. The UE  100  includes devices for accepting input and providing output, such as a keypad  102  and a liquid crystal display (LCD)  104 , respectively. A transceiver  108  is capable of receiving wireless signals and providing corresponding data to a control circuit  106 , and can also wirelessly transmit data received from the control circuit  106 . The transceiver  108  is thus part of the 3GPP layer  1  stack  60  of the present invention communications protocol. The control circuitry  106  is responsible for controlling the operations of the UE  100 , and is used to implement the layer  2  and layer  3  stacks of the 3GPP communications protocol; in particular, for implementing the RRC layer  80 , with suitable modifications to accommodate the present invention improvements. To this end, the control circuitry  106  includes a central processing unit (CPU)  106   c  in electrical communication with memory  106   m,  an arrangement familiar to those in the art of wireless communication devices. The memory  106   m  holds program code  107  that is used to implement the layer  2  and layer  3  stacks of the present invention communications protocol. With respect to a UE of the prior art, the present invention UE  100  has modifications to the program code  107  to implement the present invention method, providing modifications to the program code  107  that relate to the RRC layer  80  so as to implement the present invention improvements. These modifications should be well within the means of one reasonably skilled in the art after reading the following detailed description of the preferred embodiment.  
         [0100]     When an RLC unrecoverable error occurs (as detected by the RLC layer  72 ) on a dedicated channel (i.e. the RRC layer  80  is in the CELL_DCH state  82 ), the UE  100  does not check to see if timer T 314   109   a  or timer T 315   109   b  is zero to release the associated RABs.That is, the RAB release steps are not called in response to an RLC unrecoverable error while the UE  100  is in the CELL_DCH state  82 . Hence, the timers T 314   109   a  and T 315   109   b  are only used for RL failure (as detected by the layer  1  interface  60  of the transceiver  108 ), and are not used for RLC unrecoverable errors (as detected by the RLC layer  72 ) on a dedicated channel.  
         [0101]     When a cell update procedure is to be performed, the present invention further alters the conditions under which the RAB release steps are performed. The following details the improved steps of the present invention method (as implemented by program code  107 ) that determine how the UE  100  performs a cell update procedure or URA update procedure.  
         [0102]     Referring to the flowchart  200  of  FIG. 5 , when initiating the URA update or cell update procedure, the UE shall:  
         [0103]     1&gt;stop timer T 305 ;  
         [0104]     1&gt;if the UE isin CELL_DCH state; and  
         [0105]     1&gt;if the cause that triggers this procedure is due to “radio link failure”:  
         [0106]     2&gt;perform improved RAB release steps;  
         [0107]     1&gt;set the variables PROTOCOL_ERROR_INDICATOR, FAILURE_INDICATOR, UNSUPPORTED_CONFIGURATION and INVALID_CONFIGURATION to FALSE;  
         [0108]     1&gt;set the variable CELL_UPDATE_STARTED to TRUE;  
         [0109]     1&gt;if the UE is not already in CELL_FACH state:  
         [0110]     2&gt;move to CELL_FACH state;  
         [0111]     2&gt;select PRACH according to subclause 8.5.17;  
         [0112]     2&gt;select Secondary CCPCH according to subclause 8.5.19;  
         [0113]     2&gt;use the transport format set given in system information as specified in subclause 8.6.5.1.  
         [0114]     1&gt;if the UE performs cell re-selection:  
         [0115]     2&gt;clear the variable C_RNTI; and  
         [0116]     2&gt;stop using that C_RNTI just cleared from the variable C_RNTI in MAC.  
         [0117]     1&gt;set CFN in relation to SFN of current cell according to subclause 8.5.15;  
         [0118]     1&gt;in case of a cell update procedure:  
         [0119]     2&gt;set the contents of the CELL UPDATE message according to subclause 8.3.1.3;  
         [0120]     2&gt;submit the CELL UPDATE message for transmission on the uplink CCCH.  
         [0121]     1&gt;in case of a URA update procedure:  
         [0122]     2&gt;set the contents of the URA UPDATE message according to subclause 8.3.1.3;  
         [0123]     2&gt;submit the URA UPDATE message for transmission on the uplink CCCH.  
         [0124]     1&gt;set counter V 302  to 1;  
         [0125]     1&gt;start timer T 302  when the MAC layer indicates success or failure in transmitting the message.  
         [0126]     Subclauses mentioned in the steps above are identical to those in the prior art, and refer to TS 25.331. Hence, for the sake of brevity, the details of those steps contained within the above-mentioned subclauses is omitted. Note that the present invention cell update/URA update procedural steps now ensure that the RAB release steps are performed only if (1) the UE  100  is in the CELL_DCH state  82 ; and (2) the cause that triggers the cell update/URA update procedure is due to “radio link failure”. Hence, with the present invention procedure, as implemented by the program code  107 , only a “radio link failure” type error can cause the execution of the RAB release steps. In particular, then, an “RLC unrecoverable error” type cause for performing the present invention cell update/URA up-date procedure cannot and does not lead to the execution of the RAB release steps.  
         [0127]     To ensure that the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” is functionally relevant and useful procedural indicator, the present invention augments the procedure steps taken by the UTRAN  20   u  when the UTRAN  20   u  receives a CELL UPDATE/URA UPDATE message. The steps are detailed below and illustrated in the flowchart  300  of  FIG. 6 , and correspond to the prior art steps detailed in TS 25.331 subclause 8.3.1.5.  
         [0128]     When the UTRAN receives a CELL UPDATE/URA UPDATE message, the UTRAN should:  
         [0129]     1&gt;in case the procedure was triggered by reception of a CELL UPDATE:  
         [0130]     2&gt;if SRNS relocation was performed:  
         [0131]     3&gt;transmit a CELL UPDATE CONFIRM message on the downlink DCCH.  
         [0132]     2&gt;otherwise:  
         [0133]     3&gt;update the START value for each CN domain as maintained in UTRAN with “START” in the IE “START list” for the CN domain as indicated by “CN domain identity” in the IE “START list”;  
         [0134]     3&gt;if this procedure was triggered while the UE was not in CELL_DCH state, then for each CN domain as indicated by “CN domain identity” in the IE “START list”:  
         [0135]     4&gt;set the 20 MSB of the MAC-d HFN with the corresponding START value in the IE “START list”;  
         [0136]     4&gt;set the remaining LSB of the MAC-d HFN to zero.  
         [0137]     3&gt;transmit a CELL UPDATE CONFIRM message on the downlink DCCH or optionally on the CCCH but only if ciphering is not required; and  
         [0138]     3&gt;optionally include the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” and the IE “RLC re-establish indicator (RB 5  and upwards)” to request a RLC re-establishment in the UE, in which case the corresponding RLC entities should also be re-established in UTRAN; or  
         [0139]     1&gt;in case the procedure was triggered by reception of a URA UPDATE:  
         [0140]     2&gt;if SRNS relocation was performed:  
         [0141]     3&gt;transmit a URA UPDATE CONFIRM message on the downlink DCCH.  
         [0142]     2&gt;otherwise:  
         [0143]     3&gt;transmit a URA UPDATE CONFIRM message on the downlink CCCH or DCCH.  
         [0144]     2&gt;include the IE “URA identity” in the URA UPDATE CONFIRM message in a cell where multiple URA identifiers are broadcast; or  
         [0145]     1&gt;initiate an RRC connection release procedure by transmitting an RRC CONNECTION RELEASE message on the downlink CCCH. In particular UTRAN should:  
         [0146]     2&gt;if the CELL UPDATE message was sent because of an unrecoverable error in RB 2 , RB 3  or RB 4 :  
         [0147]     3&gt;initiate an RRC connection release procedure by transmitting an RRC CONNECTION RELEASE message on the downlink CCCH.  
         [0148]     The UTRAN may transmit several CELL UPDATE CONFIRM/URA UPDATE CONFIRM messages to increase the probability of proper reception of the message by the UE. In such a case, the RRC SN for these repeated messages should be the same.  
         [0149]     With regard to the steps above, it should be noted that the present invention steps enable the UTRAN to optionally include the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” and/or the IE “RLC re-establish indicator (RB 5  and upwards)” to request a RLC re-establishment in the UE. In contrast, the prior art permitted only the IE “RLC re-establish indicator (RB 5  and upwards)”.  
         [0150]     In contrast to the prior art, the present invention prevents the RAB release steps from being performed when an RLC unrecoverable error is detected while the UE is in the CELL_DCH state. Additionally, UTRAN may explicitly include the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” in the CELL UPDATE CONFIRM message sent to the UE, and hence give relevance to the IE “RLC re-establish indicator (RB 2 , RB 3  and RB 4 )” initially transmitted by the UE to the UTRAN in the CELL UPDATE message.  
         [0151]     Those skilled in the art will readily observe that numerous modifications and alterations of the device may be made while retaining the teachings of the invention. Accordingly, the above disclosure should be construed as limited only by the metes and bounds of the appended claims.