You are on page 1of 5

Cell Update

This document is a reference to Cell update procedure. Reason for which MS can initiate Cell Update Procedure: -Cell_DCH State: Cause: Reason: Cause: Reason: Radio Link failure Loss of L1 synchronization RLC unrecoverable error. To notify RLC unrecoverable error.

-Cell_FACH or Cell_PCH State: Cause: Cell reselection Reason: UE has entered in to a new cell. Cause: Reason: Cause: Reason: -Cell_PCH State: Cause: Reason: Cause: Reason: UL data request To indicate that MS wants to send UL data. Paging Response To answer to the RRC: Paging type 1 message received from RNC Periodic Cell Update Periodic Cell Update based on SIB information. Re-entering Service area Accessing services after an out of coverage situation.

Points to Consider: 1.RRC: Cell Update message is always send on CCCH channel. 2. RRC: Cell Update message contains U-RNTI and Cell Update Cause. 3.If the MS is in Cell_PCH State, first make the transition to Cell_FACH State. 4. MS may send consecutive Cell Update messages when a different criterion is met 5. All cause values (except the RLC unrecoverable error) are interpreted as a valid paging response for the UTRAN originated paging.

Handing of Cell Update request based on Cell Update Cause: A. Cell update due to cell reselection: If the cell update cause in RRC: CELL UPDATE message is cell reselection then the RRC entity updates the MS location information and (re) starts Cell_FACH or Cell_PCH state supervision timer, PeriodicCellURAupdWait. Point to Consider: When a cell update is received from the MS, the RRC entity shall first check the status of the MSActivitySupervision timer. If the MSActivitySupervision has expired the release of the resources of this MS (Iu Release Request procedure due to user inactivity) is initiated. After the new C-RNTI is allocated, the RRC entity informs it to the MAC-c entity of a new cell and also requests the MAC-c entity of the previous cell (if existing) to release the old C-RNTI. Also the U-RNTI is informed by RRC entity to MAC-c entity. It is also indicated that the MAC-c must use U-RNTI while sending RRC:CELL UPDATE CONFIRM message. As a response to RRC:CELL UPDATE message the RRC entity sends an RRC:CELL UPDATE CONFIRM message on DCCH to the MS. If the MS has been in Cell_FACH state and/or it shall remain in this state, the RRC:CELL UPDATE CONFIRM message shall contain a new C-RNTI. In this case the MS configures layer 2 to use the new identities and returns an RRC:UTRAN MOBILITY INFORMATION CONFIRM message as a response.
MS BTS MS is in CELL_FACH or CELL_PCH state RRC:CELL UPDATE [Cause: Cell Reselection] RRC:CELL UPDATE CONFIRM MS kept in Cell_FACH: [RRC state: Cell_FACH; New C-RNTI] MS moved from Cell_FACH: [RRC state: Cell/URA_PCH] RRC:UTRAN MOBILITY INFORMATION CONFIRM If updating of the UL traffic volume measurement threshold is needed RRC:MEASUREMENT CONTROL [Traf.Vol.Meas.] RNC

Cell Update due to cell reselection

B. Cell update due to periodical cell update Periodic Cell Update in Cell_PCH state:
If the cell update cause in RRC:CELL UPDATE message is periodic cell update, the RRC entity updates the MS location information and if the MS is in Cell_PCH state, resets the Cell_PCH state supervision timer, PeriodicCellURAupdateWait (see Error: Reference source not found). If the timer MSActivitySupervision has expired when the Cell Update message is received from the MS, the RRC entity initiates the Iu release request procedure towards the PS-CN (CN is informed about the user inactivity). The CN may ignore the initiated Iu release without sending a response to the RNC. In this case the Iu connection remains, a state transition from Cell_FACH state to Cell_PCH state is initiated and the timer MSActivitySupervision shall be restarted If a response to the Iu release request is received from the CN, the Iu connection is released and a RRC Connection Release procedure is initiated. After this the MS transfers to the Idle Mode.

