Nsa Application Paper Irat Handover Analysis-Libre

Application Paper: iRAT Handover
Analysis
Introduction
NSA Software allows you to monitor all incoming and outgoing legs of:
3G -> 2G and 2G -> 3G iRAT handovers for CS services

3G -> 2.5G iRAT cell changes for PS services (combined RAU / LAU)
all 2.5G -> 3G iRAT cell changes for PS services (combined RAU /
LAU) except for Gs interfaces
NSA Software Version 4.00 does not support yet:
Network Assisted Cell Change (NACC) for PS services

PS cell changes in A/Gb mode for PS services
Combined RAU/LAU via Gs
About This Document

This Application Paper covers the following topics:
An introduction about intersystem handovers and cell changes

iRAT Handover Analysis
Troubleshooting iRAT HO Using Dashboard KPIs
How to find an iRAT handover and cell change in the NSA Call Table
9-Dec-13, Page 1

Analysis
Evolution of Intersystem Cell Changes since 3GPP R6

In current network configurations there is no real handover of PS services from
GERAN to UTRAN or vice versa. The main reason is that there is not
dedicated traffic channel for PS data in the GSM network. PS data is sent on
Abis and Um interface in unidirectional temporary block flows whenever the
packet control unit in close cooperation with the base station controller (BSC)
detects that some radio resources are not occupied by CS services and hence,
are available to transport PS data. This is the big difference between 2.5G
GPRS and UMTS: if in UMTS the RNC assigns radio resources for a 64 kbps
PS radio bearer this 64 kbps bandwidth on the RLC transport channel layer is
guaranteed to be available for the particular UE as long as the spreading factor
of the channelization code is not changed. In 2.5 G GPRS there is no reserved
bandwidth for a single PS connection. If e.g. all time slots in a cell are used for
speech connections the user of a PS service needs to wait until one of the time
slots in the GSM cell is released. And if there are several PS service users
they all need to share this single time slot to transmit their data. A flow control
mechanism established in PCU and SGSN side prevents overflow of buffers in
BSSGP entities that may otherwise occur as a result of short PS transmission
resources.
The situation is changing due to the GERAN evolution. Starting with Rel. 6, the
2G SGSN is equipped with a packet flow management. A packet flow context
will be associated with the PDP context. This packet flow context can be seen
as the GERAN equivalent of the RAB. The main purpose of this enhancement
is to minimize the cell change delay of GPRS cell changes including changes
from 3G to 2/2.5G and vice versa. The duration of a 3G-2/2.5G inter-RAT cell
change from Rel. 99 UTRAN to GERAN often takes up to 10 seconds. During
this time, no IP payload is transmitted. If a Gs interface is available between
SGSN and VLR the combined location area update/routing area update
procedure, that is mandatory for each inter-RAT cell change, can be
accelerated. The delay can be reduced to approximately four seconds. A
further minimization of the cell change delay (< 3 seconds) is possible using
the network assisted cell change procedure introduced in Rel. 5. In this
scenario, the UE is able to acquire 2/2.5G system information while still
9-Dec-13, Page 2

connected to the 3G system. Finally, using the Rel. 6 PS cell change
procedures it is expected to reduce the interruption of data transfer to less than
0.5 seconds, which can be called a seamless cell change.
The following examples will explain some standard procedures of inter-RAT
cell changes from UMTS to GSM and vice versa.
3G-2G Inter-RAT Handover for CS Services
Step 1: This procedure is triggered by an RRC Measurement Report

coming from the UE. An event from event-ID group e3 (intersystem
measurement) will be sent.
Step 2: The RANAP Relocation Required message is sent from the

SRNC to its 3G MSC. It includes information about source and target of
the cell change.
Step 3: From the target information in the RANAP Relocation Required

message, the 3G MSC detects that the new desired cell is a GSM cell.
Hence, it is necessary to send a BSSMAP Handover Request message
to the target BSC. This BSSMAP Handover Request is part of a MAP
Prepare Handover operation.
Step 4: The BSSMAP Handover Request message is forwarded

transparently by the 2G MSC to the target BSC.
Step 5: The target BSC allocates radio resources, especially a time slot
for the connection, in the target cell. The signaling of this procedure
can be monitored on the Abis interface.
Figure 1. Overview of an inter-3G-2G cell change
Step 6: After successful resource allocation via Abis, the BSC

constructs a DTAP Handover Command that is sent to the UE via the E
9-Dec-13, Page 3

interface and later UTRAN. The 2G MSC receives a BSSMAP
Handover Request Acknowledge message that contains the DTAP
Handover Command.
Step 7: The MAP Prepare Handover Acknowledge message is used to

transfer the DTAP Handover Command via the E interface.
Step 8: The 3G MSC orders a relocation of SRNC and forwards the

DTAP Handover Command via IuCS.
Step 9: The RRC entity of the SRNC sends an intersystem Handover

Command including the DTAP Handover Command to the UE.
Step 10: Based on the information found in the DTAP Handover

Command the UE enters the GSM cell.
9-Dec-13, Page 4

3G-2.5G Inter-RAT Cell Change for PS Services
If a UE has an active PS RAB in UMTS, its mobility is controlled by the SRNC.
The compressed mode measurement will be activated if the radio conditions in
the currently used frequency are not sufficient anymore to guarantee the
required QoS. If the UE is able to find a GSM cell that offers a sufficient radio
quality, it will send an appropriate RRC Measurement Report message to the
SRNC as shown in the figure below. This measurement report contains as a
rule the event ID 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." The identifier of the measured GSM cell
is its Base Station Identity Code (BSIC). The same BSIC is found together with
an indicator of the used GSM frequency band and the ARFCN, which indicates
the frequency used to transmit the GSM cells broadcast channel in the RRC
Cell Change Order from UTRAN Command message sent by the SRNC. This
message orders the UE to leave the UMTS part of the network and register in
the 2.5G areas. Since there is no dedicated traffic channel for PS data in the
GERAN it is not possible to execute a relocation procedure as in case of CS
cell changes.
System information broadcasted in the target GSM cell tells the UE if a
combined routing area update/location area update is possible or not. In other
words: if there is a Gs interface between SGSN and VLR available or not. In
the example call flow in the figure below, the Gs interface exists. But the
current NSA software version does not support intersystem cell changes on Gs
interfaces yet.
9-Dec-13, Page 5
According to this information, the UE sends a Routing Area Update Request

message that contains the update type "combined RAU/LAU procedure"
together with old RAI and old LAI as well as currently used user temporary
identities TMSI and P-TMSI. Based on the update type, the SGSN is able to
handle the query of the VLR. For this reason, it sends BSSAP+ Location
Update Request message to the VLR and receives BSSAP+ Location Update
Accept including the new LAI and a new TMSI. These two parameters are
stored in SGSN until the routing area update procedure is completed.
Figure 2. Message flow of 3G-2.5G PS Cell Change
9-Dec-13, Page 6

