Professional Documents
Culture Documents
Application Paper: iRAT Handover Analysis
Application Paper: iRAT Handover Analysis
Analysis
Introduction
NSA Software allows you to monitor all incoming and outgoing legs of:
• 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
• How to find an iRAT handover and cell change in the NSA Call Table
9-Dec-13, Page 1
Application Paper: iRAT Handover
Analysis
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
iRAT Handover Analysis
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.
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.
9-Dec-13, Page 3
iRAT Handover Analysis
interface and later UTRAN. The 2G MSC receives a BSSMAP
Handover Request Acknowledge message that contains the DTAP
Handover Command.
9-Dec-13, Page 4
iRAT Handover Analysis
9-Dec-13, Page 5
iRAT Handover Analysis
9-Dec-13, Page 6
iRAT Handover Analysis
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
iRAT Handover Analysis
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".
9-Dec-13, Page 8
iRAT Handover Analysis
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.
9-Dec-13, Page 9
iRAT Handover Analysis
shown in the figure. The message often contains the IMSI, but this is not a
mandatory parameter.
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
iRAT Handover Analysis
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.
9-Dec-13, Page 11
iRAT Handover Analysis
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.
9-Dec-13, Page 12
iRAT Handover Analysis
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 DCH’s 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 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
Application Paper: iRAT Handover
Analysis
iRAT HO Analysis
In the iRAT 3G-2G Handover Matrix different panes/chapters are used to
display the data. Main chapters are:
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
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
Application Paper: iRAT Handover
Analysis
The iRAT HO 3G-2G Handover Matrix consists of several sections that are
described below:
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).
Cell name, uARFCN and Primary Scrambling Code (Primary SC) are also
derived from cell info file.
9-Dec-13, Page 15
iRAT Handover Analysis
Target Cell 2G–2G Cell Identity and Radio Quality before 3G-2G
Handover
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
iRAT Handover Analysis
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
TRX 3 Cell 2
BTS m
Cell n
TRX 255
9-Dec-13, Page 17
iRAT Handover Analysis
+--------------------------------------------+------------------------------------------+
|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 gSM-MeasuredResults |
|2.1.2.1.1.1.2.1 GSMCarrierRSSI |85 dBm + SCALE to 84 dBm + SCALE |
|2.1.2.1.1.1.2.2 bsicReported |
|2.1.2.1.1.1.2.2.1 verifiedBSIC |2 |
|2.1.2.1.1.1.3 gSM-MeasuredResults |
|2.1.2.1.1.1.3.1 GSMCarrierRSSI |86 dBm + SCALE to 85 dBm + SCALE |
|2.1.2.1.1.1.3.2 bsicReported |
|2.1.2.1.1.1.3.2.1 verifiedBSIC |3 |
|2.1.2.1.1.1.4 gSM-MeasuredResults |
|2.1.2.1.1.1.4.1 GSMCarrierRSSI |94 dBm + SCALE to 93 dBm + SCALE |
|2.1.2.1.1.1.4.2 bsicReported |
|2.1.2.1.1.1.4.2.1 nonVerifiedBSIC |51 |
|2.1.2.1.1.1.5 gSM-MeasuredResults |
|2.1.2.1.1.1.5.1 GSMCarrierRSSI |95 dBm + SCALE to 94 dBm + SCALE |
|2.1.2.1.1.1.5.2 bsicReported |
|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.1.3.1.2.2 cellToReport |
|2.1.3.1.2.2.1 bsicReported |
|2.1.3.1.2.2.1.1 verifiedBSIC |2 |
|2.1.3.1.2.3 cellToReport |
|2.1.3.1.2.3.1 bsicReported |
|2.1.3.1.2.3.1.1 verifiedBSIC |3 |
Figure 12. Message Example 3: RRC Measurement Report with iRAT measurement results
9-Dec-13, Page 18
iRAT Handover Analysis
+--------------------------------------------+------------------------------------------+
|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:
9-Dec-13, Page 19
iRAT Handover Analysis
To request assignment of radio resources in the 2G RAN the RNC starts the
Relocation Preparation procedure.
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:
9-Dec-13, Page 20
iRAT Handover Analysis
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
iRAT Handover Analysis
Figure 16 shows a sample call with multiple HO execution attempts that drops
at the end because of the handover failures.
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.
9-Dec-13, Page 22
iRAT Handover Analysis
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.
9-Dec-13, Page 23
iRAT Handover Analysis
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:
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:
9-Dec-13, Page 24
iRAT Handover Analysis
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.
9-Dec-13, Page 25
iRAT Handover Analysis
9-Dec-13, Page 26
Application Paper: iRAT Handover
Analysis
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.
9-Dec-13, Page 27
Application Paper: iRAT Handover
Analysis
Traffic Load
The Traffic Load pane, in the iRAT 3G-2G Handover Matrix, displays the
following KPIs (for the 3G source cell only).
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
9-Dec-13, Page 28
iRAT Handover Analysis
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
iRAT Handover Analysis
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 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
iRAT Handover Analysis
The following filters are available within the iRAT HO Matrix which allow to sort
and filter the top 10 (source) cells with:
9-Dec-13, Page 31
Application Paper: iRAT Handover
Analysis
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.
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-
9-Dec-13, Page 32
iRAT Handover Analysis
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.
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.
9-Dec-13, Page 33
iRAT Handover Analysis
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.
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
iRAT Handover Analysis
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:
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
iRAT Handover Analysis
Root Causes
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.
9-Dec-13, Page 36
iRAT Handover Analysis
But the measurement report also reveals that the strength of GSM RSSI is also
not so good: (See Figure 32)
Figure 33. Handover from UTRAN Failure, cause "Physical Channel Failure"
9-Dec-13, Page 37
iRAT Handover Analysis
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
iRAT Handover Analysis
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
iRAT Handover Analysis
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.
9-Dec-13, Page 40
iRAT Handover Analysis
This analysis has been performed over several calls and was found that:
• Some of the 2G neighbors are reported having good GSM RSSI, but
still the iRAT HO fails.
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.
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
iRAT Handover Analysis
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.
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.
9-Dec-13, Page 42
iRAT Handover Analysis
GSM RSSI for the top runner cell-id 22231 is shown in figure 20 below:
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
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
Application Paper: iRAT Handover
Analysis
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
iRAT Handover Analysis
Figure 46. Source/ Target Cell and Radio Conditions View at HO decision
9-Dec-13, Page 45
iRAT Handover Analysis
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.
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
iRAT Handover Analysis
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.
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”.
9-Dec-13, Page 47
iRAT Handover Analysis
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.
b) Now there is a possibility to verify this thesis in the following way using
the call table:
Sample: it can be seen same subscriber in same cell registering again and
again…
9-Dec-13, Page 48
iRAT Handover Analysis
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.
9-Dec-13, Page 49
iRAT Handover Analysis
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.
9-Dec-13, Page 50
Application Paper: iRAT Handover
Analysis
Thus any call that contains entries in the Handover Procedure column contains
intersystem cell changes.
9-Dec-13, Page 51
iRAT Handover Analysis
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.
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
iRAT Handover Analysis
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
Application Paper: iRAT Handover
Analysis
Abbreviations
CS Circuit Switched
DL Down link
Direct Mobile Transfer Application Part
DMTAP
Chip Energy over Noise (measured on CPICH)
Ec/N0
Global System for Mobile Communications
GSM
Handover
HO
ID Identifier
9-Dec-13, Page 54
iRAT Handover Analysis
PS Packet Switched
RB Radio Bearer
RL Radio link
9-Dec-13, Page 55
iRAT Handover Analysis
UE User Equipment
UL Up link
UP User Plane
9-Dec-13, Page 56
Application Paper: iRAT Handover
Analysis
Technical Support
For support contact your regional Technical Assistance Center:
EMEA
phone +373 22 879020
e-mail Tektronix-nd-tac-emea@tek.com
Americas
phone +1 469 330 4580
e-mail Tektronix-ND-TAC-US@tek.com
Asia Pacific
phone +86 21 389 60420
e-mail Tektronix-ND-TAC-AsiaPac@tek.com
9-Dec-13, Page 57
iRAT Handover Analysis
Tektronix Communications
3033 W President George Bush Highway
Plano, TX 75075
Phone: + 1 469 330 4000
Fax: + 1 469 330 4001
9-Dec-13, Page 58