2.9.

2 3G-2G INTER-RAT HANDOVER FOR CS AND PS SERVICES

If the UE is moving and there is no other UTRAN cell offering sufficient quality for handover of
an intra-frequency or inter-frequency type a neighbor GSM cell might be the best solution for
handover. Basically inter-RAT relocation/handover is the same procedure as explained before
with some minor, but decisive differences as illustrated in Figure 2.37.

Figure 2.37 Abstract steps of CS inter-RAT handover 3G-2G

2.9.2.1 CS 3G-2G Inter-RAT Handover

The measurement report event-ID that triggers inter-RAT handover from UTRAN to GSM is
3A: ‘The estimated quality of the currently used UTRAN frequency is below a certain threshold
and the estimated quality of the other system is above a certain threshold’.

Handover message request (2) is once again seen as an RANAP Relocation Preparation message
on IuCS, but this time a different container is embedded. Instead of the sourceRNC-to-
targetRNC-transparent-container we find a protocol sequence named oldBSS-to-newBSS-
information. This sequence contains handover-relevant information encoded in BSSMAP format
and is necessary to construct the BSSMAP Handover Request sent by the MSC to the target
BSC.

In this scenario the target BSC has substituted the target RNC. The interface between the MSC
and target BSC is the A-interface, the interface between the target cell and the target BSC is
Abis.
After handover message request (2) is received in the target BSC this network element will
construct a DTAP Handover Command message (3) that is sent back to the SRNC and forwarded
by the SRNC to the UE embedded in the RRC Handover from UTRAN to the GSM command.
On IuCS interfaces the same DTAP message was previously transported embedded in
TargetRNC-to-SourceRNC-Transparent-Container. In other words, if the source RNC sends
handover information to the target BSC it uses BSSMAP, the way of expression on the BSC/A-
interface, while on the other hand if the target BSC sends handover-related information to the
source RNC it uses RANAP, the RNC/IuCS way of expression. Due to this a prerequisite of such
a kind of handover is a software update on the BSC side as well, because standard 2G BSC
software does not offer such functionality.

Whether the UE switched to the GSM cell can be detected on the GSM Abis interface. The radio
signaling link (RSL) protocol will send a Handover Detect message to the BSC that indicates
that the cell has been able to establish radio contact with the UE. This RSL Handover Detect is
the handover complete message (4). Similar to 3G-3G hard handover scenarios described in the
previous section the reception of this message in the BSC triggers a feedback mechanism and the
reception of this feedback information on the MSC will trigger the RANAP Iu-Release
procedure (cause: ‘successful relocation’) on the IuCS inter- face and subsequently the release of
all radio and transport network resources of this particular connection in UTRAN.
Protocol events:
• CS-iRAT-HO_Attempt: RANAP Relocation Required containing oldBSS-to-
newBSS- Information.
• CS-iRAT-HO_Success: RANAP Iu-Release (cause ¼ ‘successful relocation’)
monitored for the same RANAP connection as CS-iRAT-HO_Attempt. RANAP
messages monitored on a single Iu interface belonging to the same connection are bound
by a unique pair of SCCP Source Local Reference & Destination Local Reference
numbers.

There must be three different failure cases taken into account for failure events. For this reason
three different failure events are introduced in this section.

CS-iRAT-HO_Failure_1: RANAP Relocation Cancel message. If the traffic channel can- not be
established on all involved interfaces of the GSM/EDGE radio access network (GERAN) this
will be indicated by Relocation Preparation Failure (ASN.1 encoded: RANAP
UnsuccessfulOutcome, Procedure Code ¼ ‘Relocation Preparation’). For root cause analysis it is
recommended to check the probably embedded Inter-System Information Transparent Container
or cause values such as ‘no radio resource available in target cell’. After receiving Relocation
Preparation Failure it is always up to the SRNC to decide if the relocation procedure will be
cancelled. If the SRNC decides to cancel, the RANAP Relocation Cancel message is monitored.

If RANAP Relocation Preparation Failure is received by the SRNC in some cases (e.g. cause
value ¼ ‘semantic error’) another Relocation Required message will be sent immediately to the
MSC. If this attempt fails again another Relocation Required is sent and so on. There is an
indefinite number of CS-iRAT-HO_Attempt for a single connection in such cases. It must be
defined that a failed relocation preparation procedure is only detected if in the end no relocation
preparation procedure has been finished successfully. Also, if Successful Outcome of Relocation
Preparation is seen after 30 or 40 unsuccessful attempts and it has taken more than 30 seconds to
finally get Successful Outcome the relocation procedure must be counted as successful. If
possible a separate root cause analysis can be done as follows: compare the target ID information
element of Relocation Required messages for which SuccessfulOutcome was monitored with the
target ID of Relocation Required messages for which UnsuccessfulOutcome has been seen.
Using this method we can identify target cells (or their BSCs) that need to be trouble-shot
(possible root cause: their soft- ware is not able to interact with required RANAP protocol
versions). Figure 2.38 shows a typical message example that can be used for this kind of trouble-
shooting. The target ID highlighted in the message parameters identifies the target cell uniquely.
The trace sequence in the upper part of the figure (Short View pane) shows that the target system
cannot react to the required relocation because of ‘semantic error’.

Figure 2.38 RANAP relocation preparation failure trace

CS-iRAT-HO_Failure_2: the second failure event is the RRC Handover from UTRAN Failure
message that can be measured on Iub if the RRC handover procedure fails.

CS-iRAT-HO_Failure_3: the third possibility of a failure indication is once again the case that
the UE loses contact with the radio network during the handover procedure and we see NBAP
Radio Link Failure without having seen a CS-iRAT-HO_SUCCESS event or Hand- over
Complete message on the GERAN Abis interface (if the performance measurement unit is able
to monitor GERAN interfaces and call trace application features combined with
UTRAN/GERAN monitoring).

Formulas:
P CS-IRAT -HO Success
• CS-IRAT-HO Success Rate % = ------------------------------------ * 100%
P CS-IRAT -HO Attempt
 P CS-IRAT -HO Failure
• CS-IRAT-HO Failure Rate % = ------------------------------------ * 100%
P CS-IRAT -HO Attempt

2.9.2.2 PS 3G-2G Inter-RAT Handover

The main difference between CS inter-RAT handover and PS inter-RAT handover from UTRAN
to GSM is that for the PS handover version no RANAP Relocation procedure is executed as
shown in Figure 2.39.

The handover trigger event is again RRC event-ID 3A (after a number of 2D events have been
reported, which have triggered the activation of inter-RAT measurement on RRC level). Instead
of starting a relocation, the SRNC immediately sends an RRC CellChangeOrder-fromUTRAN
message to the UE once a neighbor GSM cell has been measured to offer sufficient radio quality
for taking over the active connection.

The reason why there is no relocation performed is that there is no dedicated traffic channel for
IP payload on GERAN interfaces Gb and Abis. Instead so-called temporary blocks are monitored
on Abis whenever IP payload needs to be transmitted between the UE and the network.
Protocol events:
• PS-iRAT-HO_Attempt: RRC CellChangeOrderfromUTRAN message.
• PS-iRAT-HO_Success: RANAP Iu-Release (cause: ‘release-due-to-UTRAN-
generated-reason’).

Figure 2.39 PS inter-RAT handover 3G-2G

• PS-iRAT-HO_Failure: if handover fails the RRC Cell Change Orderfrom UTRA N

Failure message is monitored or the already well-known scenario of NBAP Radio Link
Failure Indication without having seen Success event.

Formulas for Success and Failure Ratio can be constructed in the same way as demon- strated in
inter-frequency handover analysis.