Protocol Sequence - RRC State Change

This page follows one TD-SCDMA packet call through three RRC state changes. The UE starts in CELL_DCH, goes down to CELL_PCH or URA_PCH when the data stops, and then climbs back through CELL_FACH to CELL_DCH when data comes again. Each step down saves radio resources and UE battery. Each step up costs signalling and delay. So it is worth knowing exactly which messages move the UE, and who decides to send them.

What does the DCH to PCH and back sequence look like ?

The list below is the message order that a test setup shows for this call. Steps 1 to 15 are an ordinary packet call that ends in CELL_DCH. Steps 16 to 27 are the three state changes. Note who starts each one: the network moves the UE down and up between DCH and the other states, but the UE itself starts the move out of PCH.

(1) UE <--> NW : Registration (Combined or Non-Combined)

(2) UE <--> NW : < IDLE >

(3) UE : < Make a MO Packet Call >

(4) UE --> NW : RRC CONNECTION REQUEST

(5) UE <-- NW : RRC CONNECTION SETUP

(6) UE --> NW : RRC CONNECTION SETUP COMPLETE

(7) UE --> NW : GMM SERVICE REQUEST

(8) UE <-- NW : AUTHENTICATION AND CIPHERING REQUEST

(9) UE --> NW : AUTHENTICATION AND CIPHERING RESPONSE

(10) UE <-- NW : SECURITY MODE COMMAND

(11) UE --> NW : SECURITY MODE COMPLETE

(12) UE --> NW : ACTIVATE PDP CONTEXT REQUEST

(13) UE <-- NW : RADIO BEARER SETUP

(14) UE --> NW : RADIO BEARER SETUP COMPLETE

(15) UE <-- NW : ACTIVATE PDP CONTEXT ACCEPT

(16) NW : Trigger for DCH -> PCH transition (e.g, no user data for a certain time period)

(17) UE <-- NW : PHYSICAL CHANNEL RECONFIGURATION

(18) UE --> NW : PHYSICAL CHANNEL RECONFIGURATION COMPLETE

(19) UE <--> NW : < Cell PCH or URA PCH >

(20) UE : Trigger for Cell PCH -> FACH transition (e.g, Request for data transmission)

(21) UE --> NW : CELL UPDATE

(22) UE <-- NW : CELL UPDATE CONFIRM

(23) UE --> NW : UTRAN MOBILITY INFORMATION CONFIRM

(24) UE <--> NW : < Cell FACH >

(25) NW : Trigger for FACH -> DCH transition (e.g, Data rate increase)

(26) UE <-- NW : PHYSICAL CHANNEL RECONFIGURATION

(27) UE --> NW : PHYSICAL CHANNEL RECONFIGURATION COMPLETE

Figure 1 draws the same steps as a state diagram. Each box is an RRC connected state, and each arrow is labelled with the steps and the messages that cause the transition.

Figure 1. RRC state changes on this page. The UE leaves CELL_DCH on a network reconfiguration, returns from PCH on its own cell update, and reaches CELL_DCH again on a second reconfiguration.

The network starts both reconfigurations : PHYSICAL CHANNEL RECONFIGURATION always goes from the network to the UE, and the COMPLETE goes back.
The UE starts the exit from PCH : in CELL_PCH or URA_PCH it normally has no DCCH to receive a reconfiguration on, so it sends CELL UPDATE first.
The RRC connection survives the whole cycle : no RRC CONNECTION REQUEST appears after step 4, and the PDP context stays active.

How does the UE move from CELL_DCH to CELL_PCH ?

A UE in CELL_DCH holds dedicated physical channels even when it has nothing to send. So the network watches the traffic and moves an idle UE to a cheaper state. The trigger in step 16 is typically an inactivity timer in the RNC, and 3GPP leaves its value to the network.

In step 17 the network sends PHYSICAL CHANNEL RECONFIGURATION, and in step 18 the UE answers with PHYSICAL CHANNEL RECONFIGURATION COMPLETE. The target state is not given by the message name. It comes from the IE "RRC State Indicator", which is mandatory in every reconfiguration message. So the network could use RADIO BEARER RECONFIGURATION or TRANSPORT CHANNEL RECONFIGURATION for the same move. The definition of the IE is short.

