Optimization Guidelines: Retainability in Huawei

INSTRUO OPERACIONAL para MANUAL
Assunto Referncia
OPTIMIZATION GUIDELINES: RETAINABILITY in HUAWEI DEO.OTM.IOP3023
Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

QCES Marcio Pereira Laurindo Santos Draft01 07/May/2010 07/May/2010 1/37
Optimization Guidelines:
Retainability in Huawei
CONTENTS
1 0BINTRODUCTION .......................................................................................................................... 3
2 1BRETAINABILITY .......................................................................................................................... 4
2.1 6BCell Update ............................................................................................................................................ 4
2.2 6BCS drop versus PS drop ....................................................................................................................... 5
3 2BRETAINABILITY KPIs (Key Performance Indicators) ............................................................... 7
3.1 8BHigh Level KPIs .................................................................................................................................... 7
3.1.1 14BRetainability Rate - RR (%) ........................................................................................................................7
3.1.2 15BDropped Call Rate - DCR (%) ....................................................................................................................8
3.1.2.1 32BUCS DCR (%) ..............................................................................................................................8
3.1.2.2 32BUSpeech DCR (%) .......................................................................................................................8
3.1.2.3 33BUVideo DCR (%) .........................................................................................................................9
3.1.2.4 34BUStreaming DCR (%) ..................................................................................................................9
3.1.2.5 34BUPS DCR (%) ..............................................................................................................................9
3.1.2.6 39BUFurther considerations on PS/HS DCR (%) ...............................................................................9
3.1.2.7 36BUHSDPA DCR (%) ....................................................................................................................10
3.1.2.8 37BUHSUPA DCR (%) ....................................................................................................................10
3.1.3 16BMinutes per Drop ......................................................................................................................................11
3.1.3.1 40BUVoice Minutes per drop ...........................................................................................................11
3.1.3.2 41BUVideo Minutes per drop ...........................................................................................................11
3.1.3.3 42BUHS Minutes per drop ...............................................................................................................11
3.1.4 17BDrops per Erlang (or Drops per Hour) ......................................................................................................12
3.1.4.1 43BUVoice drops per hour ...............................................................................................................12
3.1.4.2 44BUVideo drops per hour ...............................................................................................................12
3.1.4.3 45BUHS drops per hour ....................................................................................................................12
3.1.5 18BOverall Service Retainability - OSRET (%) .............................................................................................12
3.2 9BMedium Level KPIs: Voice Drop Reasons ....................................................................................... 13
3.2.1 19BUL SYNCHRONIZATION Speech DCR (%) .........................................................................................14
3.2.2 20BSOFT HANDOVER Speech DCR (%).....................................................................................................14
3.2.3 21BCONGESTION Speech DCR (%) ............................................................................................................15
3.2.4 22BCS IRAT HO Failure Rate (%) .................................................................................................................15
3.2.5 22BCS IRAT HO Preparation Failures Rate (%) ............................................................................................16
3.2.6 23B22CS IRAT HO Execution Failures Rate (%) ..........................................................................................18
3.2.7 IRAT HO DCR (%) ........................................................................................................................................18
DEO - Otimizao de Rede de Acesso

Assunto Referncia

3.2.8 23BOTHERS Speech DCR (%) ??? ................................................................................................................19

4 3BPERFORMANCE ANALYSIS..................................................................................................... 20
4.1 10BRadio Coverage Issues ...................................................................................................................... 20
4.1.1 24BUplink Problems .......................................................................................................................................20
4.1.1.1 47BURadio Connection Supervision for UE in Cell_DCH ..............................................................20
4.1.1.2 47BURadio Connection Supervision for UE in Cell_FACH ............................................................21
4.1.2 25BDownlink Problems ..................................................................................................................................22
4.1.3 26BLayer 2 Failures triggered by Coverage ....................................................................................................22
4.1.4 27BCritical radio procedure failures due to coverage .....................................................................................23
4.1.5 28BRadio Environment Evaluation .................................................................................................................23
4.1.5.1 48BUPrimary Straight Indicators ......................................................................................................23
4.1.5.2 49BUSecondary Indicators ...............................................................................................................23
4.1.5.3 50BUW-MRR ...................................................................................................................................23
4.1.5.4 51BUGPEH for Radio Coverage Analysis ??? what Huawei has .....................................................24
4.1.5.5 52BURRC measurement Reports .....................................................................................................25
4.2 11BMobility Issues .................................................................................................................................. 25
4.2.1 29BSSoft/Softer Handover Failures ................................................................................................................26
4.2.1.1 46BUSOFTER HANDOVER Speech Success Ratio (%) ...............................................................27
4.2.1.2 47BUSOFT HANDOVER Speech Success Ratio (%) ....................................................................28
4.2.2 30BMissing Neighbour Relations ...................................................................................................................28
4.2.3 31BIRAT Handover Failures ..........................................................................................................................28
4.2.4 17BIF Handover Failures ................................................................................................................................31
4.3 12BCapacity Issues: Congestion Monitoring (from CAPACITY doc) ............................................... 32
4.4 13BOther Faults ...................................................................................................................................... 32
5 4BREFERENCES ............................................................................................................................. 34
6 5BANNEX I: Call Reestablishment (Cell Update procedure) ......................................................... 35
7 5BANNEX II: UL/DL Radio Synchronization ................................................................................ 36
7.1 13BDL Synchronization .......................................................................................................................... 36
7.2 13BUL Synchronization .......................................................................................................................... 37

Assunto Referncia

1 INTRODUCTION
0B
This series of Optimization Guidelines covers all the main topics regarding
Performance Monitoring & Analysis
Configuration settings
Troubleshooting
Refer to the internal Claro document Optimization Process (DEO.OTM.IOP3000), for a summary of 3G WCDMA Radio
Access Network Optimization Basics.
This specific document focuses on RETAINABILITY and its specifics within HUAWEI infrastructure (RAN10).
Target users for this document are all personnel requiring a detailed description of this process (Retainability
Optimization), as well as configuration managers who require details to control the functions and optimize parameter
settings. It is assumed that users of this document have a working knowledge of 3G telecommunications and are
familiar with WCDMA.
Document Revision Control
Revision Date Author Changes

Draft01 07-May-2010 QCES/Huawei First Draft of the document

Assunto Referncia

2 RETAINABILITY
1B
Retainability is the ability of a service to be kept once it was accessed under given conditions for a requested
period of time. In other words, it is the probability that a service, once obtained, will continue to be provided under
given conditions for a given time duration.
Target is to get a 100% Retainability, i.e., all connections maintained until their normal release.
Poor Retainability is typically due to
Bad Handover performance (soft/softer/Iur/IFHO/IRAT) and missing neighbor cell
UL/DL imbalance
Incorrect parameter settings (power, admission, release)
Congestion
Radio environment impact (corner effect, fast Ec/No drop, Pilot pollution, etc)
Node Hardware/Software failure
Iub (E1s) Congestion
Retainability is to be monitored independently for the different RAB types (e.g. Speech, CS Video, PS Interactive R99,
PS Interactive HSDPA, etc.) as in certain situations only one of the RAB types will be affected.
2.1 Cell Update

6B
In 3G a new mechanism is available to rescue some dropped calls (both CS and PS) due to RL Failure: Call
Reestablishment by Cell Update procedure. Refer to ANNEX I for further details.
If timer T314 is set higher than 0, Voice calls that suffer from a RL Failure are not considered dropped till timer T314
expires and the call could not be reestablished by the Cell Update Procedure.
Similarly, if timer T315 is set higher than 0, PS calls that suffer from a RL Failure are not considered dropped till
timer T315 expires and the call could not be reestablished by the Cell Update Procedure.
We could say that in both cases, CS and PS, those RL Failures that can be rescued are just system-perceived drops,
but not user-perceived drops, as the user does not have to perform any additional manual operations like for
example manual re-activation of the PDP context. In reality, during the Cell Update procedure (T314 or T315 seconds),
Voice calls will be perceived as silent by the user, and PS data sessions may suffer from delays and lower
throughputs, but the fact is that the call does not drop, and it is not counted by the RAB releases counters (and
therefore, neither as a drop).
In Huawei infrastructure, both T314 and T315 are changeable. This Cell Update mechanism may be available for Voice
and PS data calls (necessarily both at the same time; this is a Huawei limitation; it is not possible to get it enabled only
for PS data calls or only for Voice calls).
In case it is not enabled, this means that all RL Failures in DL will finally lead to a drop:
o for Voice calls, it would be user and system perceived
o for PS data calls it would only be system perceived, thanks to additional implicit re-establishment
mechanisms (Paging/Service Request)
o RAB release counters and drops- increased
In case it is enabled, those RL Failures that are rescued will be system but not user-perceived, and the
abnormal RAB release counter (=drops) will not be increased.
As some other vendors may have the Cell Update mechanism de-activated for PS, the optimization team should keep
in mind these considerations when comparing PS DCR (%) in different vendors: usually worst in those ones with this