Periodic Cell Update in Cell_FACH state: In practice the time, which an inactive MS is allowed to stay in Cell_FACH state will be much shorter than the interval for periodic updates, and thus the reception of the periodic Cell Update in Cell_FACH state can be considered as a failure situation or an exception case. If however, a periodic Cell Update in Cell_FACH state is received, the MS is immediately moved to the Cell_PCH state if allowed.
MS BTS RNC

MS is in CELL_FACH or CELL_PCH state

RRC:CELL UPDATE [Cause: Periodical Cell Update] RRC:CELL UPDATE CONFIRM [RRC state: Cell/URA_PCH]

C. Cell update due to radio link failure If the cell update cause in RRC: CELL UPDATE message is Radio link failure, the RRC entity updates the MS location and state information (from Cell_DCH to Cell_FACH).

D. Cell update due to UL data transmission If the cell update cause in RRC: CELL UPDATE message is UL data transmission, the RRC entity forwards this information to the PS. As a response to RRC: CELL UPDATE message the RRC entity sends an RRC: CELL UPDATE CONFIRM message on DCCH to the MS. The RRC: CELL UPDATE CONFIRM message may include a new C-RNTI (and/or U-RNTI after the SRNS relocation procedure). In this case the MS configures layer 2 to use the new identities and returns an RRC: UTRAN MOBILITY INFORMATION CONFIRM message as a response. The MS shall remain in Cell_FACH state and in case the MS is assigned a new CRNTI and/or U-RNTI (S-RNTI plus SRNC identity), an RRC: UTRAN MOBILITY INFORMATION CONFIRM message is sent by the MS to the RRC entity. E. Cell update due to paging response
MS BTS RNC

MS is in CELL_PCH state or URA_PCH state

RRC:PAGING TYPE 1 [U-RNTI] MS moves to CELL_FACH state RRC:CELL UPDATE [Cause: Paging Response] RRC:CELL UPDATE CONFIRM [New C-RNTI] RRC:UTRAN MOBILITY INFORMATION CONFIRM

MS is in CELL_FACH state

NAS signaling sequence or u-plane data flow

If the cell update cause in RRC: CELL UPDATE message is paging response, the RRC entity updates the MS location information. F. Cell update due to re-entering service area If the cell update cause in RRC: CELL UPDATE message is re-entering service area then the RRC entity shall check if a state supervision timer,

PeriodicCellURAupdateWait, is running and stop this timer. After this the possible suspended RRC procedure can be reinitiated. In other case the indication of re-entering service area received from the MS may be collected in statistics (if needed). If the Iu connection for this MS is already released, the RRC Connection release is executed via the CCCH, and the MS is moved to the Idle Mode. G.Cell update due to RLC unrecoverable error If in MS RLC the number of retransmissions of the RLC RESET PDU exceeds the upper limit, the MS shall send a Cell Update message (with a cause value RLC unrecoverable error) to RNC. The MS should indicate in the message whether the unrecoverable error exists in the signaling radio bearer SRB2, SRB3 or SRB4 or in another radio bearer (RB>4). When RRC entity/MCC receives this message, it checks which radio bearer(s) has the unrecoverable error.
If MS is in Cell_FACH state when the unrecoverable error occurs in control and/or user plane RBs, the RRC entity/MCC shall order the MS to re-establish its control/user plane RLC entities accordingly by RRC: CELL UPDATE CONFIRM message. At the same time RNC shall also re-establish its own control plane/user plane RLC entities. RLC Re-establishment is done by sending the RFU control command message with re-establishment info per SRB/RB to RLC entity by RRC entity/MCC.

In case the MS was in Cell_DCH state and the unrecoverable error occurred in control plane RBs while running the HHO or SHO procedures or the unrecoverable error occurred in user plane RB, the handling is as in Cell_FACH state. In any other case the RRC entity/MCC shall initiate the RRC Connection Release procedure. When RRC entity/MCC receives a Cell Update message because of RLC unrecoverable error in SRB2, SRB3 or SRB4, it shall initiate the RRC Connection Release procedure by transmitting RRC: RRC CONNECTION RELEASE message on the downlink CCCH.

You might also like