Upload
shahzad-waseem
View
280
Download
1
Embed Size (px)
Citation preview
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 1/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 1
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 Th is Documen t
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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 2/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 2
Evoluti on o f Intersy stem 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 f lows 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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 3/58
iRAT Handover Analysis
9-Dec-13, Page 3
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 Handov er for CS Servi ces
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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 4/58
iRAT Handover Analysis
9-Dec-13, Page 4
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 5/58
iRAT Handover Analysis
9-Dec-13, Page 5
3G-2.5G Inter-RAT Cell Change fo r PS Servic es
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 withan 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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 6/58
iRAT Handover Analysis
9-Dec-13, Page 6
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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 7/58
iRAT Handover Analysis
9-Dec-13, Page 7
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 8/58
iRAT Handover Analysis
9-Dec-13, Page 8
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 9/58
iRAT Handover Analysis
9-Dec-13, Page 9
2G-3G CS inter-RAT Handover o n Iub and Iu i nterf ace
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 thenecessary 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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 10/58
iRAT Handover Analysis
9-Dec-13, Page 10
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-RNC-
transparent-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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 11/58
iRAT Handover Analysis
9-Dec-13, Page 11
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 l ink 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 f ind 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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 12/58
iRAT Handover Analysis
9-Dec-13, Page 12
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 s-
RNTI.
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.
Figure 5. Call flow of a 2G-3G CS inter-RAT cell change
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 13/58
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 14/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 14
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 today’s 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 drill-
down 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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 15/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 15
iRAT 3G-2G Handover Matrix
The iRAT HO 3G-2G Handover Matrix consists of several sections that are
described below:
Sourc e Cell 3G
Figure 7. Source Cell 3G
This is the unambiguous identity of the source cell where the UE receives theHO 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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 16/58
iRAT Handover Analysis
9-Dec-13, Page 16
Target Cell 2G–2G 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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 17/58
iRAT Handover Analysis
9-Dec-13, Page 17
The general relation between TRX (identified by BCCH ARFNC, BCC and
NCC) and CGI (cell) is shown in the figure below.
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 (DCS1800 band used,PCS 1900 bandused)
Indicates how tointerpret theBCCH ARFCN
>>>BCCH ARFCN MP Integer (0..1023) [45]
BSC
TRX 0
TRX 1
TRX 2
TRX 3
TRX 255
Cell 1
Cell 2
Cell n
BTS 1
BTS m
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 18/58
iRAT Handover Analysis
9-Dec-13, Page 18
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +| I D Name | Comment or Val ue |+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +| 4999 2: 53: 38 PM, 991, 846 6- RRC- I UB RLC/ MAC AM DATA DCH RRC_DCCH_UL measur ement Repor t| TS 25. 331 DCCH- UL - V5. 9. 0 ( RRC_DCCH_UL) measurement Repor t ( = measurement Repor t ) |
| uL- DCCH- Message || 1 i nt egri t yCheckI nf o || 1. 1 messageAut hent i cat i onCode | ' 1f9185f 3' H || 1. 2 r r c- MessageSequenceNumber | 1 || 2 message || 2. 1 measurement Repor t || 2. 1. 1 measurement I dent i t y | 11 || 2. 1. 2 measuredResul t s || 2. 1. 2. 1 i nt er RATMeasur edResul t sLi st || 2. 1. 2. 1. 1 i nt erRATMeasur edResul t s || 2. 1. 2. 1. 1. 1 gsm || 2. 1. 2. 1. 1. 1. 1 gSM- Measur edResul t s || 2. 1. 2. 1. 1. 1. 1. 1 GSMCarr i erRSSI | 74 dBm + SCALE t o 73 dBm + SCALE || 2. 1. 2. 1. 1. 1. 1. 2 bsi cRepor t ed || 2. 1. 2. 1. 1. 1. 1. 2. 1 veri f i edBSI C | 0 || 2. 1. 2. 1. 1. 1. 2 gSM- Measur edResul t s || 2. 1. 2. 1. 1. 1. 2. 1 GSMCarr i erRSSI | 85 dBm + SCALE t o 84 dBm + SCALE || 2. 1. 2. 1. 1. 1. 2. 2 bsi cRepor t ed || 2. 1. 2. 1. 1. 1. 2. 2. 1 veri f i edBSI C | 2 || 2. 1. 2. 1. 1. 1. 3 gSM- Measur edResul t s || 2. 1. 2. 1. 1. 1. 3. 1 GSMCarr i erRSSI | 86 dBm + SCALE t o 85 dBm + SCALE || 2. 1. 2. 1. 1. 1. 3. 2 bsi cRepor t ed || 2. 1. 2. 1. 1. 1. 3. 2. 1 veri f i edBSI C | 3 || 2. 1. 2. 1. 1. 1. 4 gSM- Measur edResul t s || 2. 1. 2. 1. 1. 1. 4. 1 GSMCarr i erRSSI | 94 dBm + SCALE t o 93 dBm + SCALE || 2. 1. 2. 1. 1. 1. 4. 2 bsi cRepor t ed || 2. 1. 2. 1. 1. 1. 4. 2. 1 nonVeri f i edBSI C | 51 || 2. 1. 2. 1. 1. 1. 5 gSM- Measur edResul t s || 2. 1. 2. 1. 1. 1. 5. 1 GSMCarr i erRSSI | 95 dBm + SCALE t o 94 dBm + SCALE || 2. 1. 2. 1. 1. 1. 5. 2 bsi cRepor t ed || 2. 1. 2. 1. 1. 1. 5. 2. 1 nonVeri f i edBSI C | 65 || 2. 1. 3 event Resul t s || 2. 1. 3. 1 i nt er RATEvent Resul t s |
| 2. 1. 3. 1. 1 event I D | e3a || 2. 1. 3. 1. 2 cel l ToReport Li st || 2. 1. 3. 1. 2. 1 cel l ToReport || 2. 1. 3. 1. 2. 1. 1 bsi cReport ed || 2. 1. 3. 1. 2. 1. 1. 1 veri f i edBSI C | 0 || 2. 1. 3. 1. 2. 2 cel l ToReport || 2. 1. 3. 1. 2. 2. 1 bsi cReport ed || 2. 1. 3. 1. 2. 2. 1. 1 veri f i edBSI C | 2 || 2. 1. 3. 1. 2. 3 cel l ToReport || 2. 1. 3. 1. 2. 3. 1 bsi cReport ed || 2. 1. 3. 1. 2. 3. 1. 1 veri f i edBSI C | 3 |
Figure 12. Message Example 3: RRC Measurement Report with iRAT measurement results
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 19/58
iRAT Handover Analysis
9-Dec-13, Page 19
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +| I D Name | Comment or Val ue |+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +| 5097 2: 53: 39 PM, 856, 612 7- RRC- I UB RLC/ MAC AM DATA DCH RRC_DCCH_DL
handover Fr omUTRANCommand- GSM || TS 25. 331 DCCH- DL - V5. 9. 0 ( RRC_DCCH_DL) handoverFr omUTRANCommand- GSM ( =handover Fr omUTRANCommand- GSM) || TS 44. 018 Radi o Resource V5. 15. 0 ( RR- DMTAP) HCOM ( = Handover command) || Handover command || Prot ocol Di scr i mi nat or | r adi o r essour ce management messages || Sub- protocol di scr i mi nat or | Ski p I ndi cat or || Message Type | 43 || Cel l Descri pt i on || BCC | 5 || NCC | 4 || BCCH ARFCN ( hi gh) | 0 || BCCH ARFCN ( l ow) | 75 || BCCH ARFCN | 75 || Channel Descr i pt i on 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:
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
LAC+CI
BCCH
ARFCN/BCC/NCC GSM Frequency Band
avg. GSM RSSI @ iRAT HO
[dBm]
308-371 75/5/4 GSM 900 74
GSM Frequ. Band ARFCN Comment
GSM 400 Dynamic Not used
GSM 400 Dynamic Not used
GSM 400 259–293 Tansania only
GSM 400 306 – 340 Tansania only
GSM 700 Dynamic Not used
GSM 700 438–511 Not used
Dynamic Not used
GSM 850 128–251 America
GSM 900 1–124 Worldwide
GSM 900 0, 1–124, 975–1023 Europe
GSM 900 0, 1–124, 955–1023 Asia, Europe
GSM 900 Dynamic Not used
GSM 1800 512–885 Worldwide
GSM 1900 512–810 America
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 20/58
iRAT Handover Analysis
9-Dec-13, Page 20
3G-2G CS Handover/Relocatio n Preparation Failu re Analys is
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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 21/58
iRAT Handover Analysis
9-Dec-13, Page 21
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 22/58
iRAT Handover Analysis
9-Dec-13, Page 22
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).
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 23/58
iRAT Handover Analysis
9-Dec-13, Page 23
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 Iu-
ReleaseRequest 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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 24/58
iRAT Handover Analysis
9-Dec-13, Page 24
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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 25/58
iRAT Handover Analysis
9-Dec-13, Page 25
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 26/58
iRAT Handover Analysis
9-Dec-13, Page 26
Figure 22. RRC Cell Change Order from UTRAN Command
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 27/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 27
Radio Measurements (Al l 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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 28/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 28
Traff ic 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 inter-
RAT 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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 29/58
iRAT Handover Analysis
9-Dec-13, Page 29
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 30/58
iRAT Handover Analysis
9-Dec-13, Page 30
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 31/58
iRAT Handover Analysis
9-Dec-13, Page 31
Sort and Fi l ter Funct ions
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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 32/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 32
Troubleshoo ting iRAT HO Usin g Dashboard K PIs
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 start ingpoints 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 sub-
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 33/58
iRAT Handover Analysis
9-Dec-13, Page 33
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.
Al ternate Entry Poin t
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 34/58
iRAT Handover Analysis
9-Dec-13, Page 34
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 Analysi s
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 35/58
iRAT Handover Analysis
9-Dec-13, Page 35
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 sub-
causes. You can also open the call table for one individual sub-cause by right-
clicking 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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 36/58
iRAT Handover Analysis
9-Dec-13, Page 36
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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 37/58
iRAT Handover Analysis
9-Dec-13, Page 37
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"
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 38/58
iRAT Handover Analysis
9-Dec-13, Page 38
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 RadioInterface 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 failseach time.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 39/58
iRAT Handover Analysis
9-Dec-13, Page 39
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 withUE lost"
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 40/58
iRAT Handover Analysis
9-Dec-13, Page 40
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 41/58
iRAT Handover Analysis
9-Dec-13, Page 41
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 42/58
iRAT Handover Analysis
9-Dec-13, Page 42
A General v iew of th e GSM RSSI in th e 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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 43/58
iRAT Handover Analysis
9-Dec-13, Page 43
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 44/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 44
RAN Optimization wit h i RAT 3G-2G Handover
Troub leshoot and Optimi ze inter-RAT 3G-2G Handov er
Problem Statement: Failed inter-RAT Handovers prevents the subscriber from
being transferred to an environment with better radio conditions. Thus, the userplane 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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 45/58
iRAT Handover Analysis
9-Dec-13, Page 45
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.
How to proceed in TrendNavigate:
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 a 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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 46/58
iRAT Handover Analysis
9-Dec-13, Page 46
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.
How to proceed in TrendNavigate:
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-to-
date 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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 47/58
iRAT Handover Analysis
9-Dec-13, Page 47
Figure 49. iRAT HO Matrix. Radio Measurements (All Reports)
Reduce Inter-RAT and Intra-RAT Location Toggli ng
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
How to proceed in TrendNavigate:
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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 48/58
iRAT Handover Analysis
9-Dec-13, Page 48
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 Ping-
Pong) 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…
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 49/58
iRAT Handover Analysis
9-Dec-13, Page 49
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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 50/58
iRAT Handover Analysis
9-Dec-13, Page 50
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 withsimilar 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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 51/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 51
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 52/58
iRAT Handover Analysis
9-Dec-13, Page 52
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 53/58
iRAT Handover Analysis
9-Dec-13, Page 53
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.
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 54/58
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 55/58
iRAT Handover Analysis
9-Dec-13, Page 55
iRAT Inter radio access technology
KPIKey Performance Indicator
LACLocation 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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 56/58
iRAT Handover Analysis
9-Dec-13, Page 56
RNC Radio Network Controller
RNTI Radio Network Temporary Identity
RRC Radio Resource Control
RSSIReceived Signal Strength Indicator
SACService Area Code
SCScrambling 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
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 57/58
Application Paper: iRAT Handover Analysis
9-Dec-13, Page 57
Technical Support
For support contact your regional Technical Assistance Center:
EMEA
phone +373 22 879020
fax +373 22 879001
e-mail [email protected]
Americas
phone +1 469 330 4580
e-mail [email protected]
Asia Pacific
phone +86 21 389 60420
e-mail [email protected]
8/18/2019 UMTS IRAT Handover Analsysis
http://slidepdf.com/reader/full/umts-irat-handover-analsysis 58/58
iRAT Handover Analysis
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.