Assunto Referncia

functionality disabled. Nevertheless, this worst behavior in the KPI usually does not match the user perception (that is
typically good) thanks to those additional implicit re-establishment mechanisms (Paging/Service Request).
2.2 CS drop versus PS drop

6B
One important difference between the Circuit Switched (CS) and Packet Switched (PS) domains is that in the CS
domain, the end-to-end services (voice, video-telephony, CS data) can be maintained only if all lower layer links are
maintained. For example, if the Radio Bearer is broken during a voice call, the network may allow only limited time
(T314) to perform a Cell Update before terminating the end-user application.
For PS data, to accommodate the bursty nature of the traffic, links from different layers can be independent. For
example, the Packet Data Protocol (PDP) context is preserved, while the Radio and Radio Access Bearers are
reconfigured or disconnected during low activity periods. The behavior of an FTP session is another example; when
Radio Bearers are dropped or experience a high block error rate, the FTP might time out, even if the PDP context is
active.
The interdependence between layers complicates data service optimization; all layers must be considered.
A single PS call (= a single PS RAB) goes dynamically through different phases (DCH R99, HSDPA, EUL, Cell_FACH)
based on different radio configurations. It may also go to IDLE (with pdp context preserved) due to inactivity
periods. It is the system that re-establishes the lower layer connections, with no user intervention.
When the PS call goes to Idle with pdp context preserved due to inactivity, the PS RAB is considered normally
released, and there will be a new process of call establishment starting with an RRC connection request, and RAB
establishment, etc. (but without the UPLINK DIRECT TRANSFER [SM: Activate PDP Context Request] as it was
preserved).
In case there is a RL Failure, the pdp context is also preserved and either Cell Update or implicit re-establishment
mechanisms (Paging/Service Request) will re-establish the lower layer connections with no user intervention. User
does not notice the call drop (but typically experiences low throughput or delay). So in terms of user perception (or

Assunto Referncia

Data Application DCR %, or Data Session DCR %, or PDP context DCR %), the retainability is not impacted. These
latest metrics (from an operational point of view) can only be derived from PS CORE (GGSN) counters.
In terms of Abnormal RAB Releases due to RL Failure, typically those vendors with CU enabled (NSN & Huawei, for
example) will not increase the counter (in fact, they will not increase any RAB Release counter nor normal neither
abnormal-; RAB is not released); those ones with CU disabled will (Huawei, for instance). So, as already anticipated,
you can expect a worst KPI PS DCR % performance in these last ones.

Assunto Referncia

3 RETAINABILITY KPIs (Key Performance Indicators)

2B
Below the main metrics used for Retainability Monitoring of a 3G WCDMA/UMTS Network, and their implementation
with Huawei counters.
Refer to SMART Documentation for further details on the actual implementation of these KPIs in the tool, together
with the additional considerations regarding:
Treatment of zeros in the denominators
Differentiation of PS: Global, R99, HS, EUL KPIs.
Considerations regarding SRNS Relocations and Outgoing Hard Handover
3.1 High Level KPIs

8B
3.1.1 Retainability Rate - RR (%)

14B
Based in statistical counters, it is possible to count every time a RAB is normally released, e.g.:
Call ended by UE or user control

(user generates a disconnect towards the CN:
Normal Release or UE Generated Signaling Connection Release)
Call ended because of any problem or action on the other part
(the monitored user receives a disconnect from the CN: Normal Release)
Call ended with cause Network Optimisation or Resource Optimisation Relocation
Connection ends because of User Inactivity (PS calls only)
Connection ends because the call is successfully transferred to another system (IRAT HO):
Successful Relocation.
and abnormally released (= DROP):
Call ended by the network for any other reason than NORMAL.
A global Retainability Rate (%) can be calculated as follows:
100 *
No of NormalRA BReleases
(No of NormalRA BReleases No of A bnormalRA BReleases)
However, it is common practice to use the Non Retainability Rate (NRR) instead, a.k.a. Dropped Call Rate (%),
that we will use throughout this document:
100 *
No of A bnormalRA BReleases
(No of NormalRA BReleases No of A bnormalRA BReleases)
As already stated, target is to keep Retainability Rate, RR (%) as close as possible to 100%, while target for NRR (%) is to
keep the DCR (%) as close as possible to 0%.

Assunto Referncia

3.1.2 Dropped Call Rate - DCR (%)

15B
It is the most common KPI for Retainability.
The value is dependent on the call duration: the shorter is the average call duration, the lower shall be the drop call
rate and vice versa. Any changes in the network that modify the call duration shall impact on the Drop Call Rate (e.g.
IRAT Handover thresholds for speech or inactivity timers for PS calls).
Counters available in Huawei for the Normal and Abnormal RAB Releases are:
Number of Normal RAB Releases Number of Abnormal RAB Releases

VS.RAB.Loss.CS.Norm VS.RAB.Loss.CS.RF + VS.RAB.Loss.CS.Abnorm + VS.CN.RAB.Loss.CS
VS.RAB.Loss.CS.Norm.AMR VS.RAB.Loss.CS.AMR
VS.Norm.Rel.CS.Conv.RB.64 VS.RAB.Loss.CS.Conv64K
VS.Norm.Rel.CS.Str VS.Abnorm.Rel.CS.Str
VS.RAB.Loss.PS.Norm VS.RAB.Loss.PS.RF + VS.RAB.Loss.PS.Abnorm + VS.CN.RAB.Loss.PS
VS.Norm.Rel.PS.Conv VS.Abnorm.Rel.PS.Conv
VS.Norm.Rel.PS.Str VS.Abnorm.Rel.PS.Str
VS.HSDPA.RAB.Loss.Norm VS.HSDPA.RAB.Loss.RF + VS.HSDPA.RAB.Loss.Abnorm.NonRF
VS.HSDPA.RAB.Loss.Inactivity
VS.HSUPA.RAB.Loss.Norm VS.HSUPA.RAB.Loss.Abnorm
As all previous counters are available at cell level, all the DCR KPIs (%) introduced in the following sections will also be
available at cell level. As expected for High Level KPIs, they can be aggregated at nation, market/vendor, region, city,
RNC, cluster, levels.
3.1.2.1 32BU CS DCR (%)
(VS.RAB.Lo ss.CS.Abno rm + VS.RAB.Los s.CS.RF VS.CN.RAB. Loss.CS)

100 *
(VS.RAB.Lo ss.CS.RF + VS.RAB.Loss.CS.Abno rm + VS.CN.RAB .Loss.CS VS.RAB.Los s.CS.Norm)
The usage of VS.CN.RAB.Loss.CS in the formula is to be confirmed by Huawei. [Pending Huawei feedback]
Another approach, considering just Voice and Video, could be:
(VS.RAB.Lo ss.CS.AMR + VS.RAB.Loss.CS.Conv 64K)

100 *
(VS.RAB.Lo ss.CS.AMR + VS.RAB.Loss.CS.Norm .AMR + VS.RAB.Loss.CS.Conv 64K + VS.Norm.Re l.CS.Conv. RB.64)
High value (e.g. >2%) indicates retainability issues for CS connections.
3.1.2.2 32BU Speech DCR (%)
(VS.RAB.Lo ss.CS.AMR)
100 *
(VS.RAB.Lo ss.CS.AMR + VS.RAB.Loss.CS.Norm .AMR)
High value (e.g. >2%) indicates retainability issues for Speech connections.

Assunto Referncia

3.1.2.3 33BU Video DCR (%)
(VS.RAB.Lo ss.CS.Conv 64K)