In the next step, the 2.5G SGSN sends a GTP SGSN Context Request to the
3G SGSN that previously served this UE.
The 3G SGSN then sends RANAP SRNS Context Request to the SRNC and
SRNC answers with RANAP SRNS Context Response (not shown in the
figure). In case the 2G and 3G SGSN are just software entities running on the
same physical network node the GTP and RANAP procedure will be handled
by primitives inside the network node and no GTP/RANAP messages will be
seen on Gn/Gp and IuPS interfaces.
Using the GTP SGSN Context Response message the 3G SGSN transmits all
parameters, that important for the particular PDP context of the UE, to the
2.5G SGSN. Now, the PDP context can be continued in the new PS core
network node. The reception of the context parameters is acknowledged.
When the 3G SGSN received the acknowledgement, it can send a RANAP
Forward SRNS Data Command to the former SRNC. Then, the downlink IP
data, that was stored in the RNC RLC buffer related to the connection, can
optionally be forwarded to the 2.5G SGSN to prevent data loss, excessive TCP
retransmissions, and long cell change delay.
When the first packet of IP data is ready to be sent by 2.5G SGSN, the Routing
Area Update Accept message is sent including new temporary identities for the
PS and CS domain services and new routing area information (RAI) as well as
new location area information (LAI) to be stored in the UE's USIM. After this
step, the PS cell change that must be actually rather seen as a registration
procedure including optional data forwarding, is completed.
9-Dec-13, Page 7

2/2.5G - 3G Inter-RAT Cell Reselection
The cell change of an UE, that has an active PDP context in 2/2.5G and is
going to move to 3G, is even simpler as shown in the following figure. Based
on the received measurement results, the BSC will decide that a cell
reselection to 3G is advisable because of the better radio quality. On the Abis
interface (not shown in the figure), a cell reselection order command is sent to
the UE and a BSSGP Radio Status message will indicate the event on behalf
of the appropriate cause value "cell reselection ordered".
The UE performs a cell reselection procedure as specified in 3GPP 25.304.
Then, it requests to establish an RRC connection. The establishment cause in
the RRC Connection Request message is "inter-RAT cell reselection". This
RRC connection is used to register to the 3G core network domains. UE and
SGSN perform the combined Routing Area Update procedure for this purpose
if the Gs interface is available. Otherwise, separate Location Area Updates and
Routing Area Updates will be performed.
Figure 3. Message flow of 2.5G-3G Inter-RAT Cell Reselection for PS Service
Typically, there is no IP data to be transmitted and the RRC connection used