Following is based on 25.331 v19.0.1 (Release 19)

RRC-StateIndicator ::=          ENUMERATED {
                                        cell-DCH, cell-FACH, cell-PCH, ura-PCH }

With cell-PCH or ura-PCH, the UE releases its dedicated channels but keeps the RRC connection, its U-RNTI and its RABs. The message can also carry a UTRAN DRX cycle length coefficient, which sets how often the UE wakes up for paging. The two PCH states differ in how the UE reports mobility. In CELL_PCH it sends a cell update after each cell reselection. In URA_PCH it sends a URA update only when it leaves its URA, so it signals less when it moves fast. In both states, timer T305 drives a periodic update.

TD-SCDMA adds one detail here. 25.331 subclause 7.2.2.1 allows a 1.28 Mcps TDD UE to receive DCCH and DTCH on the HS-DSCH in CELL_PCH. The UE has to support it, and the cell has to broadcast the HS-DSCH paging information. Otherwise, and always in URA_PCH, the UE has no DCCH and no DTCH in these states.

The RRC State Indicator decides the target state : any of the reconfiguration messages can move the UE to CELL_PCH or URA_PCH.
PCH keeps the connection and drops the channels : the UE stays RRC connected with its U-RNTI, so the way back is faster than a new RRC connection.
URA_PCH signals less than CELL_PCH : the UE reports only a change of URA, not every cell change.

How does the UE come back to CELL_FACH and CELL_DCH ?

In CELL_PCH or URA_PCH the UE normally has no DCCH, so the network cannot send it a reconfiguration. So the way back starts with a CELL UPDATE from the UE. What triggers it depends on which side has data.

In step 20 the UE has uplink data. 25.331 subclause 8.3.1.2 then asks for a cell update with the cause "uplink data transmission". For 1.28 Mcps TDD this rule applies when the variable H_RNTI is not set. If the network has downlink data instead, it pages the UE with PAGING TYPE 1, and the UE uses the cause "paging response". The causes are listed below.

Following is based on 25.331 v19.0.1 (Release 19)

CellUpdateCause ::=                 ENUMERATED {
                                        cellReselection,
                                        periodicalCellUpdate,
                                        uplinkDataTransmission,
                                        utran-pagingResponse,
                                        re-enteredServiceArea,
                                        radiolinkFailure,
                                        rlc-unrecoverableError,
                                        cellUpdateCause-ext }

In step 21 the UE sends CELL UPDATE on the CCCH and moves to CELL_FACH. The network answers with CELL UPDATE CONFIRM in step 22. The reply in step 23 depends on what the CONFIRM carries, as 25.331 subclause 8.3.1.7 specifies. If it carries no RB, transport channel or physical channel information, but for example a new C-RNTI, the UE answers with UTRAN MOBILITY INFORMATION CONFIRM. That is the case on this page, and the UE stays in CELL_FACH. If the CONFIRM carried physical channel information instead, the UE would answer with PHYSICAL CHANNEL RECONFIGURATION COMPLETE.

CELL_FACH suits small amounts of data. When the traffic grows, the network moves the UE back to CELL_DCH in step 25. A common trigger is a traffic volume measurement report, for example event 4A, where the buffer passes an absolute threshold. The network then sends PHYSICAL CHANNEL RECONFIGURATION with the RRC State Indicator set to cell-DCH in step 26. The UE answers with PHYSICAL CHANNEL RECONFIGURATION COMPLETE in step 27, now on the new dedicated channels.

The way out of PCH starts with a cell update : the cause tells the network whether the UE has uplink data or answers a page.
The CONFIRM decides the reply message : a CONFIRM with only a new identity gets UTRAN MOBILITY INFORMATION CONFIRM, and one with channel information gets a reconfiguration COMPLETE.
CELL_FACH is an intermediate step : the network moves the UE on to CELL_DCH only when the traffic needs dedicated channels.

Reference

25.331 v19.0.1 : Radio Resource Control; Protocol specification. Subclauses 7.2.2, 8.2.2, 8.3.1 and 14.4.2.1
RRC State Change : the same state machine on a UMTS network