100 *
(VS.RAB.Lo ss.CS.Conv 64K + VS.Norm.Re l.CS.Conv. RB.64)
High value (e.g. >2%) indicates retainability issues for Video CS64 connections.
3.1.2.4 34BU Streaming DCR (%)
(VS.Abnorm .Rel.CS.St r)
100 *
(VS.Abnorm .Rel.CS.St r VS.Norm.R el.CS.Str)
High value (e.g. >2%) indicates retainability issues for CS Streaming connections.
(VS.Abnorm .Rel.PS.St r)
100 *
(VS.Abnorm .Rel.PS.St r VS.Norm.R el.PS.Str)
High value (e.g. >2%) indicates retainability issues for PS Streaming connections.
3.1.2.5 34BU PS DCR (%)

(VS.RAB.Lo ss.PS.RF + VS.RAB.Loss.PS.Abno rm VS.CN.RAB. Loss.PS)
100 *
(VS.RAB.Lo ss.PS.RF + VS.RAB.Los s.PS.Abnor m + VS.CN.RAB .Loss.PS VS.RAB.Los s.PS.Norm)
The usage of VS.CN.RAB.Loss.PS in the formula is to be confirmed by Huawei. [Pending Huawei feedback]
High value (e.g. >2%) indicates retainability issues for PS connections.
This is an overall PS RAB DCR (%) based in counters from Measurement type Service Level. Typically, CU
mechanism is enabled for PS and rescues many potential RAB abnormal releases due to RL Failure (RADIO), so values
for this metric are commonly very low (i.e., very good).
3.1.2.6 39BU Further considerations on PS/HS DCR (%)
The Drop Call Rate for PS connections (Packet Interactive/Background) requires a special consideration.
Counters in the formula above refer to RAB Releases (Normal or Abnormal) of the PS connection at any active
phase, no matter if in dedicate or common channels.
In order to calculate the Drop Call Rate for each single PS phase (HSDPA or EUL or FACH or PS R99) you need to
count all the transitions at the end of that specific phase. For instance, to calculate the HS DCR % you should consider
all the possibilities:

Assunto Referncia

100 *
HS_A bnormal_Release
(HS_A bnormal_Release HS_Normal_Release Success_C hannel_Sw itching_from _HS_to_any_other_RA B)
If counters for all those transitions are not available, then the KPI could be not that meaningful.
3.1.2.7 36BU HSDPA DCR (%)
Typically calculated as:
100 *
(VS.HSDPA. RAB.Loss.Abnorm.NonR F + VS.HSDPA.R AB.Loss.RF)
(VS.HSDPA. RAB.Loss.Abnorm.NonR F + VS.HSDPA. RAB.Loss.RF + VS.HSDPA.R AB.Loss.Norm + VS.HSDPA. RAB.Loss.Inactivity)
This metric above does not consider the channel switching from HSDPA to any other PS RAB state. So it is highly
recommended to use the following formula instead:
(VS.HSDPA. RAB.Loss.Abnorm.NonR F + VS.HSDPA.R AB.Loss.RF)

100 *
VS.HSDPA.R AB.Loss.Abnorm.NonRF + VS.HSDPA. RAB.Loss.RF + VS.HSDPA.R AB.Loss.Norm +
VS.HSDPA.R AB.Loss.Inactivity VS.HSDPA.C hR.HSDSCHt oDCH + VS.HSDPA. ChR.HSDSCH toFACH +
VS.HSDPA.H HO.H2D.Suc cOutIntraRNCIntraFre q + VS.HSDPA. HHO.H2D.Su ccOutIntraRNCInterFr eq

High value (e.g. >2%) indicates retainability issues for HSDPA connections.
The usage of VS.HSDPA.RAB.Loss.Inactivity in the formula is to be confirmed by Huawei. [Pending Huawei feedback]
3.1.2.8 37BU HSUPA DCR (%)
Typically calculated as:

100 *
VS.HSUPA.R AB.Loss.Abnorm
(VS.HSUPA. RAB.Loss.Abnorm + VS.HSUPA.R AB.Loss.Norm)
This metric above does not consider the channel switching from HSUPA to any other PS RAB state. So it is highly
recommended to use the following formula instead:
VS.HSUPA.R AB.Loss.Abnorm
100 *
VS.HSUPA.R AB.Loss.Abnorm + VS.HSUPA.R AB.Loss.Norm
VS.HSUPA.C hR.IntraCe ll.EDCHtoD CH.Succ + VS.HSUPA. ChR.IntraF req.EDCHto DCH.Succ +
VS.HSUPA.C hR.InterFr eq.EDCHtoD CH.Succ + VS.HSUPA. ChR.EDCHto FACH.Succ

High value (e.g. >2%) indicates retainability issues for HSUPA connections.

Assunto Referncia

3.1.3 Minutes per Drop

16B
This KPI (Traffic Drop Ratio, using Huawei terminology) gives the average time length (in minutes) between 2
consecutive drops. In other words: It is the average number of minutes of a continuous service before a RAB is
abnormally dropped.
Traffic Erlangs of a RA B* 60
Number of A bnormalRA BReleases
i.e., Erlangs translated into minutes divided by the number of drops.
As all High Level KPIs, it can be produced at nation, market/vendor, region, city, RNC, cluster, levels , but also on cell
basis (as both elemnets involved in the formula, erlangs and drops, can be extracted from the UtranCell MO counters).
Please also note that:
It is not dependent on the call duration.

It can be used to evaluate the retainability of each single phase of a call (HSDPA, DCH, and FACH).
Target values are difficult to define. It is better used to analyze performance trends.
The values are instable in case of good performances (the indicator points to infinite for a perfect network).
A certain level of traffic is needed to have a stable indicator.
Formulas to calculate the Minutes per drop for different call types are shown next. In all the cases:
ROP (Report Output Period) = Measurement time in minutes (examples: 15, 30, hour = 60, day = 1440)
3.1.3.1 40BU Voice Minutes per drop
V oice Traffic Erlangs * 60 RO P pmSumBestAmr12200RabEstablish

60 * pmSamplesBestA mr12200RabEstablish * 60 pmNoSy stemRabReleaseSpeech
Number of A bnormalV oiceReleases
pmSumBestAmr12200RabEstablish
RO P*
pmSamplesBestA mr12200RabEstablish pmNoSy stemRabReleaseSpeech

3.1.3.2 41BU Video Minutes per drop
pmSumBestCs64RabEstablish
RO P*
pmSamplesBestC s64RabEstablish pmNoSy stemRabReleaseC s64

3.1.3.3 42BU HS Minutes per drop
pmSumBestPsHsA dchRabEstablish
RO P*
pmSamplesBestP sHsA dchRabEstablish pmNoSy stemRbReleaseHs


Assunto Referncia

3.1.4 Drops per Erlang (or Drops per Hour)

17B
It is the average number of dropped calls per 1 hour of connection.
Number of A bnormalRA BReleases

Traffic Erlangs of a RA B* 60
i.e., just the inverse of the previous KPI (Minutes per drop).
It is not often used because it is not easily mapped on the user perception.
It is not dependent on the call duration.
It is more stable than Minutes per Drop in case of good values.
3.1.4.1 43BU Voice drops per hour
Number of A bnormalV oiceReleases RO P pmSumBestAmr12200RabEstablish

pmNoSy stemRabReleaseSpeech 60 * pmSamplesBestA mr12200RabEstablish * 60
V oice Traffic Erlangs * 60
pmSumBestAmr12200RabEstablish * RO P
pmNoSy stemRabReleaseSpeech
pmSamplesBestA mr12200RabEstablish
3.1.4.2 44BU Video drops per hour
pmSumBestCs64RabEstablish * RO P
pmNoSy stemRabReleaseC s64
pmSamplesBestC s64RabEstablish
3.1.4.3 45BU HS drops per hour
pmSumBestPsHsA dchRabEstablish * RO P
pmNoSy stemRbReleaseHs
pmSamplesBestP sHsA dchRabEstablish
3.1.5 Overall Service Retainability - OSRET (%)

18B
Since there are many different services defined in UMTS and each one can have a different retainability at any time,
an overall service reatainability can be defined to obtain an overall measure of network retainability averaged over all
services. This metric can be used in case one single measurement is to be applied to sort out the worst overall cells in
terms of drops.
The OSRET criterion will be based on a weighted averaging of the retainability for the CS and PS services supported by
the cell. The weighting factors will be chosen to be the demand for the service given by the number of RAB Establish
attempts for that service.

Assunto Referncia