for registration is released. When later the user wants to exchange the IP
payload, a new RRC connection is requested (this time e.g. "originating
background call"). In this new radio connection, you can find a Service
Request message that contains the information that on a defined NSAPI a PDP
context is already active. To service this existing PDP context, an RAB and the
appropriate radio bearer are established. Now, the IP payload can be sent/
received by the network and UE using the UMTS radio interface.
9-Dec-13, Page 8

2G-3G CS inter-RAT Handover on Iub and Iu interface
This section allows a closer look at messages and parameters used on the Iub
and IuCS interface during the CS inter-RAT handover procedure from GSM to
UTRAN. Although the procedure in general was well specified, GSM to UTRAN
CS cell changes have not been monitored for a quite long time after launch of
UMTS networks. The reason was, that the handover command message sent
via the GSM radio interface (Um) must fit into a single LAPDm frame, because
neither LAPDm transport protocol nor the GSM radio resource management
layer (as a rule represented by a proprietary radio signalling link protocol) offer
a segmentation/reassembly function. As a result, the 260 bit information field
of a LAPDm frame is the maximum length of a handover message plus the
necessary radio resource header in GSM. An RRC Handover to UTRAN
Command message, that includes all necessary settings for radio bearers,
transport channel mapping, and physical channel information, would not fit into
a single LAPDm frame. For this reason, 3GPP developed so-called default
configurations. These default configurations are stored in the UE as well as in
RNC software. They allow transmitting minimized handover messages and
parameter lists. A complete overview of possible default configuration settings
can be found in 3GPP 25.331 (RRC).
The call flow of a CS inter-RAT Handover on Iub and IuCS starts with a
RANAP Relocation Request message sent from 3G MSC to the RNC.
Figure 4. Call flow of a 2G-3G CS inter-RAT cell change
Following the ASN.1 terminology, the message is encoded as Initiating

Message of Relocation Resource Allocation procedure. This name is not
9-Dec-13, Page 9

shown in the figure. The message often contains the IMSI, but this is not a
mandatory parameter.
However, the RANAP Common ID message is missed in the cell change
procedure, so to transmit the true subscriber identity to the future SRNC using
the Relocation Request message seems to be an option to close this gap. The
relocation cause indicates that this is a time-critical relocation. The relocation
type is "UE involved", which means that cell change and relocation
(assignment of a new SRNC) are done in one step. The next information
element is the target cell ID. This is the target cell ID as used in NBAP
combined with the RNC-ID found e.g. in RRC messages. Then, a RAB Setup
List follows. This RAB Setup List is similar to the one used during the RAB
Assignment procedure to establish a RAB initially. All RABs established and
released due to relocation/cell change procedures must be taken into account
to compute the correct number of simultaneous active connections in one
UTRAN that it is a prerequisite to compute meaningful call drop rates. In
addition to the RAB-ID, the Relocation Request message contains necessary
QoS RAB parameters, as well as the RAB sub-flow parameters that determine
the QoS of single radio bearers serving the same RAB. In the RAB sub-flow
parameters of this speech RAB, you can already find the transport block sizes
for transport channels used to carry AMR A, B and C bits across the Iub and
Uu.
Part of the Relocation Request message is the source-RNC-to-target-RNCtransparent-container that is filled with UE radio access capability information
for GSM and portion of cell change information. The cell change information is
divided into two major parts: UMTS security information including ciphering
start values and UE radio access capabilities for UMTS. Receiving this
information allows the RNC to ensure a seamless encryption of control plane
and user plane information during and after the cell change. In addition, the
RNC knows what the UE supports regarding measurement procedures,
transport channels (i.e. HS-DSCH, E-DCH), modulation schemes (QPSK,
16QAM), and so on.
The reception of the RANAP Relocation Request message by the RNC triggers
a NBAP Radio Link Setup procedure on the Iub interface. Here we find for the
first time the UL scrambling code with the reduced scrambling code number.
The uplink channelization code length that is identical with the UL spreading
factor is 64 as expected for a AMR 12.2 kbps call. DCH 31 shall carry the
signaling radio bearers (RRC information) while DCHs 8, 9 and 10 will
transport RLC blocks with AMR A, B and C bits. The radio link (RL-ID=0) is set
up in cell with NBAP c-ID=9685 as already signaled in the RANAP Relocation
9-Dec-13, Page 10

Request message.
The NBAP Radio Link Setup Response indicates that the radio link setup was
successful. Now the cell's receiver is waiting to receive the UE's uplink radio
signal using the specified UL scrambling code.
After successful radio link setup on Iub, the RNC sends the RANAP Relocation
Request Acknowledge message that also confirms successful establishment of
RAB with RAB-ID=1 and contains the RRC Handover to UTRAN Command
message embedded in a container. Here, the u-RNTI, that contains the
temporary s-RNTI-2, is found as well as the default configuration ID=3, that
refers to predefined settings of a 12.2 speech RAB combined with a 3.4 kbps
signaling RABs. Uplink scrambling code and uplink spreading factor are the
same as seen before in NBAP. The primary scrambling code of the UTRAN
cell is 139. And on the downlink a spreading factor 128 is used. The number of
the DL spreading code is 5. In addition to the code information the frequency
information of the cell is signaled using uplink and downlink UMTS Absolute
Radio Frequency Channel Number (uARFCN). This is a mandatory parameter
in case that there is more than one UMTS frequency used in the UTRAN,
because primary scrambling codes (only 512 of them are available) might be
the same event, if cells using different frequency directly overlap. Having
uARNFC, PSC and UL scrambling code and downlink channelization code the
UE know all necessary physical parameters to find the ready-to-use radio link
in the target cell.
The RRC Handover to UTRAN Command message is sent via Um (GSM radio)
interface to the mobile that now performs the cell change itself.
When the UL radio signal of the UE is finally received by the cell, the Node B
sends NBAP Radio Link Restore Indication for the specified radio link set as
shown in the figure below. The reception of this NBAP message by the RNC
triggers the transmission of the RANAP Relocation Detect message on the
IuCS interface.
Once the UE is able to use to preconfigured radio bearers of the default
configuration, it sends an RRC Handover to UTRAN Complete message to its
new SRNC. This message contains the new start value for ciphering and
integrity protection. After reception of Handover to UTRAN Complete message,
the cell change itself is successfully finished. This fact is signaled to the MSC
using the RANAP Relocation Complete message. The default configuration
parameters as well as temporary s-RNTI-2 and short UL scrambling code are
in use until now. These parameters shall be used only temporarily and need to
be replaced.
9-Dec-13, Page 11

The first step into this direction is an RRC UTRAN Mobility Information
message sent by the SRNC. It contains a new u-RNTI including a full length sRNTI.
In addition, this message also contains a long list of all possible connection
timer and constants. Many of them are used to guard acknowledged RRC
procedures. When a UE connection is set up in the UTRAN, initially this kind of
information is read before connection setup on the broadcast channel, but
during time-critical cell change procedures there is no time to read the BCH.
For this reason the parameters need to be explicitly signaled to the UE.
The RRC UTRAN Mobility Information procedure is an acknowledged RRC

procedure confirmed by the UE. When the RRC UTRAN Mobility Information
Confirm message is monitored, the new settings have been activated, but still
some temporary parameters are in use. For this reason, a new NBAP
Synchronized Radio Link Reconfiguration Preparation procedure is executed
that contains new physical channel parameters that correspond to the
parameters transmitted in the following RRC Radio Bearer Reconfiguration
message form SRNC to UE.
9-Dec-13, Page 12

In the RRC Radio Bearer Reconfiguration message the radio bearers used in
the default configuration are now mapped onto the appropriate DCH. This is
done to have an alignment in transport channel numbering between RNC and
UE. Now, after the numbering is aligned, some of the DCHs are deleted. A
new full length uplink scrambling code (UL SC) is assigned to the connection
that is still active in the cell with primary scrambling code = xyz.
NOTE: The change of the UL scrambling code is another hard handover that leads
to a very short interruption of data transfer. This short interruption is caused by the
fact that the UE and cell need a few milliseconds to synchronize on the Uu
interface after the code change.
The Radio Bearer Reconfiguration message is answered with a Radio Bearer
Reconfiguration Complete sent by the UE.
Now, another NBAP Synchronized Radio Link Reconfiguration Preparation
procedure follows to prepare the setup of the specific radio bearer that is the
used for low priority NAS signalling, e.g. short messages.
The setup of this new radio bearer (new compared to default settings where
only three signalling radio bearer have been established) is indicated to the UE
using a RRC Radio Bearer Setup message. It contains the new radio bearer
ID, channel mapping options for this RB that is mapped onto the mentioned
DCH. All relevant RLC parameters are the same as for the radio bearer, that is
also indicated using this signalling message. With RRC Radio Bearer Setup
Complete sent by UE the last part of the inter-RAT CS handover call flow
scenario is successfully finished.
9-Dec-13, Page 13

Analysis
iRAT HO Analysis
In the iRAT 3G-2G Handover Matrix different panes/chapters are used to
display the data. Main chapters are:
1. iRAT 3G-2G Handover Matrix
2. Cell Radio Parameters (3G cells only)
3. Mobility Indicators (for 2G cell only)
After a carefully case study of 3G-3G relocations scenarios it was decided that
a matrix view of 3G-3G relocations (inter-RNC hard handover) does not
provide meaningful results, because
these procedures are rather rare in todays network,
in Relocation Resource Allocation the source cell of the HO cannot be

identified
in Relocation Preparation for 3G-3G HO the target cell ID cannot be

identified (only LAC is signaling in Target ID)
in case of failures in these procedure the existing dashboard KPIs for

HO Analysis and RANAP Abnormal Iu-Release Ratio provide sufficient
failure indicators and allow full troubleshooting workflow including drilldown to call details.
Since best correlation results are expected with cell information provided by
operators the import of a combined 2G/3G cell info file is required as
prerequisite for the matrix algorithms.
9-Dec-13, Page 14

Analysis
iRAT 3G-2G Handover Matrix

The iRAT HO 3G-2G Handover Matrix consists of several sections that are
described below:
Source Cell 3G
Figure 7. Source Cell 3G
This is the unambiguous identity of the source cell where the UE receives the
HO Command.
In the RANAP Init.Mgs. for Relocation Preparation the SAC of the source cell
is found together with the global cell ID (GCI) of the target ID. In the matrix
these IDs are displayed as source cell = RNC-ID+LAC+SAC (where RNC-ID
is derived from topology or cell info file).
Figure 8. Message Example 1. Source and target ID
Cell name, uARFCN and Primary Scrambling Code (Primary SC) are also
derived from cell info file.
9-Dec-13, Page 15

Target Cell 2G2G Cell Identity and Radio Quality before 3G-2G
Handover
Figure 9. Target Cell 2G
In this section the cell global identity is shown as derived from Init.Mgs.
Relocation Preparation = LAC+CI.
The BCCH ARFCN as well as BCC and NCC belong to a target TRX of a 2G
cell and are found in RRC Measurement Control and DMTAP Handover
Command (HCOM). (Refer to the figure below.)
Figure 10. Message Example 2: RRC Measurement Control for iRAT measurements
9-Dec-13, Page 16

The general relation between TRX (identified by BCCH ARFNC, BCC and
NCC) and CGI (cell) is shown in the figure below.
BSC
TRX 0
TRX 1
Cell 1
BTS 1
TRX 2
Cell 2
TRX 3
BTS m
Cell n
TRX 255
Figure 11. General Relation between TRX and CGI
The interRATCellID from RRC Measurement Control is often used to indicate

the verified BSIC (BCC+NCC) in RRC Measurement Report. (See Figure
12.Message example 3.)
>>>Band indicator
MP
Enumerated (DCS
1800 band used,
PCS 1900 band
used)
Indicates how to
interpret the
BCCH ARFCN
>>>BCCH ARFCN
MP
Integer (0..1023)
[45]
9-Dec-13, Page 17

+--------------------------------------------+------------------------------------------+
|ID Name
|Comment or Value
|
+--------------------------------------------+------------------------------------------+
|4999 2:53:38 PM,991,846 6-RRC-IUB RLC/MAC AM DATA DCH RRC_DCCH_UL measurementReport
|TS 25.331 DCCH-UL - V5.9.0 (RRC_DCCH_UL) measurementReport (= measurementReport)
|
|uL-DCCH-Message
|
|1 integrityCheckInfo
|
|1.1 messageAuthenticationCode
|'1f9185f3'H
|
|1.2 rrc-MessageSequenceNumber
|1
|
|2 message
|
|2.1 measurementReport
|
|2.1.1 measurementIdentity
|11
|
|2.1.2 measuredResults
|
|2.1.2.1 interRATMeasuredResultsList
|
|2.1.2.1.1 interRATMeasuredResults
|
|2.1.2.1.1.1 gsm
|
|2.1.2.1.1.1.1 gSM-MeasuredResults
|
|2.1.2.1.1.1.1.1 GSMCarrierRSSI
|74 dBm + SCALE to 73 dBm + SCALE
|
|2.1.2.1.1.1.1.2 bsicReported
|
|2.1.2.1.1.1.1.2.1 verifiedBSIC
|0
|
|
|
|
|2.1.2.1.1.1.2.2.1 verifiedBSIC
|2
|
|
|
|
|2.1.2.1.1.1.3.2.1 verifiedBSIC
|3
|
|
|
|
|2.1.2.1.1.1.4.2.1 nonVerifiedBSIC
|51
|
|
|
|
|2.1.2.1.1.1.5.2.1 nonVerifiedBSIC
|65
|
|2.1.3 eventResults
|
|2.1.3.1 interRATEventResults
|
|2.1.3.1.1 eventID
|e3a
|
|2.1.3.1.2 cellToReportList
|
|2.1.3.1.2.1 cellToReport
|
|2.1.3.1.2.1.1 bsicReported
|
|2.1.3.1.2.1.1.1 verifiedBSIC
|0
|
|
|
|2
|
|
|
|3
|
Figure 12. Message Example 3: RRC Measurement Report with iRAT measurement results
9-Dec-13, Page 18

+--------------------------------------------+------------------------------------------+
|ID Name
|Comment or Value
|
+--------------------------------------------+------------------------------------------+
|5097
2:53:39
PM,856,612
7-RRC-IUB
RLC/MAC
AM
DATA
DCH
RRC_DCCH_DL
handoverFromUTRANCommand-GSM
|
|TS
25.331
DCCH-DL
V5.9.0
(RRC_DCCH_DL)
handoverFromUTRANCommand-GSM
(=
handoverFromUTRANCommand-GSM) |
|TS 44.018 Radio Resource V5.15.0 (RR-DMTAP) HCOM (= Handover command)
|
|Handover command
|
|Protocol Discriminator
|radio ressource management messages
|
|Sub-protocol discriminator
|Skip Indicator
|
|Message Type
|43
|
|Cell Description
|
|BCC
|5
|
|NCC
|4
|
|BCCH ARFCN (high)
|0
|
|BCCH ARFCN (low)
|75
|
|BCCH ARFCN
|75
|
|Channel Description 2
|
Figure 13. Message Example 4: RRC Handover from UTRAN Command/DMTAP Handover Command
There is a fix mapping between BCCH ARFCN and the used GSM frequency
band:
GSM Frequ. Band
ARFCN
Comment
GSM 400
Dynamic
Not used
GSM 400
Dynamic
Not used
GSM 400
259293
Tansania only
GSM 400
306 340
Tansania only
GSM 700
Dynamic
Not used
GSM 700
438511
Not used
Dynamic
Not used
GSM 850
128251
America
GSM 900
1124
Worldwide
GSM 900
0, 1124, 9751023 Europe
GSM 900
0, 1124, 9551023 Asia, Europe
GSM 900
Dynamic
Not used
GSM 1800
512885
Worldwide
GSM 1900
512810
America
For the sequence of messages shown in Message Examples 1 to 4 the matrix

sections looks as below:
2G cell identiy and radio quality before 3G-2G handover
2G
BCCH
LAC+CI
ARFCN/BCC/NCC
GSM Frequency Band
[dBm]
75/5/4
GSM 900
74
308-371
avg. GSM RSSI @ iRAT HO
9-Dec-13, Page 19

3G-2G CS Handover/Relocation Preparation Failure Analysis
To request assignment of radio resources in the 2G RAN the RNC starts the
Relocation Preparation procedure.
Figure 14 shows a message flow example where first Relocation Preparation
fails due to semantic error and second Relocation Preparation sent to a
different 2G cell is successful.
Figure 14. Relocation Preparation Failure and Successful Relocation in same call
Reloc. Prep. Attempts. This is the number of RANAP Initiating Message for
procedure code relocation preparation
Distinct calls with Relocation Preparation Failure: This is the number of global
call IDs in which one or more Relocation Preparation Failures have been
found. Since the Relocation Preparation procedure in case of failure is
repeated multiple times in the same call a single problem of an individual
subscriber can lead to high failure ratios of the procedure KPI while subscriber
impact is low. This column helps to validate the subscriber impact.
Top Cause Reloc. Prep. Failure: These are the cause values seen most often
in Relocation Preparation Failure message (RANAP Unsuccessful Outcome for
procedure code relocation preparation.
For the sample call in Figure 14 the matrix delivers the following results:
Figure 15. 3G-2G CS Handover/Relocation Preparation Failure Analysis
9-Dec-13, Page 20

NOTE: For calls that have Iu (RANAP) signaling only and miss Iub the ARFCN
cannot be detected in case of Relocation Preparation Failure. Hence, the ARFCN
values are displayed as unknown in such cases.
9-Dec-13, Page 21

3G-2G CS Handover/Relocation Execution Failure Analysis
Figure 16 shows a sample call with multiple HO execution attempts that drops
at the end because of the handover failures.
Figure 16. Repeated Relocation Execution Failure in a voice call
The matrix view displays the following columns as follows:
Figure 17. 3G-2G CS Handover/Relocation Execution Failure Analysis
3G-2G HO Command. This is the number of DMTAP HCOM (embedded in

RANAP Successful Outcome relocation preparation.
Distinct Calls with HO Command. This is the number of global call IDs that
have min. 1 DMTAP HCOM
Top Cause HO Exec. Failure. This is the cause value seen most often in
RANAP Initiating Message Relocation Cancel.
Number HO Failure reported by Handset. This is the number RRC Handover
from UTRAN Failure messages (counted on the target cell of relocation
preparation procedure).
9-Dec-13, Page 22

Top Cause HO Failure reported by UE. This is the cause value seen most
often in RRC Handover from UTRAN Failure messages
Number Call Drop after failed HO. This is the number of RANAP IuReleaseRequest messages with BAD cause. This is a call drop that happens
as result of failed relocation preparation or HO execution.
Top Cause for Call Drop after failed HO the top RANAP cause value for
drops after failed relocation preparation or HO execution.
9-Dec-13, Page 23

3G-2G PS Cell Change Order (CCO) Failure
Figure 18 shows a full call flow procedure of a PS cell change order to 2G.
Note that there is no relocation preparation and only identity of the target cell is
BCCH ARFCN and BSIC. As the details in the sequence of messages (figure
19 to 21) shows there are a couple of options that have been taken into
account:
1. The RRC Meas. Reports is sent periodically instead of event-triggered. If
event-triggered the proper HO trigger is event 3A.
2. The BSIC value display in RRC Meas. Report is not always the BSIC
itself. Depending on RNC NEM the BSIC value in the RRC Meas. Report
is one of the following:
a. The BSIC in combined (NCC+BCC) hex format
b. The value of the BCCH ARFCN of the cell (as seen in Figure 20)
c. The value of the inter-RATCellID seen in RRC Meas. Control before
Figure 18. CCO full call flow procedure
Figure 19. RRC Meas. Control for iRAT
9-Dec-13, Page 24
Figure 20. RRC Measurement Report (periodic)
Figure 21. RRC Cell Change Order from UTRAN Command
The contents of the columns in the 3G-2G PS CCO section of the matrix is
defined as follows:
PS 3G-2G CCO Att. This is the number of RRC Cell Change Order from
UTRAN messages.
Top Cause CCO Failure reported by UE. This is the cause value seen most
often in RRC Cell Change Order Failure.
The matrix columns representation is as shown in the figure below.
9-Dec-13, Page 25
Figure 22. RRC Cell Change Order from UTRAN Command
9-Dec-13, Page 26

Analysis
Radio Measurements (All reports)

In the pane Radio Measurements, in the iRAT 3G-2G Handover Matrix, the
histograms for Intra-frequency Ec/N0, Intra-frequency RSCP, GSM RSSI and
Propagation Delay can be viewed, for the source cell during duration of the
iRAT matrix snapshot.
The histograms show the percentage (%) value for each histogram bar and
standard deviation value.
Figure 23. Radio Measurements Histograms Representation
9-Dec-13, Page 27

Analysis
Traffic Load
The Traffic Load pane, in the iRAT 3G-2G Handover Matrix, displays the
following KPIs (for the 3G source cell only).
Figure 24. Traffic Load View
iRAT CRS Mobility Ratio %. This formula works the following way: each interRAT cell reselection of an UE changing from 2G to 3G leads to a combined
Location/Routing Area Update (Loc. Update cause = normal LUP). The
number of iRAT cell reselections is the number of successfully established
RRC connections for establishment cause inter-RAT-cell-reselection. The
result of the formula shows how many normal Location Updates caused by
mobility of UEs are due to iRAT cell change 2G-3G. A value > 50% indicates
that there are more UEs toggling between 2G and 3G than UEs moving from
one 3G LAC to another.
NOTE: During system test phase it was observed that in short sessions defective
handsets can leverage the equation result to values higher than 100%. If such
values are seen this is a clear indication to make a more detailed investigation of
the Location Update performance in the source cell, e.g. by filtering on all calls
with RRC Establishment Cause = "inter-RAT cell reselection" of this cell and make
column statistics on subscriber IDs.
Outgoing iRAT PDP Cntx. Mobility Ratio %. This KPI shows how many active
PDP Contexts from the source cell are leaving to 2G.
Incoming iRAT PDP Cntx. Mobility Ratio %. This KPI shows how many active
PDP Context in the cell are coming from 2G.
CS outgoing iRAT Mobility Ratio %. This KPI shows how many CS RABs that
9-Dec-13, Page 28

have been successfully established in 3G are leaving to 2G while active.
This KPI shows how many CS RABs that have been successfully established
in 3G are leaving to 2G while active.
9-Dec-13, Page 29

In addition to these KPIs, there are also the CS and PS Traffic Load KPIs for
the 3G source cell as CS Traffic Load (Erlang) per hour =
PS Traffic Load (Erlang) per hour =
PS vs. CS iRAT Handover Ratio %. This KPI shows the percentage of PS iRAT
Cell Change compared to all iRAT handover (CS + PS). It allows determining if
more packet calls or more voice calls are handed over to 2G.
9-Dec-13, Page 30

Sort and Filter Functions
The following filters are available within the iRAT HO Matrix which allow to sort
and filter the top 10 (source) cells with:
Highest iRAT CRS Mobility Ratio
Highest Outgoing iRAT PDP Cntx. Mobility Ratio
Highest Incoming iRAT PDP Cntx. Mobility Ratio
Highest CS outgoing iRAT Mobility Ratio
Highest CS Traffic Load
Highest PS Traffic Load
Highest PS vs. CS iRAT Handover Ratio
Lowest PS vs. CS iRAT Handover Ratio
9-Dec-13, Page 31

Analysis
Troubleshooting iRAT HO Using Dashboard KPIs

The TrendNavigate reports allow to analyze iRAT HO Analysis from the
several report KPIs. The following sections show these possibilities.
Problem discovery
As it is already known, the TrendNavigate tool provides more than one starting
points for discovering the network issues. One such report is the Top Cells
report.
In our case the Top Cells report can be generated based on several KPIs, e.g.
3G-2G CS Handover Failure Ratio.
The method of getting this report is simple. From the Reports menu, click Top
Cells. In the displayed screen, in the right pane, select the report criteria and
the KPI 3G-2G CS Handover Failure Ratio from the KPI list and click Apply.
The following figure shows a view of the Top Cells Report.
Figure 25. Top Cells Report View
This report contains all the cells with 3G-2G Handover Failure, and gives
details on the number of Attempts recorded and for each attempt the sub9-Dec-13, Page 32

cause of failure, e.g. Failure in the Radio Interface Procedure, Radio
Connection with UE lost, or Timer Expiry.
In this report we can see the SAC 22231 is the top runner of the list. So, this
deserves some deep dive analysis. The findings from this SAC shall be equally
applicable to other SACs in the network.
Alternate Entry Point
An equally good and valuable way of discovering iRAT issues is the KPI Cause
CPT Report. This report can be opened from the toolbar menu KPI Cause. In
the displayed report window select the criteria from the right navigation panel.
In the Additional right navigation panel, select the 3G-2G CS Handover Failure
Ratio in the KPIs list.
Figure 26. Select KPI "3G-2G CS Handover Failure Ratio"
When selecting a KPI, TrendNavigate fills in the Cause and sub-causes

automatically. Next, click on the Trend button at the bottom of this panel. This
will sort the report in the descending order for all sub-causes.
9-Dec-13, Page 33

The final report looks like in the figure below:
Figure 27. KPI Cause Report for "3G-2G CS Handover Failure Ratio"
In this graphic we can see the causes and sub-causes for our selected KPI.
The main cause is Relocation Cancel and the sub-causes are Failure in the
Radio Interface Procedure and Radio Connection with UE lost, along with one
case where the sub-cause is mentioned as Cause not distributed.
Deep Dive Analysis
Having seen the Iu Report for 3G-2G CS Handover Failure analysis, further
investigations into the messaging of call flow are possible, to find out the root
cause. The root cause can either be in the hardware (RNC, UE) or in the
planning of the network, (iRAT neighbor definitions, missing or one-way
neighbors, or poor GSM signal of the 2G neighbor).
All of this requires a detailed analysis in the messaging to compare the values
reported in the Measurement reports for various 2G Cells.
For this purpose, the first need is to look at all those calls that contributed to
the KPI 3G-2G CS Handover Failure Ratio in the UMTs network.
TrendNavigate offers this possibility to getting the call table containing only our
intended calls.
9-Dec-13, Page 34

Right-click on the bar graph under the Causes for KPI 3G-2G CS Handover
Failure Ratio. This gives you the option to open the call Table. Refer to the
figure below.
Figure 28. Right-Click on the bar graph gives the option to Open Call Table
Click the Open Call Table option to open the NSA Call Analysis application. It
gets started with the auto-filtered call table for the desired KPI.
It is worth mentioning here that if you opened the call table from the top left
graph in the KPI Cause report, the call table will contain calls for all subcauses. You can also open the call table for one individual sub-cause by rightclicking on the graph for the particular sub-cause. Refer to figure 27.
The call table has the flexibility to show RANAP Release Causes. In this case
the Call Table looks like in figure below:
Figure 29. NSA-CA Call Table showing calls after filtering
Each row in the call table represents one Global Call and is capable of being
drilled down to the single message level.
9-Dec-13, Page 35
Root Causes
Delving into the Messaging Sequences revealed some interesting facts:

a. UE informs the network that 3G coverage is fading out; see figure 30
below for details.
Figure 30. UE Reporting weak 3G Coverage.
b. There are 2G neighbors in the vicinity; they are the right candidates for
iRAT Handover. The RNC gives the Relocation Preparation Command,
a signal to go ahead and perform the Handover to 2G system. This is
shown in the figure 31 below.
Figure 31. RNC gives the "Relocation Preparation" Command
9-Dec-13, Page 36

But the measurement report also reveals that the strength of GSM RSSI is also
not so good: (See Figure 32)
Figure 32. UE reports weak GSM Signal for 2G neighbors
c. There is the Handover Command from UTRAN-GSM also seen on the

Iub interface, followed by Handover from UTRAN Failure, with the
cause Physical Channel Failure, as seen in the figure 33 below:
Figure 33. Handover from UTRAN Failure, cause "Physical Channel Failure"
9-Dec-13, Page 37

d. As a result, the RNC gives the command Relocation Cancel with the
cause code Failure in the Radio Interface Procedure as shown in the
figure 34 below:
Figure 34. RNC sends "Relocation Cancel" Command, cause "Failure in the Radio
Interface Procedure"
This process repeats several times itself (Figure 35 below) and finally the call
is released with the cause Radio Connection with UE Lost (see Figure 37)
Figure 35. UE tries several times during the call to perform iRAT HO to 2G, but fails
each time.
9-Dec-13, Page 38

Just before call drop, the UE reported all its 2G neighbors, none of which
seems to be strong enough to sustain the call. (See Figure 36)
Figure 36. All of the reported GSM neighbors are too weak to perform the HO.
Figure 37. Finally, RNC send the Iu-Release command, cause "Radio Connection with
UE lost"
9-Dec-13, Page 39

NSA Call Analysis application also shows the measured quantities in the
Measurement reports. The following figure shows the Radio environment
before the call drop with the help of NSA CA.
Figure 38. RSCP, EcNo and TrCh BER before the call dropped
Figure 38 shows clearly that the RSCP of the serving cell is deteriorating,
EcNo is below -20 dB and the TrCH BER is ~ 25%. At such Radio
environment, it is impossible for the communication to continue.
Following figure (39) shows the RSCP value only just before the call drop:
Figure 39. RSCP Value of the serving cell before the call dropped.
Obviously, with RSCP at <-114 dBm, the call cannot continue.
9-Dec-13, Page 40

This analysis has been performed over several calls and was found that:
Some of the defined 2G neighbors are not strong enough.

Some of the 2G neighbors are reported having good GSM RSSI, but
still the iRAT HO fails.
The excel sheet attached below displays this analysis.

As one can see all these details of this table that shows results of (manual)
single call analysis will be presented now in the iRAT 3G-2G Handover Matrix
in an aggregated way.
Figure 40. iRAT HO Analysis
A snapshot of the excel sheet for iRAT HO Failure Analysis shows the GSM
RSSI is generally very low in the network, although there are some instances
of good GSM RSSI also reported in iRAT HO Failures.
9-Dec-13, Page 41
A General view of the GSM RSSI in the network
In this case, it is obvious that the 2G coverage is not so good, but to give it a
quantitative aspect, pull out some reports on RNC level and then on some
selected cell levels to see how the GSM RSSI looks like.
Figure 41 reveals that the general RMS value of the GSM RSSI is rather on the
lower side. Majority of the GSM carriers appears to be below -90 dBm, with
some of them being as low as -110 dBm. This trend indicates that the GSM
values reported by UEs are not favorable in most of the cases to support the
iRAT HO to 2G carriers.
One recommendation is to add more 2G sites to the network so as to bring the
average around -85 dBm. That will enhance significantly the chances of iRAT
HO to 2G being successful.
Figure 41. GSM RSSI for the RNC05
GSM RSSI value histogram for cell-id 61722 is shown below in the figure 19
below.
Figures 42 and figure 43 show the Histogram for GSM RSSI for two selected
cells.
Figure 42. GSM RSSI for c-id 61722
9-Dec-13, Page 42

GSM RSSI for the top runner cell-id 22231 is shown in figure 20 below:
Figure 43. GSM RSSI for c-id 22231
From the sample, cells selected for GSM RSSI histogram, it is shown that the
majority of the measurements report GSM values below -90 dBm. This coupled
with the average GSM RSSI for the whole RNC (Figure 41) is sufficient to
believe that the network lacks the absolute required level of GSM coverage
and the call will keep dropping due to unsuccessful iRAT HO to 2G, unless
some measures are taken to boost the average value of 2G signal in the
network.
PS Data Calls
There are no differences between the situations of the PS and CS calls.

It should be mentioned that it has been observed similar pattern of drop calls
while an iRAT HO was declared mandatory by the radio conditions. So, the
Cell Change Order command will be find on the Iub instead of Handover from
UTRAN command for the PS calls. The rest of the procedure and cause values
remain unchanged.
9-Dec-13, Page 43

Analysis
RAN Optimization with iRAT 3G-2G Handover
Troubleshoot and Optimize inter-RAT 3G-2G Handover
Problem Statement: Failed inter-RAT Handovers prevents the subscriber from

being transferred to an environment with better radio conditions. Thus, the user
plane QoS/QoE for subscriber remains poor and the risk of a call drops in the
3G radio environment rises the longer the handover is not successfully
executed.
How to proceed in TrendNavigate:
a) Open inter-RAT Handover Matrix
b)
Filter on non blanks in column 3G-2G HO Execution Failure Ratio
Figure 44. iRAT Hanover Matrix: Set Filter for 3G-2G HO Execution Failure Ratio
c) Scroll to the left side to see names of source cell/target cell and radio
conditions in target cell. Based on this information the RAN engineers
or consultants can prepare a list of executable actions.
9-Dec-13, Page 44
Troubleshoot 3G-2G Relocation Preparation Issues
Problem Statement: Relocation Preparation is a RANAP procedure that

