2.9.2 3G-2G INTER-RAT HANDOVER FOR CS AND PS SERVICES
2.10 STATE TRANSITIONS AND CHANNEL TYPE SWITCHING
When analysing state transitions it must be distinguished between protocol states and virtual states defined in performance measurement software. As already mentioned in the section about performance measurement software architecture in Chapter 1 some measurement equipment manu- facturers have based a large part of their call analysis on state machines. States used by such software are mostly virtual ones, which means that they have not been defined in any inter- national standard document published by 3GPP or other standards organisations. Such virtual states are beyond the scope of this section with one single exception: theHSDPA Activestate.
Due to the fact that there is noHSDPA Activestate defined in 3GPP a virtual state needs to be defined if it is to be analysed when, how often and how long the UE uses HS-DSCH for downlink data transmission.
During call establishment the SRNC sends first RRC state information to the UE embed- ded in the RRC Connection Setup message. Either the UE is ordered to enter CELL_DCH state and use dedicated channels (with parameters transmitted in the same RRC Connection Setup message) for further signalling exchange with the network, or the UE is ordered to enter CELL_FACH state and use common transport channels RACH and FACH for RRC/
NAS signalling transmission. Which option is used depends on the RNC configuration settings and optimisation targets defined for UTRAN.
If further exchanged signalling leads to a radio bearer setup (in currently installed network configurations) this always requires the UE entering CELL_DCH state after request by the SRNC transmitted to the UE using the RRC Radio Bearer Setup Request message shown in message example 2.15.
While speech calls remain in CELL_DCH as long as a call is active the radio bearers of PS data calls are adapted to currently required data transmission rates whenever the SRNC decides that this is necessary. Procedures defined for such dynamical reconfigurations are all RRC reconfiguration procedures: RRC physical channel reconfiguration, RRC transport Message example 2.15RRC radio bearer setup request (RRC StateẳCELL_DCH)
| ID Name | Comment or Value |
| TS 29.331 DCCH-DL (2002-09) (RRC_DCCH_DL) radioBearerSetup (ẳradioBearerSetup) |
| dL-DCCH-Message |
| 2 message |
| 2.1radioBearerSetup |
| 2.1.1 r3 |
| 2.1.1.1 radioBearerSetup-r3 |
| 2.1.1.1.1 rrc-TransactionIdentifier | 0 |
| 2.1.1.1.2rrc-StateIndicator |cell-DCH |
channel reconfiguration and RRC radio bearer reconfiguration. In all these procedures we can monitor RRC state indicators as well as optionally channel mapping options. Sometimes only the spreading factor and transport format sets of DCH are adapted to current needs – as shown in Figure 1.36. Sometimes the type of transport channel which dedicated traffic channels (DTCH) are mapped onto is changed: if IP data volume to be transmitted is expected to be extremely small DTCH is mapped onto common transport channels RACH and FACH. Whenever this happens RRC state is also changed from CELL_DCH to CELL_FACH. Usually the RRC Physical Channel Reconfiguration Request message is used to transmit this state change information, but also the RRC Radio Bearer Reconfigura- tion Request can be used as shown in message example 2.16.
Message example 2.16RRC radio bearer reconfiguration (RRC stateẳCELL_FACH)
| ID Name | Comment or Value |
| TS 29.331 DCCH-DL (2002-09) (RRC_DCCH_DL) radioBearerReconfiguration |
| dL-DCCH-Message |
| 2 message |
| 2.1 radioBearerReconfiguration |
| 2.1.1 r3 |
| 2.1.1.1 radioBearerReconfiguration-r3 |
| 2.1.1.1.1 rrc-TransactionIdentifier | 1 |
| 2.1.1.1.2 activationTime | 80 |
| 2.1.1.1.3 new-C-RNTI | ‘0000000000000001’B |
| 2.1.1.1.4rrc-StateIndicator |cell-FACH |
| 2.1.1.1.5rb-InformationReconfigList |
| 2.1.1.1.5.1 rB-InformationReconfig |
| 2.1.1.1.5.1.1 rb-Identity | 1 |
| 2.1.1.1.5.1.2 rlc-Info |
| 2.1.1.1.5.1.2.1 ul-RLC-Mode |
| 2.1.1.1.5.1.2.1.1 ul-UM-RLC-Mode |
| 2.1.1.1.5.1.2.2 dl-RLC-Mode |
| 2.1.1.1.5.1.2.2.1 dl-UM-RLC-Mode | 0 |
| 2.1.1.1.5.1.3 rb-MappingInfo |
| 2.1.1.1.5.1.3.1 rB-MappingOption |
| 2.1.1.1.5.1.3.1.1 ul-LogicalChannelMappings |
| 2.1.1.1.5.1.3.1.1.1 oneLogicalChannel |
| 2.1.1.1.5.1.3.1.1.1.1ul-TransportChannelType |
| 2.1.1.1.5.1.3.1.1.1.1.1rach | 0 |
| 2.1.1.1.5.1.3.1.1.1.2 logicalChannelIdentity | 1 |
| 2.1.1.1.5.1.3.1.1.1.3 rlc-SizeList |
| 2.1.1.1.5.1.3.1.1.1.3.1 explicitList |
| 2.1.1.1.5.1.3.1.1.1.3.1.1 rLC-SizeInfo |
| 2.1.1.1.5.1.3.1.1.1.3.1.1.1 rlc-SizeIndex | 1 |
| 2.1.1.1.5.1.3.1.1.1.4 mac-LogicalChannelPri.. | 1 |
| 2.1.1.1.5.1.3.1.2 dl-LogicalChannelMappingList |
| 2.1.1.1.5.1.3.1.2.1 dL-LogicalChannelMapping |
| 2.1.1.1.5.1.3.1.2.1.1dl-TransportChannelType |
| 2.1.1.1.5.1.3.1.2.1.1.1fach | 0 |
| 2.1.1.1.5.1.3.1.2.1.2 logicalChannelIdentity | 1 |
In this message example channel mapping options are also highlighted that are used for channel type switching from DCH to RACH/FACH. In a similar way channel type switching of DL transport channel to HS-DSCH can be performed. It happens whenever the downlink transport channel type is HS-DSCH (instead of FACH in the message example above).
However, a prerequisite of using HS-DSCH is that the UE is in CELL_DCH state. Knowing these facts the virtual stateHSDPA Activecan be defined as follows:
HSDPA Active:UE in CELL DCH and active downlink transport channelẳHS-DSCH:
So far it does not seem to be difficult to follow HSDPA activations/deactivations. HSDPA is deactive if the radio bearer/DTCH is mapped onto the downlink dedicated transport channel (DCH) or Forward Access Channel (FACH) again. However, the problem is that radio bearer mapping options are often only transmitted once when the radio bearer is set up or reconfigured for the first time. Then these mapping options are stored in the UE as well as in the SRNC and whenever a change of transport channel mapping is necessary only the transport channel IDs are used to indicate which channel will be used. In message example 2.16 the uplink transport channel ID for RACHẳ‘0’ and the downlink transport channel ID or FACHẳ‘0’ are assigned to this particular connection.
Note: It will be noticed that transport channel IDs used in RRC and NBAP signalling messages belonging to same connection/call may have different values (þ/1) due to different number value ranges defined by 3GPP (for more details refer to Kreher and Ruedebusch, 2005).
In some cases PS radio bearers are also deleted and the UE is sent to RRC CELL_PCH state due to the long period of user inactivity on the user plane. In such cases a message like the one seen in message example 2.17 can be monitored.
Message example 2.17RRC physical channel reconfiguration (RRC stateẳCELL_PCH)
| ID Name | Comment or Value |
| TS 29.331 DCCH-DL (2002-09) (RRC_DCCH_DL) physicalChannelReconfiguration |
| dL-DCCH-Message |
| 2 message |
| 2.1 physicalChannelReconfiguration |
| 2.1.1 r3 |
| 2.1.1.1 physicalChannelReconfiguration-r3 |
| 2.1.1.1.1 rrc-TransactionIdentifier | 0 |
| 2.1.1.1.2rrc-StateIndicator |cell-PCH |
| 2.1.1.1.3 utran-DRX-CycleLengthCoeff | 5 |
| 2.1.1.1.4 frequencyInfo |
| 2.1.1.1.4.1 modeSpecificInfo |
| 2.1.1.1.4.1.1 fdd |
| 2.1.1.1.4.1.1.1 uarfcn-DL | 10761 |
| 2.1.1.1.5 modeSpecificInfo |
| 2.1.1.1.5.1 fdd |
| 2.1.1.1.6 dl-InformationPerRL-List |
| 2.1.1.1.6.1 dL-InformationPerRL |
| 2.1.1.1.6.1.1 modeSpecificInfo |
| 2.1.1.1.6.1.1.1 fdd |
| 2.1.1.1.6.1.1.1.1 primaryCPICH-Info |
| 2.1.1.1.6.1.1.1.1.1primaryScramblingCode |123 |
This message contains not only the RRC state, but also information about the cell which was used by the UE last. If the UE changes this cell due to mobility it needs to perform the RRC Cell Update procedure towards the SRNC (causeẳ‘cell reselection’). If the UE is moving faster it needs to perform many cell updates and if it moves too fast we would see too many cell updates or the network would not be able to complete them successfully. For this reason RRC state URA_PCH was defined: the UE in this state does not need to perform an update each time a cell is changed, only if the UMTS registration area (URA) is changed.
A UMTS registration area (URA) is a cluster of cells. The number of cells belonging to the same URA is not limited by 3GPP standards.
Knowing this background a low RRC Cell Update Success Rate may indicate that state transitions form CELL_PCH to URA_PCH are not always performed when necessary.
Prerequisite: network elements (UE, RNC) support URA_PCH state, which is not guaran- teed especially for equipment brought to market during the early days of UMTS network deployment.
The problem with analysis of the RRC cell update procedure is that there is no defined failure message for this procedure. In some cases the network will react to the Cell Update Request with release of the RRC connection. This happens if RRC state machines on both sides of the connection (UE and RNC) are completely off the track, for instance due to unrecoverable errors in RLC AM transport blocks. However, in most cases it is expected to simply see no answer to the Cell Update Request and the UE will try again and again until timer T307 (see 3GPP 25.331) expires and the UE releases all information of the existing RRC context.
Another problem is that some state transitions reported by RNC statistics to higher level network management systems seem to be impossible when looking at 3GPP definitions. An example is necessary to explain this.
From Figure 2.40 it becomes clear that state transitions from CELL_PCH to CELL_DCH are actually not possible, but RNC statistics report such state transitions. The reason is that 3GPP 25.331 only reflects state transitions on the UE side. If the UE is in CELL_PCH state it is impossible to send any RRC message, because in CELL_PCH the UE can only be paged. To perform a necessary cell update procedure the UE must enter CELL_FACH first before it is able to send the RRC Cell Update Request message on RACH.
UTRARRC Connected Mode
URA_PCH
CELL_DCH CELL_FACH
CELL_PCH
Figure 2.40 RRC states as defined in 3GPP 25.331
The same thing happens if the UE is in CELL_PCH and wants to set up e.g. a voice call again. This means the UE needs to send an RRC Cell Update Request on RACH (causeẳ
‘uplink data transmission’), but to be able to send this message it first needs to move from CELL_PCH state into CELL_FACH state. However, the SRNC is not informed about this UE internal state transition. From the point of view of the SRNC an RRC Cell Update message is received while the UE is still in CELL_PCH state and due to the fact that voice calls require CELL_DCH state the SRNC will order the UE subsequently to enter CELL_DCH state. The appropriate command is embedded in the RRC Cell Update Confirm message sent by the SRNC. This scenario explains why in RNC software and RNC statistics a state transition CELL_PCH to CELL_DCH exists although it does not exist in 3GPP specifications.
Performance measurement software based on Iub protocol analysis can only follow RRC messages and embedded RRC state indicators to detect state transitions. Due to performance reasons such software is also not able to store CELL_PCH state assigned to a number of UEs for a long time. The UE remains in CELL_PCH (or URA_PCH) state as long as the PDP context is active in the SGNS without transmitting either user data or signalling messages.
A PDP context can be active for more than 48 hours without having an active RAB. If performance measurement software stores all connections with active PDP context, but no RAB (and also no message transfer between UE and RNC) active for more than 48 hours, it would need a lot of temporary memory resources that would be blocked for other temporary memory-intensive operations like macro-diversity filtering. For this reason most call trace applications will terminate the context of a call after the UE has been monitored being in CELL_PCH state for a couple of minutes. Also if performance measurement software is turned on at a defined time (maybe after hours or days of being turned off) it cannot retrieve any information from SRNCs about how many UEs in UTRAN are currently in CELL_PCH or URA_PCH state and hence are inactive from the point of view of transport resources.
The only possible solution is to detect the start of new call/connection when RRC Cell Update Request (causeẳ‘uplink data transmission’ or ‘paging response’) is transmitted from the UE to the SRNC.
Now – as discussed – the SRNC still shows RRC CELL_PCH or URA_PCH state for the particular UE when the RRC Cell Update Request message from this UE is received.
By the appropriate Cell Update Confirm message the UE is already ordered to enter CELL_DCH state to be able to start voice calls and at this point of the call different state transitions are very clearly visible. While the UE will transit from CELL_FACH to CELL_DCH after receiving visible Cell Update Confirm message the SRNC has already registered a state transition form CELL_PCH (when visible RNC has received Cell Update from UE) to CELL_DCH (when RNC has constructed command that orders UE to enter CELL_DCH). To put it in a nutshell, if a procedure like RRC cell update is performed for a short time, RRC state machines on the RNC and UE side may not have the same state stored, because it is the nature of state machines that they need outgoing events (sent messages) and incoming events (received messages) to transit from one state to another.