OSRET = 100 * [(CS DCR * Total CS Releases) + (PS DCR * Total PS Releases)] / Total CS & PS Releases
where:
CS/PS DCR = Dropped Call Rate, as described in the previous section.
Or simplifying:
100 * {[(CS Abnormal Releases / CS Normal & Abnormal Releases) * CS Normal & Abnormal Releases ] +
[(PS Abnormal Releases / PS Normal & Abnormal Releases) * PS Normal & Abnormal Releases ]} /
(CS Normal & Abnormal Releases + PS Normal & Abnormal Releases) =
100 * (CS Abnormal Releases + PS Abnormal Releases) /

(CS Normal & Abnormal Releases + PS Normal & Abnormal Releases)
The KPI can be built for Huawei in the following way:
VS.RAB.Los s.CS.RF + VS.RAB.Loss.CS.Abno rm VS.CN.RAB. Loss.CS

100 *
VS.RAB.Los s.PS.RF + VS.RAB.Loss.PS.Abno rm VS.CN.RAB. Loss.PS
VS.RAB.Los s.CS.RF + VS.RAB.Los s.CS.Abnor m + VS.CN.RAB .Loss.CS VS.RAB.Los s.CS.Norm
VS.RAB.Los s.PS.RF + VS.RAB.Los s.PS.Abnor m + VS.CN.RAB .Loss.PS VS.RAB.Los s.PS.Norm
The usage of VS.CN.RAB.Loss.PS and VS.CN.RAB.Loss.PS in the formula above is to be confirmed by Huawei.
[Pending Huawei feedback]
3.2 Medium Level KPIs: Voice Drop Reasons

9B
In order to dig deeper into the different reasons for the drops detected by the KPIs described so far, we can build
the following Medium Level KPIs based in the relationships shown between all the measurements items:
CS DROPS PS DROPS
CS RF drops (= VS.RAB.Loss.CS.RF) PS RF drops (= VS.RAB.Loss.PS.RF)

o VS.RAB.Loss.CS.RF.RLCRst o VS.RAB.Loss.PS.RF.RLCRst
= VS.RAB.Loss.CS.SRBReset = VS.RAB.Loss.PS.SRBReset
o VS.RAB.Loss.CS.RF.ULSync + VS.RAB.Loss.PS.TRBReset
o VS.RAB.Loss.CS.RF.UuNoReply o VS.RAB.Loss.PS.RF.ULSync
o VS.RAB.Loss.CS.RF.Oth o VS.RAB.Loss.PS.RF.UuNoReply
o VS.RAB.Loss.PS.RF.Oth
CS Non-RF drops (= VS.RAB.Loss.CS.Abnorm)
o VS.RAB.RelReqCS.OM PS Non-RF drops (= VS.RAB.Loss.PS.Abnorm)
o VS.RAB.RelReqCS.RABPreempt o VS.RAB.RelReqPS.OM
o VS.RAB.RelReqCS.UTRANgen o VS.RAB.RelReqPS.RABPreempt
o VS.RAB.Loss.CS.Aal2Loss o VS.RAB.Loss.PS.GTPULoss
o VS.RAB.Loss.CS.Congstion.CELL o VS.RAB.Loss.PS.Congstion.CELL
CS CN (Releases initiated by Core Network) PS CN (Releases initiated by Core Network)

= VS.CN.RAB.Loss.CS = VS.CN.RAB.Loss.PS
This set of reasons are analyzed further in Section 4 (Performance Analysis Low Level KPIs)

Assunto Referncia

3.2.1 CS RF DCR (%)