triggers the request to allocate radio resources. As results the target systems
(e.g. BSC in GERAN) sends a DTAP Handover Command message back to
the UTRAN. If Relocation Preparation fails the HO Command message is not
provided by BSC and hence, the handover cannot be executed and the
subscriber must continue to stay under bad radio conditions with impact on
QoS/QoE and risk of drop due to radio.
a) Open inter-RAT Handover Matrix.
b) Filter on non blanks in column Reloc. Prep. Failure Ratio. In the
example
the
failure
ratios
really
low
after
successful
troubleshooting/optimization campaing in this field.
Figure 45. Set Filter for Reloc. Prep. Failure Ratio
c) Scroll to left side to see names of source/target cell and radio

conditions in target at HO decision
Figure 46. Source/ Target Cell and Radio Conditions View at HO decision
d) Further analysis must be done in the 2G RAN or core network

transport. These are the typical problem areas of Relocation
Preparation Failures.
9-Dec-13, Page 45
Wrong 2G Target Neighbor
Problem Statement: It is aim of the handover to bring the connection of the

subscriber to an area with better radio conditions to improve QoS/QoE and
reduce the risk of drops. When a target cell does not offer good radio
conditions and the handover is executed anyway, the improvement will not
happened and more dramatically the risk of a drop during or after the
handover is even higher than staying in the suboptimal 3G RAN.
a) Open inter-RAT handover matrix
b) Filter on target cells that have low GSM RSSI values, check impact on
HO Execution Failures. Typically the UEs react with a physical
channel failure when radio conditions in HO Target are insufficient or
the targeted radio signal is not found.
Figure 47. Execution Failure Analysis
Figure 48. Execution Failure Ratio
c) The typical error in such situation is that the best 2G neighbor is

missed in the inter-RAT neighbor list of the 3G source cell in the RNC.
So, it is highly recommended to check this list and compare with up-todate 2G radio network planning data.
d) If the neighbor lists are okay then coverage issues of the 2G cell can
be assumed that are often revealed from the GSM RSSI Measurement
results reported on 3G refer to the figure below. Here an insufficient
2G coverage of the target cell leads to physical channel failure during
HO/Cell Change Order while the HO trigger conditions of the source
cell can be easily identified as 3G coverage issues based on
comparison of RSCP and Ec/N0 histograms.
9-Dec-13, Page 46
Figure 49. iRAT HO Matrix. Radio Measurements (All Reports)
Reduce Inter-RAT and Intra-RAT Location Toggling
Problem Statements: During Location Update procedure, the mobile does not
listen to received Paging, so we should count the number of Paging sent to a
mobile when it is doing the LUREQ procedure (Paging received between
rrcConnectionRequest (registration) and LUACC). This sometimes is called
collision. Especially it is often seen that one IMSI makes 60 to more than 100
LUREQ/hour in one cell, because it is toggling in IDLE mode (not signaling
sent) between 2G and 3G LAC or between two different 3G LACs. This kind of
LAC toggling creates a lot of unwanted signaling load on RNCs.
Optimization Target: Reduce Signaling Load in RNC by eliminating ping-pong
Location Updates improve customer QoE in parallel, because ping-pong LUP
leads to high number of paging failures in turn
a) When looking into iRAT Matrix you see iRAT CRS Mobility Ratio, which
is number of successful RRC Conn. Setups with est. cause inter-RAT
Cell Reselection vs. number of Loc. Upd. normal.
As we know, each inter-RAT Cell Reselection triggers a combined
LUP/RAUP normal and subscribers can only come from 2G to 3G cell
or form different 3GLAU to our monitored 3G LAU (RNC). Looking at
example below it is seen 3971 LUP normal and 75.8% of the are due
9-Dec-13, Page 47