(Percentage of CS calls dropped due to RF Failure: "Radio Connection With UE Lost", "Failure in the Radio Interface
Procedure")
(VS.RAB.Lo ss.CS.RF)
100 *
High value (e.g. >2%) indicates retainability problems related to the RF environment.
3.2.1.1 47BU CS RF UL Synchronization DCR (%)
o VS.RAB.Loss.CS.RF.ULSync
In CELL_DCH state, the Radio Connection Supervision functionality is provided by means of two different algorithms:
the
100 *
3.2.2 CS Non-RF DCR (%)

20B
Procedure")

100 *
Procedure")

100 *

Assunto Referncia

VS.SHO.Drop.RNC: the number of call drops caused by soft handover in the RNC
During soft handover, when the RNC sends an ACTIVE SET UPDATE message to the UE, it starts the timer to wait for the
response from the UE. If the RNC does not receive the response until the timer expires, it releases this RRC connection,
which results in call drops. At this time, the RNC measures this item.
High value (e.g. >2%) indicates retainability problems related to the Active Set dynamic. A special and important
subset of these issues is the one caused by missing neighbours:
3.2.3 CONGESTION Speech DCR (%)

21B
(Percentage of Voice calls dropped due to cell congestion)
100 *
pmNoO fTermSpeechC ong
(pmNoNormalRabReleaseSpeech pmNoSy stemRabReleaseSpeech)
100 *
VS.RAB.Loss.CS.Congs tion.CELL
( VS.RAB.Loss.CS.Norm.AMR VS.RAB.Loss.CS.Congs tion.CELL
High value (e.g. >2%) indicates retainability problems related to cell congestion.
CD_Cong = VS.RAB.Loss.CS.Congstion.CELL + VS.RAB.Loss.PS.Congstion.CELL
3.2.4 CS IRAT HO Failure Rate (%)

22B
=100*(A-B)/B

Assunto Referncia

This KPI covers all IRAT Phases, including the Preparation one.
Hence, it provides an overall perception of the IRAT Performance
(VS.SRELOC .AttPrep.IRHOCS - VS.IRATHO.SuccCSOut. RNC)

100 *
VS.SRELOC. AttPrep.IRHOCS
3.2.5 22B CS IRAT HO Preparation Failures Rate (%)
22B CS IRAT HO Preparation Failures =A-C

Assunto Referncia

In order to isolate the issues, Global IRAT performance shown in the previous section should be analyzed per phases.
The first phase is: PREPARATION PHASE, i.e., how many RELOCATION REQUIRED messages sent by the RNC to CN
could not be converted into HO FROM UTRAN COMMAND sent to the UE.
In order to get a more accurate perception of the importance/impact of Preparation Failures in global IRAT
performance, we show now the ratio:
100 * Preparation Failures / Total IRAT Failures (including IRAT drops)
100*(A-C)/(A-B)
what give us an idea of the contribution of this type of Failures to the total number of IRAT HO Failures.
(VS.SRELOC .AttPrep.IRHOCS - VS.SRELOC. SuccPrep.IRHOCS)

100 *
(VS.SRELOC .AttPrep.IRHOCS - VS.IRATHO.SuccCSOut. RNC)

Assunto Referncia

3.2.6 23B22CS IRAT HO Execution Failures Rate (%)
=100*(D-B)/D
(VS.IRATHO.AttCSOut.RNC - VS.IRATHO.SuccCSOut. RNC)

100 *
VS.IRATHO.AttCSOut.RNC
3.2.7 IRAT HO DCR (%)
Focus of this paragraph is on the Execution Failures (i.e., execution + confirmation failures).
When a UE fails in getting the 2G system, it tries to return to 3G. If it succeeds reacquiring 3G, it
will then send a HO FROM UTRAN FAILURE to the network. This is an IRAT HO FAILURE, but
not a drop.
Sometimes though, the UE does not get the 2G system, nor reacquires the 3G one. It is then
considered LOST. This is what we call an IRAT drop.

Assunto Referncia

3.2.8 OTHERS Speech DCR (%) ???

23B
(All Voice drop reasons not considered in the previous categories are collected in this subset. We typically find here drops
related to faults in the Transport Network, or RNC, or CORE, etc.)
pmN oS y stemRabReleaseS peech

(pmN oS y sRelS peechU lSy nch
pmN oS y sRelS peechS oHo
pmN oO fTermS peechC ong
(pmN oA ttO utIratHoS peech pmN oS uccessO utIratHoS peech
pmN oF ailO utIratHoS peechReturnOldC hP hy C hFail
pmN oF ailO utIratHoS peechReturnOldC hN otP hyC hF ail

100 *
pmN oF ailO utIratHoS peechU eRejection))
(pmN oN ormalRabReleaseS peech pmN oS y stemRabReleaseS peech)
High value (e.g. >2%) indicates reatainability problems related to those other causes.
VS.RRC.AttConRel.Cng.RNC Number of RRC CONNECTION RELEASE messages from the RNC to UEs because of
congestion
VS.RRC.AttConRel.Preempt.RNC Number of RRC CONNECTION RELEASE messages from the RNC to UEs because of
preemptive release
VS.RRC.AttConRel.UsrIact.RNC: Number of RRC CONNECTION RELEASE messages from the RNC to UEs because of
user inactivity
VS.RRC.AttConRel.ReEstRj.RNC: Number of RRC CONNECTION RELEASE messages from the RNC to UEs because of
reestablishment rejection
VS.RRC.AttConRel.SigREst.RNC: Number of RRC CONNECTION RELEASE messages from the RNC to UEs because of
directed signaling connection re-establishment
VS.RRC.AttConRel.Unspec.RNC: Number of RRC CONNECTION RELEASE messages from the RNC to UEs because of
unspecified reason
Inter-Frequency Handover DCR (%)
(VS.HHO.InterFreq.AttOut - VS.HHO.InterFreq.SuccOut)
100 *
VS.HHO.InterFreq.AttOut

Assunto Referncia

4 PERFORMANCE ANALYSIS
3B
Following the Hierarchical KPIs methodology described in the Claro internal document Optimization process, Ref.
DEO.OTM.IOP.3000, once identified areas/nodes/cells showing bad performance through the overall KPIs defined
above, analysis to find out the cause root of the problem should be performed. To do so, we move towards an in-
depth analysis based in more detailed and specific raw counters (Low Level KPIs).
In the case of Ericsson infra, this analysis for Retainability issues will explore in the different directions pointed out by
the Medium Level KPIs described in the previous section for Voice calls:
Radio coverage issues:

o Uplink problems
o Downlink problems
Mobility issues:
o Handover failures
o Missing neighbour relations
o IRAT/IF handover issues
Capacity issues
Other faults
4.1 Radio Coverage Issues

10B
Any condition related to the the radio links propagation that can lead to lose the radio synchronization either from the
UE side (DOWNLINK) or from the RBS side (UPLINK).
Typically the problem is due to high pathloss and/or interference.
4.1.1 Uplink Problems

24B
From the network side (RBS) the uplink radio synchronization is handled by the Radio Connection Supervision
algorithm that monitors:
UEs in DCH state (also valid for HS and EUL)
UEs in cell FACH state or URA PCH state
4.1.1.1 47BU Radio Connection Supervision for UE in Cell_DCH
In CELL_DCH state, the Radio Connection Supervision functionality is provided by means of two different algorithms:
the Radio Link Set Supervision algorithm (RLS), located in the RBS, supports the Radio Connection Supervision
Evaluation algorithms (RCS), located in the SRNC.

Assunto Referncia

Radio Connection Supervision (RCS) Evaluation

The Radio Connection Supervision Evaluation algorithm keeps track of the synchronization status of the whole
radio connection by assigning a tag to every RLS.
Radio Link Set (RLS) Supervision

The RLS Supervision function supervises the synchronization status of the RLS provided by the RBS to the radio
connection, and reports any changes to the SRNC. When nOutSyncInd number of consecutive frames are out-of-
sync a timer rlFailureT is started and at expiry the RLS is considered out-of-sync and Radio Link Failure is
reported to the SRNC. When the RLS is out-of-sync and nInSyncInd number of frames are in-sync, the RLS is
considered in-sync and Radio Link Restore is reported to the SRNC.
The connection is considered lost by the RCS when the last RLS, for the connection, has been out-of-sync for a time
given by the parameter dchRcLostT. For a connection that includes HSDPA, the PS part of the connection is
considered lost by the RCS when the RLS that contains the Serving HS-DSCH cell, has been out-of-sync for a time
given by the parameter hsDschRcLostT. This means that when the hsDschRcLostT timer expires, an Iu Release
will be requested to the PS CN and when the dchRcLostT timer expires, an Iu Release will be requested to all
involved CNs.
4.1.1.2 47BU Radio Connection Supervision for UE in Cell_FACH
In CELL_FACH state, supervision is provided by monitoring periodic Cell Update messages sent by the UE. In URA_PCH
state periodic URA Update messages are sent instead.
The timer cchWaitCuT is started in the RNC whenever the UE enters the
CELL_FACH or URA_PCH state. The timer is stopped if the UE enters
CELL_DCH state and is reset to zero (but not stopped) upon receipt of a Cell
Update or URA Update from the UE. Upon expiry of the timer, the overall
release of the connection shall be triggered (abnormal release) by sending
Iu release request to the CN.
The time set on cchWaitCuT is longer than the one set on timer t305. The
timer t305 indicates how often the UE should send a Cell Update message
when in state CELL_FACH and how often to send the URA Update message
when in state URA_PCH.
Radio Connection Supervision Parameters :

U U
Final recommended setting under discussion. Trial ongoing to be completed.
Guard Time to detect rl failure in RBS: rlFailureT=10 (1s)

Number of consecutive bad frames: nOutSyncInd=20 (20 frames)
Number of consecutive good frames: nInSyncInd=1 (1 frame)
Timer in RNC for DCH: dchRcLostT=100 (10s)
Timer in RNC for HSDPA: hsDschRcLost=100 (10s)
Timer in RNC for FACH: cchWaitCuT=9 (45 min)
U Radio Connection Supervision Counters : U
Following 2 counters are available only at RNC level. They cannot be used for cell level troubleshooting:
pmNoReleaseDchRcLostT: Number of overall releases triggered by dchRcLostT expiry
pmNoReleaseCchWaitCuT: Number of overall releases triggered by cchWaitCuT expiry
Good counter for speech abnormal release identification at cell level:

Assunto Referncia

pmNoSysRelSpeechUlSynch: Number of system disconnects of a speech call for the best cell in the active set due to
lost UL synch.
Typical reasons for uplink problems:
High pathloss: UE is too far from the site or the propagation is blocked by obstacles. This condition could be
checked by evaluating some environment indicators
High UL interference: the RBS cannot receive the UE because of high UL interference. This condition can be
checked by UL RSSI monitoring counters:
o pmAverageRssi: check the 90th perc or the max value. Results higher than -95 dBm can be associated
with UL synch problems
o pmSumUlRssi / pmSamplesUlRssi: averaged value of UL RSSI. Values higher than -90 dBm can be
associated with UL synch problems
4.1.2 Downlink Problems

25B
Algorithms similar to uplink RCS are executed by the UE to monitor the downlink radio connection.
In case of DL synchronization lost the UE suspends the UL transmission without any notice. The final result will be
again an UL synchronization lost! For further details in UL/DL Synchronization Monitoring, refer to ANNEX II.
Typical reasons for downlink problems:
High pathloss: UE is too far from the site or the propagation is blocked by obstacles.
This condition could be checked by evaluating some environment indicators.
High DL interference: the quality of the signal received by the UE is poor even if the level is acceptable.
Fast environment changes due to UE mobility (outdoor/indoor transitions, corner effects) where the power
control is not capable to quickly adapt.
4.1.3 Layer 2 Failures triggered by Coverage

26B
Before the RCS timers expire in the RNC, the RLC protocol could detect the problem and trigger the connection release
because of RLC unrecoverable error.
pmNoRlcErrors: Number of RLC unrecoverable error (UTRAN) for any UEs on FACH, DCH or HS.
The errors are related with the RLC Acknowledged Mode that is used with the SRB associated to all RABs and with the
user data of PS Interactive connections. The error is typically triggered by a too high number of retransmission and the
wait timers of acknowledgment.

Assunto Referncia

4.1.4 Critical radio procedure failures due to coverage

27B
The most common radio procedure failed by coverage is the Active Set Update (SHO execution)
4.1.5 Radio Environment Evaluation

28B
Evaluating radio environment characteristics by counters:
Radio Environment straight indicators

Radio Environment Statistics (RES) and OSS W-MRR
4.1.5.1 48BU Primary Straight Indicators
CPICH RSCP (the signal strength of the pilot channel) Samples at low level (<-105 dBm) means high pathloss
problems. If the service should perform IRAT HO or IF HO (e.g. speech) this could be a problem in the IRAT/IF
settings.
CPICH Ec/No (the signal to total interference ratio) Samples at low level (<-13 dB) means poor signal quality. If the
service should perform IRAT HO or IF HO (e.g. speech) this could be a problem in the IRAT/IF settings.
UE Tx Power (the UE transmitted power) Samples at high level (>+15 dBm) means UL problems. It could be again
high pathloss or high UL interference.
4.1.5.2 49BU Secondary Indicators
Some clues to detect bad radio coverage conditions by standard counters:

Compressed Mode activation events (IRAT of IF measurement activation)/ Traffic Erlang of services that can
start CM (Speech, PsR99)
Compressed mode average number of users / Traffic Erlang of services that can start CM (Speech, PS R99)
Number of IRAT execution/ Normal RAB releases
CQI Distribution
4.1.5.3 50BU W-MRR

Assunto Referncia

pmResX is a PDF counter where the first item pmResX[0] is a number that describe the type of measurement
according to this schema:
Radio Environment Statistics (RES) settings (by OSS-W-MRR)

Define 16 measurements, each consisting of a Service + Measurement Quantity
Schedule the measurements
Define a recording area that is Cell Sets or Cells
Define sampling periods (how many seconds between two MRs: from 2 to 64)
Define UE fraction (how many UEs are ordered to make measurements: FULL, 1/2, 1/3, 1/4 and 1/5)
Manage recording activities: Start, stop and terminate recordings
Generate reports
4.1.5.4 51BU GPEH for Radio Coverage Analysis ??? what Huawei has
Some internal and external GPEH events carry some radio measurements that can be collected and correlated with
other events or used to build distributions:

Assunto Referncia

4.1.5.5 52BU RRC measurement Reports
In case RES is activated it will be possible to capture the periodical MRs containing the scheduled measurements. The
information can be correlated to the other GPEH events to provide a very advanced analysis.
RRC_RRC_CONNECTION_REQUEST - The message has to be fully decoded, then all the included measurement will be
available, in particular the Ec/No Value of the cell where the connection is requested. Sampling will be uniform all over
the cell. It could be helpful to correlate the Ec/No values with the RRC Establishment Cause to evaluate coverage for
different user activities
RRC_MEASUREMENT_REPORT - By counting the measurement reports for events 2d it is possible to count how many
times the connection was bad for RSCP or for Ec/No. To distinguish 2d-RSCP from 2d-Ec/No use the Measurement
Identity information element retrieved from the fully decoded message (13 and 12 respectively)
4.2 Mobility Issues

11B
This section covers Intrafrequency HO, Interfrequency HO (IFHO) and IRAT HO, in those aspects with impact in
Retainability:
Soft/Softer Handover failures

IRAT Handover failures
IF Handover Failures
Refer to Claro internal doc. Optimization Guidelines Mobility in Ericsson (DEO.OTM.IOP) for further details
regarding Mobility in general.

Assunto Referncia

4.2.1 Soft/Softer Handover Failures

29BS
When UE in connected mode moves within a WCDMA carrier it should always stay connected with the best cells,
otherwise:
The downlink connection quality will deeply decrease because of the interference of the strongest (non-used)
cell. (Each cell acts as interferer for the others)
The UE shall generate high UL interference in the closest (non-used) cell.
RNC implements special measures to avoid UL problems in the target cell and it could decide to release a dangerous
connection.
If the UE reports to the RNC the measurement from an unknown (not in the neighbour list) cell that is
stronger than the best cell in the current active set + releaseConnOffset parameter, then the call will be
released.
If the UE reports a measurement from a neighbour cell, that is stronger than the current active set +
releaseConnOffset parameter, cannot be added to the active set for any reason, then the call will also be
released.
U Huawei counters:

Assunto Referncia

SHO.FailRLAddUESide.NoReply : The measurement is triggered at point A as shown in Figure 1, when the RNC sends an
ACTIVE SET UPDATE message to the UE and starts the timer to wait for the response
from the UE. If the RNC does not receive the response from the UE upon expiry of the
timer, the RNC measures the item in the cell where there is a newly added RL.
SHO.AttRLAddUESide : The measurement is triggered at point B as shown in Figure 1, when the RNC sends
an ACTIVE SET UPDATE message to the UE. If there are newly added RLs, the RNC
measures the item in the cell where the RL is added
SHO.SuccRLAddUESide :The measurement is triggered at point C as shown in Figure 1, when the RNC
receives an ACTIVE SET UPDATE message from the UE. If there are newly added
RLs, the RNC measures the item in the cell where an RL is successfully added.
SHO.AttRLDelUESide :The measurement is triggered at point B as shown in Figure 1, when the RNC sends
an ACTIVE SET UPDATE message to the UE and the RLs are deleted from the cells.
In this case, the RNC measures the item in the cell where the RLs are deleted
SHO.SuccRLDelUESide :The measurement is triggered at point C as shown in Figure 1, when the RNC
receives an ACTIVE SET UPDATE COMPLETE message from the UE and the RLs are
deleted from the cells. In this case, the RNC measures the item in the cell where the
RL is successfully deleted.
VS.SoHo.ASU.AttRNC : The measurement is triggered at point B, as shown in Figure 1. During softer

handover, when the RNC sends an ACTIVE SET UPDATE message to a UE, the RNC
measures this item.
VS.SoHo.Succ :The measurement is triggered at point C, as shown in Figure 1. When the RNC receives
an ACTIVE SET UPDATE COMPLETE message from the UE, which indicates that the
softer handover is successful, the RNC measures this item
Based on this counter and the number of successful HOs executions , we can define following Mobility metrics:
4.2.1.1 46BU SOFTER HANDOVER Speech Success Ratio (%)
[ ]
( )
VS.SoHO.ASU.SuccRLAdd : Number of Successful RL Additions in Softer Handover (Cell)

VS.SoHO.ASU.SuccRlDel : Number of Successful RL Deletions in Softer Handover (Cell)
VS.SoHO.ASU.AttRLAdd : Number of RL Additions in Softer Handover (Cell)
VS.SoHO.ASU.AttRlDel : Number of Attempts to Delete RLs in Softer Handover (Cell)

Assunto Referncia

4.2.1.2 47BU SOFT HANDOVER Speech Success Ratio (%)
( )
[ ]
( )
SHO.SuccRLAddUESide : Number of Successful RL Additions in Soft Handover (Cell)

SHO.SuccRLDelUESide : Number of Successful RL Deletions in Soft Handover (Cell)
SHO.AttRLAddUESide : Number of RL Additions in Soft Handover (Cell)
SHO.AttRLDelUESide : Number of Attempts to Delete RLs in Soft Handover (Cell)
VS.SoHO.ASU.AttRLAdd : Number of RL Additions in Softer Handover (Cell)
VS.SoHO.ASU.AttRlDel : Number of Attempts to Delete RLs in Softer Handover (Cell)
Poor SHO failure rate could explain dropped calls in the neighbours.
4.2.2 Missing Neighbour Relations

30B
The most common cause for a missed handover is the missing neighbour relation
4.2.3 IRAT Handover Failures

31B

Assunto Referncia

IRAT HO should reduce the dropped calls by

moving the connections towards GSM before
they drop.
The real user perception of retainability however

1 depends on both drop call rate on WCDMA and
on GSM side. Wrong IRAT HO settings or wrong
definition of IRAT neighbours can delay or block
the execution of the handover with a negative
effect on the retainability. Moreover some
failures during the IRAT HO execution can
produce dropped calls.
It is important to understand that CS IRAT HO

2 is basically a 3-steps process:
Step 1: Preparation Phase

Preparing the 2G network for the incoming HO.
Step 2: Execution Phase
Ordering the UE to handover to the 2G network.
Step 3: Confirmation Phase
3 Receiving confirmation from the 2G network that
IRAT HO was successful.
Different metrics can be defined to get a complete understanding of the IRAT Performance:
In Section 3.2.4 above we already introduced the IRAT Speech DCR (%), providing the percentage of Voice Drops
that are IRAT drops. It gives an initial idea of the importance of the IRAT problem, in case it is present.
Be aware that IRAT HO Failure does not mean dropped call: If the UE fails in getting the 2G system, it will try to get
back to 3G. Only those calls that fail both in getting gsm and then also to reacquire umts are considered lost (IRAT
drops). But being already in the border of the 3G coverage, all the delays, attempts and reattempts to move to 2G can
only increase the probability to finally drop. Same impact can be expected from delays due to Preparation Failures.
Following KPIs are calculated also for Voice Calls, but can be calculated as well for other RABs (Multi-RAB, SRB
Standalone, CS streaming).
Speech Relocation Preparation Failure Rate (%)

Percentage of IRAT HO Failures due to Preparation Phase issues.
100 *
pmNoF ailO u
tIratHoSpeechGsmF ailure
(pmNoF ailOutIratHoSpeechGsmF ailure pmNoA ttO utIratHoSpeech)
High values point out to problems in the Core Network or in the target GSM Network (resource allocation failure in the
target GSM cell, including congestion)
Percentage of Speech IRAT Handover lost (IRAT drops) over the total number of attempts (%):
pmN oA ttO utIratHoS peech

pmN oS uccessO utIratHoS peech DEO - Otimizao de Rede de Acesso
pmN oF ailO utIratHoS peechReturnOldC hP hy C hFail
pmN oF ailO utIratHoS peechReturnOldC hN otP hyC hF ail
pmN oF ailO utIratHoS peechU eRejection
Assunto Referncia

Percentage of Speech IRAT HO Command rejected by UE (%):
100 *
pmNoF ailO utIratHoSpeechU eRejection
pmNoA ttO ut IratHoSpeech
Percentage of Speech IRAT HO attempts failed for Physical Channel Failure (%):
100 *
pmNoF ailO utIratHoSpeechReturnOldC hPhy C hFail
pmNoA ttO ut IratHoSpeech
Percentage of Speech IRAT HO attempts failed for other reasons (%):
100 *
pmNoF ailO utIratHoSpeechReturnOldC hNotPhyC hF ail
pmNoA ttO ut
IratHoSpeech
Similar metrics can be defined for PS calls and IRAT Cell Changes:
Outgoing IRAT Cell Change Failure Rate (%):
100 *
(pmNoO utIratC cA tt- pmNoO utIratC cSuccess)
pmNoO utIratC cA tt
( )
[ ]
( )
IRATHO.AttOutCS : Number of attempts at CS domain outgoing inter-RAT handovers

IRATHO.SuccOutCS : Number of successful CS domain outgoing inter-RAT handovers.
IRATHO.SuccOutPSUTRAN : Number of Successful RNC-originated PS Domain Outgoing Inter-RAT Handovers
(Cell)
IRATHO.AttOutPSUTRAN : Number of Attempts at PS Domain Outgoing Inter-RAT Handovers (Cell)

Assunto Referncia

And again, also for IRAT CC, some PS connections succeed in getting the 2G system (Successful Cell Change), some
others dont (Cell Change Failures, in general). Amongst these IRAT CC Failures, we have 2 cases now: those
connections that managed to get back to 3G, and those ones that dont (these lost connections are IRAT PS drops).
Percentage of Outgoing IRAT Cell Change Drops (%):
100 *
(pmNoO utIratC cA tt- pmNoO utIratC cSuccess- pmNoO utIratC cReturnOldC h)
pmNoO utIratC cA tt
where pmNoOutIratCcReturnOldCh provides the total number of the PS Inter-RATCC attempts for UE on DCH where
the UE returns to old channel. It is stepped for Inter-RAT CC from UTRAN to GPRS, UE on DCH. The counter is
increased when the Cell change order from UTRAN failure (RRC) message is received from the UE. It doesnt trigger
a dropped call, but it can be responsible of dropped calls for poor coverage due to the delay in the IRAT CC execution,
so its interesting to get an idea of the contribution of these Failures:
Percentage of Outgoing IRAT Cell Change Failures (%) not including drops-:
100 *
pmNoO utIratC cReturnOldC h
pmNoO utIratC cA tt
4.2.4 IF Handover Failures

17B
Inter-Frequency HOs are also hard handovers. Also here the possibilities are:
the UE succeeds in handover to the target carrier (Successful IF HO)
the UE fails in getting the target carrier and comes back to the original carrier (IF HO Failure)
the UE fails in getting the target carrier and also fails to get back to the original carrier (lost call = IF drop)
Percentage of IF HO lost (dropped) (%):
100 *
(pmA ttNonBlindInterFreqHo(RA B)- pmSuccNonBlindInterFreqHo(RA B)- pmF ailNonlindInterF reqHoRev ert(RA B))
pmA ttNonBlindInterF reqHo(RA B)
( )
[ ]
( )
VS.HHO.InterFreq.SuccOut : Number of successful outgoing inter-frequency hard handovers initiated by the RNC.
VS.HHO.InterFreq.AttOut : Number of requests for outgoing inter-frequency hard handovers initiated by the RNC.
Where (RAB) can be any of these possibilities:

Assunto Referncia

CsConversational
CsSpeech12
PSInteractiveGreater64
PSInteractiveLess64
StreamingOther
A correct neighbours definition is critical for both IRAT and IF HO.
For IF HO the neighbours definition could be even more difficult:

Isolated or border second layer cells could have a very large and unpredicted coverage extension because
they are not limited by the surrounding
On the other hand the target WCDMA cells will be only available in the area where they are the best, in other
positions they will be really interfered and cannot be used
Refer to internal Claro docs. Multicarrier Strategy in Claro (DEO.OTM.IOP3112) and PSC Plan and Neighbor List
Strategy in Claro (DEO.OTM.IOP3110).
4.3 Capacity Issues: Congestion Monitoring (from CAPACITY doc)

12B
Following metrics should be considered in the analysis:
Number of downlink congestion events

pmSumOfTimesMeasOlDl
Number of uplink congestion events

pmSumOfTimesMeasOlUl
Number of speech calls released because of congestion (including calls over Iur)
pmNoOfTermspeechCong + pmNoOfIurTermSpeechCong
Number of CS64 calls released because of congestion (including calls over Iur)
pmNoOfTermCsCong + pmNoOfIurTermCsCong
Number of PS calls switched to FACH or released due to congestion (including Iur calls)
pmNoOfSwDownNgCong + pmNoOfIurSwDownNgCong
Percentage of time a cell was congested in DL during a reporting period

100 * pmTotalTimeDlCellCong / [measurementTimeinSeconds]
Percentage of time a cell was congested in DL during a reporting period

100 * pmTotalTimeUlCellCong / [measurementTimeinSeconds]
4.4 Other Faults

13B
There is no counter for Drops due to Other reasons: We just simply calculate them as those cases for which counter
pmNoSystemRabReleaseSpeech is pegged without any of the drop reason counters being pegged.
Section 3.2.5 describes the OTHERS Speech DCR (%).
For further analysis of this dropped calls contribution, try to correlate with Transport Network, RNC, CORE, issues.

Assunto Referncia

TN checkings should include, amongst others, counters for Transmission Errored Seconds (pmEs), Transmission
Severely Errored Seconds (pmSes), Transmission Unavailable Seconds (pmUas). Also for other MOs: ImaLink, etc.
Refer to Claro internal Doc. DEO.OTM.IOP3061, Optimization Guidelines: Transport Network in Ericsson for further
details.

Assunto Referncia

5 REFERENCES
4B
[1] WCDMA (UMTS) Deployment Handbook. Planning and Optimization Aspects. Christophe Chevallier, Christopher
Brunner, Andrea Garavaglia, Kevin P. Murray, Kenneth R. Baker (All of QUALCOMM Incorporated California, USA). Ed.
John Wiley & Sons. 2006
[2] Radio Network Planning and Optimisation for UMTS. Jaana Laiho and Achim Wacker [Both of Nokia Networks,
Nokia Group, Finland] & Toma s Novosad [Nokia Networks, Nokia Group, USA]. Ed. John Wiley & Sons. 2006
[3] WCDMA Radio Access Network Optimization. LZT 123 8297 R1C. Ericsson 2006.
[4] Retainability-Analysis and Monitor Rev5. Guidelines delivered by Ericsson Brazil to Claro in Nov.2009
[5] Introduction to UMTS Optimization. Wray Castle, 2004
[6] HED 5.5. NodeB Documentation (V100R010_06)
[7] RAN6.1 Feature Description
[8] RAN10.0 Network Optimization Parameter Reference-20080329-A-1.0
[9] NodeB WCDMA V100R010C01B051 Performance Counter Reference
[10] Function List and Description of Huawei UMTS RAN10[1].0 V1.7(20080827)

Assunto Referncia

6 ANNEX I: Call Reestablishment (Cell Update procedure)

5B
If a call drops because of a radio link failure, and if network settings allow Call Reestablishment, the UE can reestablish
the call connection through the cell update procedure.
After the drop, a suitable cell is reselected and the UE sends a cell update, as shown in next slide Figure. This
procedure requires the radio condition to recover quickly from the radio link failure; otherwise higher layers on the
UTRAN will clear the call.
After a suitable cell is found, the UE transitions to CELL FACH. The UE sends a Cell Update message using a random
access procedure, the normal procedure for radio link establishment. In this procedure, the network can send a Cell
Update Confirmed message to instruct the UE to return to the CELL DCH state with new RB, transport channel, and
physical channel information (with new assigned dedicated channel information). This is similar to the procedure used
in channel-type switching (from CELL FACH to CELL DCH) during a packet switched call. The UE then responds with
one of the following acknowledgment Layer 3 messages: RB Reconfiguration Complete, Transport Channel
Reconfiguration Complete, or Physical Channel Reconfiguration Complete.
If the connection is successfully reestablished, the dropped call could be a system perceived call drop rather than a
user-perceived call drop, because the user does not have to manually intervene to reestablish the connection. System-
perceived call drops and user-perceived call drops should be counted separately during network analysis. It can take
up to T315 seconds (for PS) or T314 s (for CS) to complete the link reestablishment procedure, during which the UE
transitions to CELL FACH, recovers from the radio link failure, reads all the SIBs, sends the cell update message, and
receives the cell update Complete message with new channel information. During this time, the conversation sounds
are muted to the user.
System and User Perceived PS Call Drops can be easily reported from drive test log-files.
User-perceived call drops are a subset of system-perceived call drops. In these cases, the call was not recovered
automatically; the user had to reactivate it manually.
Use Actix to get the number of call drops.
Display on table: 3G UMTS >> Event Data >>Uu_OutgoingCallOK_PS, Uu_CallDropped_PS and Uu_CallCompleted_PS
The count of Uu_CallDropped_PS is the number of system-perceived call drops.
The difference between Uu_OutgoingCallOK_PS and Uu_CallCompleted_PS is the number of user-
perceived call drops.

Assunto Referncia

7 ANNEX II: UL/DL Radio Synchronization

5B
UTRAN and UE (Layer 1) constantly monitor the Uplink and Downlink for synchronization through Qin and Qout, which
are in-sync and out-of-sync primitives, respectively. It is important to understand this process because it is the source
of dropped calls that can have misleading signatures.
7.1 DL Synchronization
13B
Next Figure shows a Call drop due to loss of Downlink synchronization
Downlink out-of-sync is reported with each frame using the CPHY-out-of-sync-IND primitive, which checks to see
whether either of the two following quality criteria is true:
Downlink Dedicated Physical Control Channel (DL DPCCH) quality over the previous 160 ms is worse than
Qout [3GPP 25.101. UE Radio transmission and reception (FDD)]. For this situation, Qout is not defined
formally in the standard, but is commonly implemented using DL SIR.
All of the last 20 transport blocks received have CRC errors and, of the CRC-protected blocks, all transport
blocks received in the last 160 ms have CRC errors.
If N313 successive out-of-sync indicators are detected at Layer 1, the UE waits for the T313 timer to expire before
declaring a radio link failure. T313 is implemented to allow the link to recover. If N315 successive in-sync indicators
are detected, the entire out-of-sync process is reset. N313, T313 and N315 are broadcast in SIB 1.
Downlink in-sync is reported in every radio frame (10 ms), using the CPHY-sync-IND primitive. This process checks
to see whether both of the following quality criteria are met:

Assunto Referncia

DL DPCCH quality over the previous 160 ms is better than Qin [3GPP 25.101. UE Radio transmission and
reception (FDD)].
At least one correct CRC is received in a TTI ending in the current frame. Only CRC-protected blocks are
considered. The criterion is assumed to be fulfilled if no CRC-protected blocks are transmitted.
After Qout is detected, the UE Power Amplifier (PA) is turned off. Because the Downlink cannot be demodulated
reliably, power control information is not received; thus the PA is turned off to avoid generating interference on the
Uplink. If the Qout condition is maintained for N313 frames, the UE declares CPHY-out-of-sync. The UE then starts a
process similar to initial acquisition of the radio link, because the system timing is considered lost at this point. If the
acquisition process does not succeed within T313, the link is considered lost and radio link failure is declared.
The N313 and T313 parameters directly influence how long a call can be maintained in bad RF conditions. If these
parameters are too short, many calls may be prematurely dropped under rapidly changing RF conditions. On the other
hand, setting these times too long allows more time for calls to recover but may affect call quality and resource
utilization.
For simplicity, the example in the Figure above assumes that the UE PA turns off after the first Qout. The actual
process is more complex: 160 ms after physical channel establishment, the UE turns its transmitter on or off according
to the Downlink DPCCH quality criteria, as follows:
The UE turns off its transmitter when it estimates that the DPCCH quality over the last 160 ms is worse
than a threshold Qout.
The UE can turn its transmitter on again when it estimates that the DPCCH quality over the last 160 ms is
better than a threshold Qin. When transmission is resumed, the power of the DPCCH is the same as when
the UE transmitter was turned off.
This allows the UE to turn off its PA after 160 ms, but turn it back on only after 10 ms if the Qin threshold is lower
than Qout. It is not uncommon for the UE to turn power on and off under bad RF conditions in response to
synchronization loss and recovery.
7.2 UL Synchronization
13B
For the Node B, a similar process is available through the CPHY-sync-IND or CPHY-out-of-sync-IND primitives.
The Node B monitors the Uplink synchronization [3GPP 25.214. Physical layer procedures (FDD)] and reports a CPHY-
sync-IND or CPHY-out-of-sync-IND primitive to the RL Failure/Restored triggering function.
The Uplink synchronization criteria are not specified in the standard, but could be based on similar
measurementsCRC and/or DPCCH quality.
With soft handover, a call could be supported by several radio links; therefore, some vendors have implemented
separate timers for individual links and the overall connection. If a radio link fails, only the link-specific timer
expires and only that specific link clears. Alternatively, if the connection timer expires, the connection would drop.

Optimization Guidelines: Retainability in Huawei

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Optimization Guidelines: Retainability in Huawei

Hochgeladen von

Copyright:

Verfügbare Formate

INSTRUO OPERACIONAL para MANUAL

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

3.2.8 23BOTHERS Speech DCR (%) ??? ................................................................................................................19

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

Document Revision Control

Revision Date Author Changes

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

2.1 Cell Update

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

2.2 CS drop versus PS drop

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

3 RETAINABILITY KPIs (Key Performance Indicators)

3.1 High Level KPIs

3.1.1 Retainability Rate - RR (%)

Call ended by UE or user control

and abnormally released (= DROP):

A global Retainability Rate (%) can be calculated as follows:

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

3.1.2 Dropped Call Rate - DCR (%)

It is the most common KPI for Retainability.

Number of Normal RAB Releases Number of Abnormal RAB Releases

3.1.2.1 32BU CS DCR (%)

(VS.RAB.Lo ss.CS.Abno rm + VS.RAB.Los s.CS.RF VS.CN.RAB. Loss.CS)

Another approach, considering just Voice and Video, could be:

(VS.RAB.Lo ss.CS.AMR + VS.RAB.Loss.CS.Conv 64K)

High value (e.g. >2%) indicates retainability issues for CS connections.

3.1.2.2 32BU Speech DCR (%)

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

3.1.2.3 33BU Video DCR (%)

(VS.RAB.Lo ss.CS.Conv 64K)

3.1.2.4 34BU Streaming DCR (%)

3.1.2.5 34BU PS DCR (%)

High value (e.g. >2%) indicates retainability issues for PS connections.

3.1.2.6 39BU Further considerations on PS/HS DCR (%)

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

3.1.2.7 36BU HSDPA DCR (%)

Typically calculated as:

(VS.HSDPA. RAB.Loss.Abnorm.NonR F + VS.HSDPA.R AB.Loss.RF)

3.1.2.8 37BU HSUPA DCR (%)

Typically calculated as:

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas

3.1.3 Minutes per Drop

i.e., Erlangs translated into minutes divided by the number of drops.

Please also note that:

It is not dependent on the call duration.

3.1.3.1 40BU Voice Minutes per drop

V oice Traffic Erlangs * 60 RO P pmSumBestAmr12200RabEstablish

3.1.3.2 41BU Video Minutes per drop

3.1.3.3 42BU HS Minutes per drop

DEO - Otimizao de Rede de Acesso

Elaborador Revisor Aprovador Reviso Data Emisso Data Reviso Pginas