to 2G-3G LUP, which means in turn that 100%-75.8%=24.2% are due
to 3G-3G LUP.
There also can be observed that 89.5% of the 476 PDP Contexts that
are active in this cell during the observation period come from 2G
(following iRAT CRS) and you see further that form the 197 PDP
Contexts initially established on 3G in this cell 37% are sent to 2G
using RRC Cell Change Order from UTRAN (which is forced iRAT CRS
to 2G).
45.9% of the CS RABs (voice) that are established in this cell are
handed over to 2G. Conclusion: in this cell there is a lot of 3G-2G-3G
Ping-Pong.
Figure 50. Source Cell Measurements Values
b) Now there is a possibility to verify this thesis in the following way using
the call table:
a. Filter on the first UTRAN cell = cell-ID of Lafitte* and RRC
Establishment Cause = inter-RAT Cell Reselection (3G-2G PingPong) or registration (3G-3G Ping-Pong)
b. Run column statistics on IMSI to see if same subscribers pop up all
the time, filter on single IMSIs for more details.
Sample: it can be seen same subscriber in same cell registering again and
again
9-Dec-13, Page 48
Figure 51. Subscriber Multiple Registration
If you need stats how often IMSI register in same cell you can run XML KPI. If
you further want to know if they have old LAC = new LAC you can also build
XML counter for this.
Figure 52. Find New/Old LAC
9-Dec-13, Page 49

c) Drill-down to call details or rf5. In case of our example you see that old
LAC is default value 65534, means: old LAC was deleted on SIM card.
This happens, e.g. in case of IMSI unknown in VLR/HLR during
Identity Check Procedure LUP/Attach/RAUP or CMSREJect with
similar NAS cause.
The other possible root cause is that the handset loses the stored
LAC due to internal error and thus, needs to register again.
Note: During system test phase using short sessions iRAT CRS Mobility Ratio
values > 100% have been observed. This was caused by a single subscriber trying to
register in PS domain ping-pong wise 3G-2G-3G etc. and always rejected by the
network. This is exceptional behavior rarely seen, but a real issue for the network in
term of rising signaling load. So values >100% shall not be seen a bug in
TrendNavigate formula, but rather they highlight exceptional problem areas.
Figure 53. Call Table View
9-Dec-13, Page 50

Analysis
How to Find iRATs in the NSA Call Table

Circuit switched intersystem cell changes calls can be viewed in the Call Table.
When you open the Call Table, the column Handover Procedure displays the
history of the cell change for a call as displayed in the figure below.
Figure 54. Handover Procedure shown in the Call Table
Thus any call that contains entries in the Handover Procedure column contains
intersystem cell changes.
9-Dec-13, Page 51

For a detailed analysis of such calls, select the individual row and double-click
for the drill down chart. A sample screen capture is depicted below.
Figure 55. Drill-down chart
For packet switched calls the handover history is not populated. Hence, calls
with intersystem cell changes can be detected via the SGSN, BSC and RNC
columns in the Call Table. A call that has had an intersystem cell change
includes the BSC and RNC columns populated accordingly.
9-Dec-13, Page 52

An example of a PS call with an intersystem cell change is depicted in the
figure below.
Figure 56. PS Call with intersystem cell change
Also in this view, a call that has had an intersystem cell change shows entries
in the BSC and RNC columns.
9-Dec-13, Page 53

Analysis
Abbreviations
2G
Second Generation (synonym for GSM)
3G
Third Generation Mobile Services
ALCAP
Access Link Control Application Part
AMR
Adaptive Multi Rate
ARFCN
Absolute Radio Frequency Channel Number
BCC
Base station Colour Code
BCCH
Broadcast Control Channel
BSIC
Base Station Identity Code
BSSAP
Base Station System Application Part
BSSGP
Base Station System GPRS Protocol
CPT
Call Phase Tracker, the main engine behind the

TrendNavigate GUI.
CS
Circuit Switched
CGI
Common Gateway Interface
DCH
Dedicated Channel
DL
Down link
DMTAP
Ec/N0
GSM
HO
Direct Mobile Transfer Application Part

Chip Energy over Noise (measured on CPICH)
Global System for Mobile Communications
Handover
HS-DSCH
High Speed Downlink Shared Channel
ID
Identifier
IMSI
International Mobile Subscriber Identity

9-Dec-13, Page 54

iRAT
KPI
LAC
Inter radio access technology

Key Performance Indicator
Location Area Connection
LAI
Location Area Interface
LAPD
Link Access Protocol in the D channel
LAU
Location Area Update
MSC
Mobile Switching Centre
NAS
Non Access Stratum
NBAP
Node-B Application Part
NEM
Network Equipment Manufacturer
NSA
Network Service Analyzer
NSAP
Network Service Access Point
NSAPI
Network Service Access Point Identifier
PCU
Packet Control Unit
PDP
Packet Data Protocol (e.g. PPP, IP, X.25)
PLMN
Public Land Mobile Network
PS
Packet Switched
PSC
Primary Scrambling Code
P-TMSI
Packet TMSI
QoS
Quality of Service
QPSK
Quadrature Phase Shift Keying
RAB
Radio Access Bearer
RAI
Routing Area Interface
RAN
Radio Access Network
RANAP
Radio Access Network Application Part
RAU
Routing Area Update
RB
Radio Bearer
RL
Radio link
RLC
Radio Link Control; Release Complete Message

9-Dec-13, Page 55

RNC
Radio Network Controller
RNTI
Radio Network Temporary Identity
RRC
Radio Resource Control
RSSI
SAC
SC
Received Signal Strength Indicator

Service Area Code
Scrambling Code
SGSN
Serving GPRS Support Node
SRNC
Serving Radio Network Controller
TMSI
Temporary Mobile Subscriber Identity
TRX
(Base Station) Transceiver
u-ARFCN
UMTS Radio Frequency Channel Number
UE
User Equipment
UL
Up link
Um
GSM Air Interface
UP
User Plane
UTRAN
UMTS Terrestrial Radio Access Network
VLR
Visitor Location Register
9-Dec-13, Page 56

Analysis
Technical Support
EMEA
For support contact your regional Technical Assistance Center:
phone
+373 22 879020
fax
+373 22 879001
Americas
e-mail
phone
e-mail
Tektronix-nd-tac-emea@tek.com
+1 469 330 4580

Tektronix-ND-TAC-US@tek.com
Asia Pacific
phone
e-mail
+86 21 389 60420

Tektronix-ND-TAC-AsiaPac@tek.com
9-Dec-13, Page 57

Copyright Tektronix Communications. All rights reserved. Licensed software
products are owned by Tektronix Communications or its subsidiaries or
suppliers, and are protected by national copyright laws and international treaty
provisions.
Tektronix Communications products are covered by U.S. and foreign patents,
issued and pending. Information in this publication supersedes that in all
previously published material. Specifications and price change privileges
reserved.
TEKTRONIX, Tektronix Communications and TEK are registered trademarks of
Tektronix, Inc.
Contacting Tektronix Communications
Tektronix Communications
3033 W President George Bush Highway
Plano, TX 75075
Phone: + 1 469 330 4000
Fax: + 1 469 330 4001
For product information, sales, service, and technical support:

+373 22 879 020
This document supports software version NSA 4.00 and above.
Revised: April 2012
Worldwide, visit http://www.tektronixcommunications.com to find contacts in
your area.
9-Dec-13, Page 58

Nsa Application Paper Irat Handover Analysis-Libre

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nsa Application Paper Irat Handover Analysis-Libre

Uploaded by

Copyright:

Available Formats

Application Paper: iRAT Handover

3G -> 2G and 2G -> 3G iRAT handovers for CS services

NSA Software Version 4.00 does not support yet:

Network Assisted Cell Change (NACC) for PS services

About This Document

An introduction about intersystem handovers and cell changes

Application Paper: iRAT Handover

Evolution of Intersystem Cell Changes since 3GPP R6

iRAT Handover Analysis

3G-2G Inter-RAT Handover for CS Services

Step 1: This procedure is triggered by an RRC Measurement Report

Step 2: The RANAP Relocation Required message is sent from the

Step 3: From the target information in the RANAP Relocation Required

Step 4: The BSSMAP Handover Request message is forwarded

Figure 1. Overview of an inter-3G-2G cell change

Step 6: After successful resource allocation via Abis, the BSC

iRAT Handover Analysis

Step 7: The MAP Prepare Handover Acknowledge message is used to

Step 8: The 3G MSC orders a relocation of SRNC and forwards the

Step 9: The RRC entity of the SRNC sends an intersystem Handover

Step 10: Based on the information found in the DTAP Handover

iRAT Handover Analysis

iRAT Handover Analysis

According to this information, the UE sends a Routing Area Update Request

Figure 2. Message flow of 3G-2.5G PS Cell Change

iRAT Handover Analysis

iRAT Handover Analysis

Figure 3. Message flow of 2.5G-3G Inter-RAT Cell Reselection for PS Service

Typically, there is no IP data to be transmitted and the RRC connection used

iRAT Handover Analysis

Figure 4. Call flow of a 2G-3G CS inter-RAT cell change

Following the ASN.1 terminology, the message is encoded as Initiating

iRAT Handover Analysis

iRAT Handover Analysis

iRAT Handover Analysis

Figure 5. Call flow of a 2G-3G CS inter-RAT cell change

The RRC UTRAN Mobility Information procedure is an acknowledged RRC

iRAT Handover Analysis

Figure 6. Call flow of a 2G-3G CS inter-RAT cell change

Application Paper: iRAT Handover

these procedures are rather rare in todays network,

in Relocation Resource Allocation the source cell of the HO cannot be

in Relocation Preparation for 3G-3G HO the target cell ID cannot be

in case of failures in these procedure the existing dashboard KPIs for

Application Paper: iRAT Handover

iRAT 3G-2G Handover Matrix

Figure 7. Source Cell 3G

Figure 8. Message Example 1. Source and target ID

iRAT Handover Analysis

Figure 9. Target Cell 2G

iRAT Handover Analysis

The interRATCellID from RRC Measurement Control is often used to indicate

iRAT Handover Analysis

iRAT Handover Analysis

0, 1124, 9751023 Europe

0, 1124, 9551023 Asia, Europe

For the sequence of messages shown in Message Examples 1 to 4 the matrix

GSM Frequency Band

avg. GSM RSSI @ iRAT HO

iRAT Handover Analysis

Figure 15. 3G-2G CS Handover/Relocation Preparation Failure Analysis

iRAT Handover Analysis

iRAT Handover Analysis