Optimization Guidelines:
Retainability in NSN
CONTENTS
1 0BINTRODUCTION.........................................................................................................................3
2 1BRETAINABILITY.........................................................................................................................4
2.1 6BCell Update..........................................................................................................................................4
2.2 6BCS drop versus PS drop......................................................................................................................4
3 2BRETAINABILITY KPIs (Key Performance Indicators).............................................................6
3.1 8BHigh Level KPIs..................................................................................................................................6
3.1.1 14BRetainability Rate - RR (%)..........................................................................................................................6
3.1.2 15BDropped Call Rate - DCR (%)......................................................................................................................6
3.1.2.1 32BUSpeech DCR (%)..........................................................................................................................7
3.1.2.2 33BUVideo DCR (%)............................................................................................................................7
3.1.2.3 34BUCS Streaming DCR (%)...............................................................................................................8
3.1.2.4 34BUPS Streaming DCR (%)................................................................................................................8
3.1.2.5 35BUPS DCR (%) ................................................................................................................................8
3.1.2.6 39BUFurther considerations on PS/HS DCR (%).................................................................................9
3.1.2.7 35BUNSN Packet Call DCR (%)..........................................................................................................9
3.1.2.8 36BUHS DCR (%)..............................................................................................................................10
3.1.2.9 37BUEUL DCR (%)............................................................................................................................11
3.1.2.10 38BUCell_FACH DCR (%)..............................................................................................................11
3.1.3 16BMinutes per Drop........................................................................................................................................12
3.1.3.1 40BUVoice Minutes per drop..............................................................................................................12
3.1.3.2 Video Minutes per drop.......................................................................................................................12
3.1.3.3 42BUHS Minutes per drop..................................................................................................................12
3.1.4 17BDrops per Erlang (or Drops per Hour)........................................................................................................13
3.1.4.1 43BUVoice drops per hour..................................................................................................................13
3.1.4.2 44BUVideo drops per hour..................................................................................................................13
3.1.4.3 45BUHS drops per hour......................................................................................................................13
3.1.5 18BOverall Service Retainability - OSRET (%)...............................................................................................13
3.2 9BMedium Level KPIs: Voice Drop Reasons......................................................................................14
3.2.1 19BRADIO <RAB> DCR (%)..........................................................................................................................14
3.2.2 20BIu <RAB> DCR (%)...................................................................................................................................15
3.2.3 21BIur <RAB> DCR (%)..................................................................................................................................15
3.2.4 21BBTS <RAB> DCR (%)...............................................................................................................................16
3.2.5 20BUE <RAB> DCR (%).................................................................................................................................16
3.2.6 21BUnspecified Error <RAB> DCR (%)..........................................................................................................16
3.2.7 20BPre-emption <RAB> DCR (%)...................................................................................................................16
3.2.8 21BRNC (OTHERS) <RAB> DCR (%)...........................................................................................................17
3.2.9 22BIRAT Speech DCR (%)..............................................................................................................................17
4 3BPERFORMANCE ANALYSIS...................................................................................................18
4.1 10BRadio Coverage Issues....................................................................................................................18
4.1.1 24BUplink Problems.........................................................................................................................................18
4.1.1.1 47BURadio Connection Supervision for UE in Cell_DCH................................................................18
4.1.1.2 47BURadio Connection Supervision for UE in Cell_FACH..............................................................19
4.1.2 25BDownlink Problems....................................................................................................................................20
4.1.3 26BLayer 2 Failures triggered by Coverage.....................................................................................................21
4.1.4 27BCritical radio procedure failures due to coverage.......................................................................................21
4.1.5 28BRadio Environment Evaluation...................................................................................................................22
4.1.5.1 48BUPrimary Straight Indicators........................................................................................................22
4.1.5.2 49BUSecondary Indicators..................................................................................................................22
4.1.5.3 50BUW-MRR......................................................................................................................................22
4.1.5.4 51BUGPEH for Radio Coverage Analysis..........................................................................................23
4.1.5.5 52BURRC measurement Reports........................................................................................................23
4.2 11BMobility Issues.................................................................................................................................23
4.2.1 29BSSoft/Softer Handover Failures..................................................................................................................24
4.2.2 30BMissing Neighbour Relations.....................................................................................................................25
4.2.3 31BIRAT Handover Failures............................................................................................................................25
4.2.4 17BIF Handover Failures..................................................................................................................................28
4.3 12BCapacity Issues: Congestion Monitoring.......................................................................................29
4.4 13BOther Faults.....................................................................................................................................30
5 4BREFERENCES...........................................................................................................................31
6 5BANNEX I: Call Reestablishment (Cell Update procedure).......................................................32
7 5BANNEX II: UL/DL Radio Synchronization..............................................................................33
7.1 13BDL Synchronization........................................................................................................................33
7.2 13BUL Synchronization........................................................................................................................34
1 INTRODUCTION
0B
This series of Optimization Guidelines cover all main topics regarding
•
•
•
Performance Monitoring & Analysis
Configuration settings
Troubleshooting
Refer to the internal Claro document Ref. ####.## , Optimization Process, for a summary of 3G
WCDMA Radio Access Network Optimization Basics.
This specific document focuses on RETAINABILITY and its specifics in NSN infrastructure (Release
RU10).
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 telecommunication and are familiar with WCDMA.
Document Revision Control
Revisio
n
Draft0
1
Date
Author
Changes
23-Dec-2009
QCES/NSN
First Draft of the document
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
•
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 systemperceived 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 NSN infrastructure, T314=0 is hardcoded, and T315=30 sec (changeable), i.e., this Cell Update
mechanism is only available for PS data calls (not for Voice calls).
•
In terms of Voice Calls, this means that all RL Failures in DL will finally lead to a drop (user and system
perceived, and RAB release counters –and drops- increased).
•
In terms of PS Calls, 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 functionality disabled. Nevertheless, this worst behavior in the KPI usually
does not match the user perception (that is typically good) thanks to 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 reestablishment 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 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 (Ericsson,
for instance). So, as already anticipated, you can expect a worst KPI PS DCR % performance in these
last ones.
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 NSN 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 or UE Signaling Connection Release)
Call ended because of any problem or action on the other part
(the monitored user receives a “disconnect” from the CN)
Connection ends because of user inactivity (PS calls only)
Connection ends because the call is successfully transferred to another system (IRAT handover)
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
No of Normal RAB Releases
of Normal RAB Releases + No of Abnormal
RAB Releases)
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
No of Abnormal
RAB Releases
of Normal RAB Releases + No of Abnormal
RAB Releases)
As already stated, target is to keep Retainability Rate, RR (%) as closed as possible to 100%, while target
for NRR (%) is to keep the DCR (%) as closed as possible to 0%.
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 NSN for the Normal and Abnormal RAB Releases are:
No of Normal RAB Releases
No of Abnormal RAB Releases
RAB_ACT_COMP_CS_VOICE +
RAB_ACT_REL_CS_VOICE_SRNC
RAB_ACT_COMP_CS_CONV +
RAB_ACT_REL_CS_CONV_SRNC
RAB_ACT_COMP_CS_STREA +
RAB_ACT_REL_CS_STREA_SRNC
RAB_ACT_COMP_PS_CONV +
RAB_ACT_REL_PS_CONV_SRNC
RAB_ACT_COMP_PS_STREA +
RAB_ACT_REL_PS_STREA_SRNC
RAB_ACT_COMP_PS_INTER +
RAB_ACT_REL_PS_INTER_SRNC
RAB_ACT_COMP_PS_BACKG +
RAB_ACT_REL_PS_BACKG_SRNC
RAB_ACT_REL_CS_VOICE_P_EMP + RAB_ACT_REL_CS_V_UNSPE_ER_CN +
RAB_ACT_FAIL_CS_VOICE_IU + RAB_ACT_FAIL_CS_VOICE_RADIO +
RAB_ACT_FAIL_CS_VOICE_BTS + RAB_ACT_FAIL_CS_VOICE_IUR +
RAB_ACT_FAIL_CS_VOICE_RNC + RAB_ACT_FAIL_CS_VOICE_UE
RAB_ACT_REL_CS_CONV_P_EMP + RAB_ACT_REL_CS_C_UNSPE_ER_CN +
RAB_ACT_FAIL_CS_CONV_IU + RAB_ACT_FAIL_CS_CONV_RADIO +
RAB_ACT_FAIL_CS_CONV_BTS + RAB_ACT_FAIL_CS_CONV_IUR +
RAB_ACT_FAIL_CS_CONV_RNC + RAB_ACT_FAIL_CS_CONV_UE
RAB_ACT_REL_CS_STREA_P_EMP + RAB_ACT_REL_CS_S_UNSPE_ER_CN +
RAB_ACT_FAIL_CS_STREA_IU + RAB_ACT_FAIL_CS_STREA_RADIO +
RAB_ACT_FAIL_CS_STREA_BTS + RAB_ACT_FAIL_CS_STREA_IUR +
RAB_ACT_FAIL_CS_STREA_RNC + RAB_ACT_FAIL_CS_STREA_UE
RAB_ACT_REL_PS_CONV_P_EMP + RAB_ACT_REL_PS_C_UNSPE_ER_CN +
RAB_ACT_FAIL_PS_CONV_IU + RAB_ACT_FAIL_PS_CONV_RADIO +
RAB_ACT_FAIL_PS_CONV_BTS + RAB_ACT_FAIL_PS_CONV_IUR +
RAB_ACT_FAIL_PS_CONV_RNC + RAB_ACT_FAIL_PS_CONV_UE
RAB_ACT_REL_PS_STREA_P_EMP + RAB_ACT_REL_PS_S_UNSPE_ER_CN +
RAB_ACT_FAIL_PS_STREA_IU + RAB_ACT_FAIL_PS_STREA_RADIO +
RAB_ACT_FAIL_PS_STREA_BTS + RAB_ACT_FAIL_PS_STREA_IUR +
RAB_ACT_FAIL_PS_STREA_RNC + RAB_ACT_FAIL_PS_STREA_UE
RAB_ACT_REL_PS_I_UNSPE_ER_CN + RAB_ACT_FAIL_PS_INTER_IU +
RAB_ACT_FAIL_PS_INTER_RADIO + RAB_ACT_FAIL_PS_INTER_BTS +
RAB_ACT_FAIL_PS_INTER_IUR + RAB_ACT_FAIL_PS_INTER_RNC +
RAB_ACT_FAIL_PS_INTER_UE
RAB_ACT_REL_PS_B_UNSPE_ER_CN + RAB_ACT_FAIL_PS_BACKG_IU +
RAB_ACT_FAIL_PS_BACKG_RADIO + RAB_ACT_FAIL_PS_BACKG_BTS +
RAB_ACT_FAIL_PS_BACKG_IUR + RAB_ACT_FAIL_PS_BACKG_RNC +
RAB_ACT_FAIL_PS_BACKG_UE
NSN considers 3 possibilities for a RAB in the “ACTIVE” phase:
•
RAB_ACT_COMP_<RAB type>: Normal Release (counter updated when the RNC sends an RANAP:
RAB ASSIGNMENT RESPONSE or RANAP: IU RELEASE COMPLETE to the CN after normal RAB release for a
certain type of RAB)
•
RAB_ACT_FAIL_<RAB type>_<Reason>: Abnormal Release due to some abnormal reason related to Iuinterface, Radio, BTS, Iur-interface, RNC or UE.
•
RAB active releases, the cause of which has been either inter-system handover, intra-system hard
handover, SRNS relocation, pre-emption or "unspecified failure”. Pre-emption for conversational and streaming
and all releases with "unspecified failure" cause received from CN have been considered “Abnormal Releases”.
R A
R A
R A
R A
1 *0 0
R A
R A
R A
R A
R A
B L __ AC C_PS PT__ +_ERV_C ERMOA MEBPINLCP __VEAC _ CPS ET_ _CV+ RE_
B I L_ _A CEC_ S+I_TRUI_ _UAVCF BOAI L_IN_CA CVEC_ SR_T _+R+A_ CVFAD OAD
All above counters are in Measurement “Service Level”, so all DCR (%) KPIs we can derive from them
are available at cell level. Also, as expected for a High Level KPI, they can be aggregated at nation,
market/vendor, region, city, RNC, cluster,… levels.
3.1.2.1 Speech DCR (%)
32BU
B I L_ _A CEC_ SB_T+RB_T_ VCATFS OSAB I LI_NC_A VCEC_ SI_T+U+_I _URCVF RO
B I L_ _A CEC_ SR_T+R_ N_ VCNAF C OABCI LIN_ C _AV CEC_ SU_T _UE_ CVFE O
B M _ AP _CE+CRT SA_ _CB LVCO__OAC INC_SCS STVR_+ + R_CVN RNOC ECNI
B L __ AC C_PS PT__ +_ERV_C ERMOA MEBPINLCP __VEAC _ CPS ET_ _CV+ RE_
B I L_ _A CEC_ S+I_TRUI_ _UAVCF BOAI L_IN_CA CVEC_ SR_T _+R+A_ CVFAD OAD
B I L_ _A CEC_ SB_T+RB_T_ VCATFS OSAB I LI_NC_A VCEC_ SI_T+U+_I _URCVF RO
B I L_ _A CEC_ SR_T+R_ N_ VCNAF C OABCI LIN_ C _AV CEC_ SU_T _UE_ CVFE O
High value (e.g. >2%) indicates retainability issues for Speech connections.
3.1.2.2 Video DCR (%)
33BU
High value (e.g. >2%) indicates retainability issues for Video CS64 connections.
3.1.2.3 CS Streaming DCR (%)
34BU
R A B L __ AC C_S PT_ +__SR ERTAMERB LPE__ AC CPS ET_ _S+ RE_
R A B I L_ _A CAC S+_TR_I _USAF TBAI RL_ _AE CAC S_T _R+_ SFA T AD
R A B I L_ _A CAC S_T+_RB_ SAFT TASB IRL_ E_A CAC S_T+_I _USF RTA
R A B _LA_ CP TS P_ REI _ _EUE+ NRR SA_ CB N_L A_ CP TS P_ RBE E_ UE+ RN
R RA BA _I BAL I _CL_P T_ASR_C__FAC+I IRANSU_TA+T_R_BES FNA_I TLAABC_CIRPL_TSEG_A_F_CB+ACI UAS_TC_U_K S FE TA
1 R*0 A 0 B _I AL _C P T SR_ __F I RAN +ATR DEA IBO _I LA _C P TSG_ _F_BAR A+A C D K
R AR BA _I ALB M_C_P T SAPR_ __F_CIAB+AN+CRRTTTASS_EAB_CB_ISLLAO___TC PACTRSG_C_S_EF_BST+AB_ +ART_S CSRNTK ERC
R RA BA _I ALB L_C_P_TASRP_ __FC_SI I+ANUPRT_ TRA+_S_REBERTA_IMLAREB_CLPEP _T_SGA_AP_F_BCP+AIS UA ET_RC S_K+ ER_
R RAR BAA _I ALBB IL_CL__P_T_ASARC_ P__FACC_ISR+ANS PR+_TTN_RT_AI+___CSERUSABERFTA_TBIMALAIERRBL__CLPPE_EA_T_SGPA_ACC_F_SBCAPR_+STA_RN+ET__CSCFA_SK+ T REA_D
R RAR BAA _I ALBB II_CLL__P T__ASAR_ PC__FAACCI+ UANSRS_+_TTE+TAR_R_BI __EBUSSAATFF_ITTALBAASBI_IRCRL_LP_T_EASE_GA_ C_PFAC_ABCAUSSA_T_TE+_CR_+I__SUKSFAFTTRADA
1 0* 0 R A B I L_ _A CAC S_T+_RB_ S AFT TASB IRL_ E_A CAC S_T+_I _US F RTA
R RA BA _ MAB I PCL_ _T_AP_RPS+CACR_SOA_ITN+_BR_TS_ MFANEAT PACBCRI_TL_P_EG_S+AC _POACB S A_T _CU_ SK FE T
1 R*0 AR 0BA _L AB_I CPL_ TS_A__ CSRIACNRE+S_RTTN+_ERA_CSRBFAN _TLABAC_IRCPL_ ETS_A _ CSRBAC RESA+ _T NC_U_CKS FEG T
R AR B A _LAB_ MCP_ TS PAP_ REI_C_A_+EPURET+ NSRRA_ SA__CBCBSL ON__LT_A_APRCP C_STSE SP_T_ RBE+ RS_E_ UERTN+ RNREC
R A B _I AL _C P T SR_ __F+I IRANU AT BE _I LA _C P TSG_ _F_B+AI UA C K
R AR B A _I ALB L_C _P_T SARP_ __FC_SI RANP+T_ATR+_DSE_RA EIRBTOAM_RIELAB L_PEC_P_TAASGP_ _FC_PSBAR EAT_+A CS_D+ KER_
R AR B A _I ALB I_CL_P T_SAR_ _P_FACI B+ANSR+_TTTR_AISE_USBA F_TIBLAAI R_LC_ P _TAESG_P_ACF_BS+AB_TA_TR+C_SS KFA T AD
R AR B A _I ALB I_CL_P T_SAR_ _P_FACI I+ANSUR_T+TR_ARBE_ SB ATF_TI LAASB IR_CLP_ TES_AG_ _PFA_CB+AISUA_T+_RCI _USK F TR
R A B _I AL _C P T SR_ __F I R+AN RNT ACE B _I LA _C P TSG_ _F_BAR+A N C CK
R A B I L_ _A PAC S _T+_R_ S ANF T ABCRI L_ E_A PAC S _T _U_S FE T
R A B _I AL _C P T SR_ __F I+ UANR ETA EB _I AL _C P TSG_ _F_BAU A E C K
High value (e.g. >2%) indicates retainability issues for CS Streaming connections.
3.1.2.4 PS Streaming DCR (%)
34BU
High value (e.g. >2%) indicates retainability issues for PS Streaming connections.
3.1.2.5 PS DCR (%)
35BU
High value (e.g. >2%) indicates retainability issues for Packet Switch 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).
According to NSN documentation (See References), formula above gives the “Network perspective” of
the KPI.
By just substracting next 2 counters from the numerator, we obtain the “User perspective”:
RAB_ACT_FAIL_PS_INT_PCH: When a call with the PS data interactive RAB in cell-PCH state is dropped.
RAB_ACT_FAIL_PS_BACKG_PCH: When a call with the PS data background RAB in cell-PCH state is dropped.
3.1.2.6 Further considerations on PS/HS DCR (%)
39BU
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:
100 *
(HS_Abnorm
HS_Abnorma l_Release
al_Release + HS_Normal_ Release + Success_Ch annel_Swit ching_from _HS_to_any _other_RAB )
If counters for all those transitions are not available, then the KPI could be not that meaningful.
3.1.2.7 NSN Packet Call DCR (%)
35BU
Another metric is available in NSN, based in counters from Measurement “Packet Call”, where the
impact of RL Failures can be observed. This is a Packet Active Sessions DCR (%), i.e., a retainability
KPI to account for issues during active data transfer periods.
For your reference, Packet Calls (sessions) are shown in blue in the following diagram, their Normal
Releases in green and an Abnormal Release due to RL Failure in red. Note that the data transfer was
interrupted by the RL Failure, but the RAB was kept until its Normal Release.
•
Normal Releases (of NSN Packet Call) counters are updated, for example, due to inactivity or RAB
release. The counters are also updated in case of outgoing SRNC relocations, outgoing Inter-RNC hard
handovers, Inter-System hard handovers, and state transitions to DCH (0/0)/FACH/PCH.
•
Abnormal (=Failure) Releases (of NSN Packet Call) counters are updated in case of Radio Link
failures, pre-emption and RT over NRT. In case of RL failure, all radio links go out of sync state during a packet
call, and as a consequence, the dedicated user plane allocation is released and the call is dropped into the
Cell_FACH or Cell_PCH state. The counter for other failures is updated when a packet call is released due to
some other failure cause than a radio link failure, pre-emption, or RT over NRT. The counter is updated, for
example, if the reservation of the DMPG resource does not succeed when switching the HSPA to a DCH, or
when a DSP runtime error occurs.
1 0* 0[ 1-
P S _ R EML _ NH OS _+RPE S_ I_NR TEML _ HN SO _R+ E _ B G R
P S _ R EML _ NH OS _+RDP S_ I_NR TEML _ HN OS _R+D _ B G R
P S _ R EML _ ND O_ D+ RP _SI N_ RT EML _ DN O_ DR _ B G R
]
R
PS _R
PS _R
PR _EGD R+ _ D _
P S _ R EF LA _I RL _LIH_N S+TP_ SE _ R EF LA _I RL _LBH_ GS+P_R ES _ R EF LA _I RL _L IH_N S+TP_ SD __ R EF LA _I RL _L BH_ GS+ _RP DS _ R EF LA _I RL _LND_ T+_ PD S_ _I R EF LA _I RL _L DG_ R_+ D _ B
P S _ R E_ LF _AOI LT _HIHN+SPT _SE_ R E_ LF _AOI LT _HBH G+SP_RSE _ R E_ LF _AOI LT _HIHN+STP _SD_ R E_ LF _AOI LT _HBH GS+ P_R SD _ R E_ LF _AOI LT I_HND +T_P DS _ R E_ LF _AOI LT B_HDG _RD
This NSN metric is closer to the PS RAB DCR (%) in vendors with no CU enabled, where PS RAB drops
Edue
ML _ HNto SORL_+REPfailures
S_ I_NR TEMLare
_ HNcount.
SO _R+EP _SItB_ isGR certainly
ERML _ HN OS _“Closer”
R+DP S_ I_ NR TEas
ML _account
NH OS _R+DP for
_S B_ RL
GR ERMFailures
L _ DN O_ D+ Rbut
P _SI N_nor
RT EM“completely
L _ DN O_ D+R _ B G
comparable” as this formula above refers to the NSN concept of Packet Call (data transfers in FACH not
Eincluded)
_ LE _MP PR _IENHand
+TSP _Sthe
E_ _RPSE_ RAB
LE _MP DCR
PR _BEHG(%)
+SPR_ Srefers
E __ R E_toLE _PS
MP PRABs
R _EI NH +TS(FACH
P _SD_ _R included).
E_ LE _MP PR _BEHGS+ RP_ SD __ R E_ LE _MP PR _NEDT+ _P DS _ IR E_ LE _MP
Note also that transitions between the different PS states have not been considered (HS <> R99 DCH,
etc).
To be agreed if Pre-empted NRT calls are to be considered Abnormal or Normal Releases.
3.1.2.8 HS DCR (%)
36BU
This metric has been built based also on counters in Measurement PACKET CALL and following the
considerations included in section 3.1.2.6 (i.e., channel switching transitions from HS to other PS RAB
states have been considered):
( P SR _R REM ET L_TL+HHP__ SDNA__ OMREFSL +R_E_ALCI HLNEO+I_HPSLTNLS__ _OEH__ OMR_IHRDAN_BE_ SGFHLL T++_PRSALCNS_ OD_ MRR_ EI_ N LH )T_S N _ OD
1 *0[ -10
]
R
E
L
L
_
_
F
D
A
A
S
L
+
R
I
C
L
L
E
O
H
_
L
L
H
_
_
_
R
I
S
F
D
A
N
A
_
S
L
T
I
L
C
L
P S 1_ M*R 0 E_ 0LH +_PS NS_ O_E MR_R IE_N HL T+_PS NS_ OE_ MR_R BE_ GHL +_PRS NS_ OD_ MRR_ EI_ N LH T+_S N _ OD R_ B
P S _ _R E E M L I NP_ +P_T SHR _ES _R _E E M L_B P_ +GP_ HRS _ES _R_ E E M _L I P_N+P_T HRS _ES _R_E ED M L_B P_ +GP_ HR
P S _ FR RA E I LIE N_+OPLRTH S L_SR__F_AHR MEA E+L__IRLB_ LI_+GENPHRHOORSLLSTS____F_RR _EANAHE _MDI LI L+_N_+S_PRLBHT S LS __ F_R DA E I_LB _ +GRH RLS _
P S _ _R RF E A LE_ I _ILT+NLOP_ HTSHT_ _DHSA__R _F FSEL +A RLA_LCI _LB +EOOIP_HGLTHSTL R_ __HSH_ _OR_IHDFAN_E A SLFL_IT+_LI +ALNCOP_ HTS _HS _R_ F ED A L_I _LB +O_G
P S _ ES _W T NIO_+ PTH_ SDS _ _ ESD _W _T IIGO_ + PHR_ SDS __ DSD W_ _ TBINO_+ PTH _ SDS _ _ DS D W_ _T IGO_ HR_ DS
R E L L _ _ FDA A SL+RI CLL EOH_ L LH__ _ RISFDAN A_ SL T I LCL
High value (e.g. >2%) indicates retainability issues for HSDPA connections.
There is a second option based on counters in Measurement TRAFFIC, i.e., considering dedicated
transport channel allocations and their releases. In other words, all the DCH-related resources (RNC,
BTS, transport, UE) are released, i.e., HS-DSCH MAC-d flow and its return channel allocations are released:
In this case, NSN proposal considers Pre-emptions as Normal Releases.
High value (e.g. >2%) indicates retainability issues for HSDPA connections.
3.1.2.9 EUL DCR (%)
37BU
This metric has been built based also on counters in Measurement PACKET CALL and following the
considerations included in section 3.1.2.6 (i.e., channel switching transitions from EUL to other PS RAB
states have been considered):
1 *0[ -10
( P S R_ RM E _T L+HP _ SN _ OMRE E_ IHL N) _S N _
]
S _ MR E_ HL +P_S NS_ _OE MR_R IE_ N HL +T_S N _ OE
S _ _R E E M LI NP_+PP_T SHR _ ES_R _E EEM L_B P_ +GP_ HR
S _ FR A E I LI N+_ P RTH S LS_ _F_R AE E I_ LB _+G RH R L
S _ _R F E A L_ I _IL+NPO_ STHT _ SH_R _F EEA L_ I _BL + O_G
LS_ __EES F_WDT +AIORN_C+ PH_ITELHSHS _S_L_ ES__LI__WDNRT_E_BIO_FT+GDH_ A+ C I LH
TS_ _ HEES _WDET INION_R+CP+TH_ RSDT_HS _ _E_FES D__WLA_TOTIGO_I_ LRHH_E D _DE B RC G
P
P
P
P
R E LP
P
R E L
1 *0 0
R E L O_ ER D+MR CE_ HIL NO_ TENR D+M C _ HB
High value (e.g. >2%) indicates retainability issues for HSUPA connections.
There is a second option based on counters in Measurement TRAFFIC:
High value (e.g. >2%) indicates retainability issues for HSDPA connections.
3.1.2.10
38BU
Cell_FACH DCR (%)
R
R
To be completed with NSN
Formula
L L_ _E F D +ARC I ELH _L _LI_ NR_E FTD A+ C I LH
L T_ HE DE I NRC+R T_H EF _ LA OT_I LHE _DE B RCG
High value (e.g. >2%) indicates retainability issues for data connections when in state Cell_FACH.
E
E
3.1.3 Minutes per Drop
16B
This KPI 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.
TrafficErlangsof a RAB* 60
Numberof Abnormal
RABReleases
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 Voice Minutes per drop
40BU
Voice Traffic Erlangs * 60
Number of Abnormal Voice Releases
AVG_RAB_HL D_TM_CS_VO
100 * 3600
=
ICE
* 60
Number of Abnormal Voice Releases =
A V GD _ _ R T IAMC B E_ _C H S L _ V
R A BL _A AC V_CS GP DT_+_R_V_ERARTOMNAMBELI PCBV__ A_EC HPCS ELT_ _V+C_ E
R A BI L _ _A CE C S+_ RT I_ U_AV F BOI AL _ I_AC CE C S_ T R+_ _ VAF
0* R0 A0 B L _ AC PCS _T_+ERC_ MARO BEPLN _ VAC _PCS ET_ _C+ _ E
RR AA BBII LL__ __AA CCE_CC S+IS_ +RTUTRB__ _A_VCAT FFBOISBOAIAL _L _IN_AC_AC_CVCECRS S_T++T_AI__UC_ VDF FR
0* R 0 A 0 BI L _ _A CE C S_ +T R_ _ VANF OBCAI L _I C_A CE C S_ T U_ _ VEF
R A BI L _ _A C_C BS+TR_T _ ACSF BOIA L _N_A CV_C SI +UT _ _RC F
R A BI L _ _A C_C RS +TR_N _ CA FC OBAI L _N _A VC_C US T _E_ C F
3.1.3.2 Video Minutes per drop
6
3.1.3.3 HS Minutes per drop
42BU
6
To be completed with NSN
Formula
3.1.4 Drops per Erlang (or Drops per Hour)
17B
It is the average number of dropped calls per 1 hour of connection.
Numberof AbnormalRAB Releases
TrafficErlangsof a RAB * 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 Voice drops per hour
43BU
6
R A B L _ _ AC C_S PT_ +__VR EROAME BI CLP _ _EAC CPS TE_ _V+ RE_
R A B I L_ _A CEC S_+T R_I _UVAF OBAI L_I C_A CEC S_T _R+_ VFA OAD
0* 0 0
R A B I L_ _A CEC S_T+_BR_ VTFA OASB I IL_ C _A CEC S_T+_I _UVF RO
RR AA BBIL L__ _AACCECPCSS_T_+T_+_R_ERCV_ FNAMAROOABCBIEPLINL_C__AVACCEC_PCSS_TET__U_ _VC+_FE E
3.1.4.2 Video drops per hour
44BU
R A BI L _ _A C_C +IS RUT _ A_ C FBIOAL _ N_A C_VC RS T+_A _ C DF O
6 0* 0 0 A V G D _ _R T AIMC B _E _ C H S L _ V O
R A BI L _ _A C_C BS+TR _T _ACSF BOIA L _N_A CV_C IS+UT _ _RC F
R A BI L _ _A C_C RS+TR_N _ CA CF BOAI L _N_A VC_C US T _E _ C F
3.1.4.3 HS drops per hour
45BU
To be completed with NSN
Formula
3.1.5 Overall Service Retainability - OSRET (%)
18B
A V GD _ _ R T NAM VB _ _C H S L _ C
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.
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 NSN in the following way:
R A B _ A C LT__CRSE_ V O_ PIC_ EE M+RP A B _ A C LT__CRSE_ C OP N_ EVM_+P
R A B _ A C LT__CRSE_ V _PUE N_ ES R _+ CR NA B _ A C LT__CRSE_ C _PUE N_ ES R _+ CR NA B _ A C LT__PRSE_ I_ PU EN_SE R _+ CR NA B _ A C LT__PRSE_ B _PUEN_ ES R _+ C N
R A B _ A CILT _ FC AS _ VEO_ IICU+ R A B _ A CILT _ FC AS _ C _OI UN+ VR A B _ A CITL _ FP AS _ INR _T IUE+R A B _ A CILT _ FP AS _ BGA _CI +UK
R A B _ A CILT _ FC AS _ VEO_ RICA D+IOR A B _ A CITL _ FC AS _ C_ORNA VD+I OR A B _ A CITL _ FP AS _ INR _T RE A D+IROA B _ A CITL _ FP AS _ BGA _CRKA D+I O
R A B _ A CILT _ FC AS _ VEO_ BICT+ SR A B _ A CITL _ FC AS _ C _OBNT +VSR A B _ A CITL _ FP AS _ INR _T BE T+SR A B _ A CITL _ FP AS _ BGA _CBKT+S
R A B _ A CILT _ FC AS _ VEO_ IICU+RR A B _ A CITL _ FC AS _ C_OI UN R+VR A B _ A CITL _ FP AS _ I NR _T IEU+RR A B _ A CITL _ FP AS _ BGA _CIUK+R
R A B _ A CILT _ FC AS _ VEO_ RICN+CR A B _ A CILT _ FC AS _ C _ORNN+VCR A B _ A CITL _ FP AS _ I NR _T RE N+CR A B _ A CILT _ FP AS _ BGA _CRKN+C
+
+
+
R
A
B
_
A
C
IL
T
_
F
C
A
S
_
V
E
O
_
U
IC
E
R
A
B
_
A
C
IL
T
_
F
C
A
S
_
C
_
O
U
N
E
V
R
A
B
_
A
C
IL
T
_
F
P
A
S
_
IN
R
_
T
U
E
E
R
A
B
_
A
C
I
T
L
_
F
P
A
S
_
B
G
A
_
C
U
K
E
1 0 *0
R A B _ A C MT _PC_ OC S _ EV+ORI AC B _ A C MT _PC_ OP S _ RIN+ TR EA B _ A C MT _PC_ OP S _ BG+A C K
R A B _ A C LT__CRSE_ V O_ SICR EN+ CR A B _ A C LT__CRSE_ C OS NR NV+_CR A B _ A C LT__PRSE_ IN_TSERRN+ CR A B _ A C LT__PRSE_ B A_ CS KR GN+ C
R A B _ A C LT__CRSE_ V _PUEN_ ES R _+ CR NA B _ A C LT__CRSE_ C _PUE N_ ES R _+ CRNA B _ A C LT__PRSE_ I _ PU EN_SE R _+ CR NA B _ A C LT__PRSE_ B _PUEN_ ES R _+ C N
R A B _ A C LT__CRSE_ V O_ PIC_ EE M+ RP A B _ A C LT__CRSE_ C OP N_ EVM_+P
R A B _ A CITL _ FC AS _ VEO_ IUIC+ R A B _ A CILT _ FC AS _ C _OIUN+ VR A B _ A CILT _ FP AS _ INR _T IEU+R A B _ A CILT _ FP AS _ BGA _CIU+K
Medium Level KPIs: Voice Drop Reasons
R A B _ A C3.2
ITL _ FC AS _ VEO_ RICA D+IO
R A B _ A CITL _ FC AS _ C _OR NA VD+I OR A B _ A C ILT _ FP AS _ INR _T RE A D+IO
R A B _ A C ILT _ FP AS _ BGA _CRKA D+ IO
to dig deeper into the different reasons for the drops detected by the High Level KPIs
R A B _ A CInITL _order
FC AS _ VEsoO_ BIC
T+ SRweA Bcan
_ A build
CITL _ FCthe
AS _following
C _OB NT +VSR Medium
A B _ A CLevel
ILT _ FP ASKPIs,
_ INR _Tfor
BE T+each
SR A Btype
_ A CofITL Calls.
_ FP AS _ This
BGA _Cway,
BKT+S for
described
far,
instance:
R A B _ A C ITL _ FC AS _ VEO_ IU
IC +RR A B _ A C ILT _ FC AS _ C _OI UN R+VR A B _ A CITL _ FP AS _ INR _T IU
E +RR A B _ A C ILT _ FP AS _ BGA _CI UK+R
R A B _ A C ITL _ FC AS _ VEO_ RICN+CR A B _ Speech
A CITL _ FCDCR
AS _ C _(%)
ORNN=+
VCR A B _ A CITL _ FP AS _ INR _T RE N+CR A B _ A C ILT _ FP AS _ BGA _CRKN+C
• RADIO Speech DCR +
R
A
B
_
A
C
I
T
L
_
F
C
A
S
_
V
E
O
_
U
IC
+
E
R
A
B
_
A
C
I
T
L
_
F
C
A
S
_
C
_
O
U
N
E
+
V
R
A
B
_
A
C
I
T
L
_
F
P
A
S
_
I
N
R
_
T
U
E
+
E
R
A
B
_
A
C
IL
T
_
F
P
A
S
_
B
G
A
_
C
U
K
E
• Iu Speech DCR +
9B
1 *0 0
R
R
R
R
R
•
•
•
•
A
A
A
A
A
•
•
Iur Speech DCR +
BTS Speech DCR +
UE Speech DCR +
Unspecified Error Speech DCR +
R A B I _L A_ (CAR TDA _ IBFO )A _ R
Pre-emption Speech DCR +
B M_ AP C+_ R (T RA _ ABC L B_O_ A) ( CRN TA+ C _B R ) _E S
B L _ _ A ( CRE TAM+R_B PRA ) _EB LP _ _ A ( CR S TAP _BE R+ )_ _E
B I _L A_ (CUR+RT A A_ BFB )AI _L AI_ (CAR TD+A _ IBFO )A _
B I _L A_ (CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _
B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _
RNC (OTHERS) Speech DCR
To be CONFIRMED with NSN if IRAT drops are already counted in this split of reasons above.
We guess they are.Maybe included in RNC (Others) reason.
This set of reasons are analyzed further in Section 4 (Performance Analysis – Low Level KPIs)
3.2.1 RADIO <RAB> DCR (%)
(Percentage of <RAB> calls dropped due to radio interface synchronization failure, i.e., the radio
connection is lost)
19B
Where the string “(RAB)” must be replaced by one of the following RAB types:
•
•
•
•
•
•
•
CS_VOICE (CS_V),
CS_CONV (CS_V),
CS_STREA (CS_S),
PS_CONV (PS_C),
PS_STREA (PS_S),
PS_INTER (PS_I),
PS_BACKG (PS_B).
Note: In brackets, the string to be used for counters “…_UNSPE_ER_CN”.
For <Reason> PS DCR, counters for both PS_INTER and PS_BACKG are to be added in the formula.
Note that these 2 RAB types (PS_INTER and PS_BACKG) do not have counters for drops due to preemption (P_EMP): Pre-emption is not done for NRT RABs (interactive and background). NRT DCHs can be
released to make room for RT RABs but this is not called “pre-emption” but “RT over NRT”.
It is possible to put together in a similar formula all types of RABs to estimate the total contribution of a
certain <Drop Reason> to the Overall DCR.
High value (e.g. >2%) indicates retainability problems related to the RF environment.
3.2.2 Iu <RAB> DCR (%)
(Percentage of <RAB> calls dropped due to some abnormal reason related to Iu-interface)
20B
1 *0 0
R
R
R
1 *0 R0
RR
R
R
R
R
R A B I _L A_ (CUR T A _ BF )A _ I
A
A
A
A
A
A
A
A
A
A
B M_ AP C+_ R (T RA _ ABC L B_O_ A) ( CRN TA+ C _B R ) _E S
B L _ _ A ( CRE TAM+R_B PRA ) _BE LP _ _ A ( CR S TAP _BE R+ )_ _E
B I _L A_ R(CUR+ART ABA_ IBF_LB )AAI_ _L (CUAI_R (TCRAAR_TDB+AF _ )AIBFO_ )AI _
B I _L A_ (CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _
B M_ AP C+_ R (T RA _ ABC L B_O_ A) ( CRN TA+ C _B R ) _E S
B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _
B L _ _ A ( CRE TAM+R_B PRA ) _BE LP _ _ A ( CR S TAP _BE R+ )_ _E
B I _L A_ (CUR+RT A A_ BFB )AI _L AI_ (CAR TD+A _ IBFO )A _
B I _L A_ (CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _
B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _
Where the string “(RAB)” must be replaced by one of the following RAB types: CS_VOICE (CS_V), CS_CONV (CS_V), CS_STREA (CS_S), PS_CONV (PS_C),
PS_STREA (PS_S), PS_INTER (PS_I), PS_BACKG (PS_B). Note: In brackets, the string to be used for counters “…_UNSPE_ER_CN”.
For <Reason> PS DCR, counters for both PS_INTER and PS_BACKG are to be added in the formula.
Note that these 2 RAB types (PS_INTER and PS_BACKG) do not have counters for drops due to pre-emption (P_EMP).
High value (e.g. >2%) indicates retainability problems related to Iu-interface.
3.2.3 Iur <RAB> DCR (%)
(Percentage of Voice calls dropped caused by drift RNC procedures; for example, radio link reconfiguration
failure in DRNC)
21B
Where the string “(RAB)” must be replaced by one of the following RAB types: CS_VOICE (CS_V), CS_CONV (CS_V), CS_STREA (CS_S), PS_CONV (PS_C),
PS_STREA (PS_S), PS_INTER (PS_I), PS_BACKG (PS_B). Note: In brackets, the string to be used for counters “…_UNSPE_ER_CN”.
For <Reason> PS DCR, counters for both PS_INTER and PS_BACKG are to be added in the formula.
Note that these 2 RAB types (PS_INTER and PS_BACKG) do not have counters for drops due to pre-emption (P_EMP).
High value (e.g. >2%) indicates retainability problems related to Iur-interface.
3.2.4 BTS <RAB> DCR (%)
(Percentage of Voice calls dropped caused by BTS (for example, radio link setup or reconfiguration
problem)
21B
R A B I _L A_ (CTR TS A _ BF )A _ B
1 *0 0
R A B M_ AP C+_ R(T RA _ ABC LB_O_A)( CRN TA+ C _B R ) _E S
R A B L _ _A ( CRE TAM+R_B PRA ) _BE LP_ _ A ( CR S ATP _BE R+)_ _E
Where the string “(RAB)” must be replaced by one of the following RAB types: CS_VOICE (CS_V), CS_CONV (CS_V), CS_STREA (CS_S), PS_CONV (PS_C),
PS_STREA (PS_S), PS_INTER (PS_I), PS_BACKG (PS_B). Note: In brackets, the string to be used for counters “…_UNSPE_ER_CN”.
For <Reason> PS DCR, counters for both PS_INTER and PS_BACKG are to be added in the formula.
Note that these 2 RAB types (PS_INTER and PS_BACKG) do not have counters for drops due to pre-emption (P_EMP).
R A
R A
R A
1 *0 0
R A
R A
R A
R A
R A
1 *0 0
1 *0 R0 A
RR AA
R A
R A
R A
R A
R A
RR AA
B I _L
B I _L
B I _L
A_
A_
A_
(CUR+RT A A_ BFB )IA _L AI_ (CAR TD+A _ IBFO )A _
(CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _
R(CNR A+TRCA B_ ABI F_L B)AA_I_ _L(CRERA_ T(ACER_ BTFA _)A B_F U)A _
High value (e.g. >2%) indicates retainability problems related to Iur-interface.
3.2.5 UE <RAB> DCR (%)
(Percentage of <RAB> calls dropped caused by the UE.
The RNC sends IU/RAB RELEASE REQUEST message to the CN because the UE is not responding to an RRC
message or the UE is responding with such failure message that the connection must be released).
20B
B M_ AP C+_ R (T RA _ ABC L B_O_ A) ( CRN TA+ C _B R ) _E S
B L _ _ A ( CRE TAM+R_B PRA ) _BE LP _ _ A ( CR S ATP _BE R+ )_ _E
Where the string “(RAB)” must be replaced by one of the following RAB types: CS_VOICE (CS_V), CS_CONV (CS_V), CS_STREA (CS_S), PS_CONV (PS_C),
PS_STREA (PS_S), PS_INTER (PS_I), PS_BACKG (PS_B). Note: In brackets, the string to be used for counters “…_UNSPE_ER_CN”.
For <Reason> PS DCR, counters for both PS_INTER and PS_BACKG are to be added in the formula.
Note that these 2 RAB types (PS_INTER and PS_BACKG) do not have counters for drops due to pre-emption (P_EMP).
B I _L A_ (CUR+RT A A_ BFB )IA _L AI_ (CAR TD+A _ IBFO )A _
B I _L A_ (CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _
B I _L RA_ A(CNRB+TIRCA_L_ AB_F (BC)ANRI_ _LTSRAA__ PB(CFERE)AT _A _UEBF R)A _
R A B I _L A_ (C_R ET A M_ BF P )A _ P
B M_ AP C+_ R (T RA _ ABC L B_O_ A) ( CRN TA+ C _B R ) _E S
BB LM__ _ AAP( CCR+_ER (TTAM+RAR__B ABPCRA )L B__OBE_ ALP) (_ _CRAN( TA+ CRCS_BATPR )_BE_ER+ )_S _E
BB IL __L _ AA_ ( (CCRUER+RTTAM+ARA__B BPRAFB) )IA_BE_L LPA_I_ _ A(C(ARCRTSD+ATA_PIBF_OBE R)A+ )__ _E
BB II __LL AA__ ((CCUTRR++RTTSRAA A__ ABBFFBB))AIAI_L__L ABI_A_ (C(ACRURT+DT+ARA_ _IBFBOF )A)A_ _
BB II __LL AA__ ((CCTNRR ++TTSRRCAA __ AABBFF BB))AAII___L_L RBAA__ ((CCUERR+TTRAA __ BBFF )A)A __
B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _
High value (e.g. >2%) indicates retainability problems related to the UE.
3.2.6 Unspecified Error <RAB> DCR (%)
(Percentage of <RAB> active releases with "unspecified failure" cause received from CN).
21B
Where the string “(RAB)” must be replaced by one of the following RAB types: CS_VOICE (CS_V), CS_CONV (CS_V), CS_STREA (CS_S), PS_CONV (PS_C),
PS_STREA (PS_S), PS_INTER (PS_I), PS_BACKG (PS_B). Note: In brackets, the string to be used for counters “…_UNSPE_ER_CN”.
For <Reason> PS DCR, counters for both PS_INTER and PS_BACKG are to be added in the formula.
Note that these 2 RAB types (PS_INTER and PS_BACKG) do not have counters for drops due to pre-emption (P_EMP).
High value (e.g. >2%) indicates retainability problems to be investigated further, likely CORE, TX,
Protocol,… issues.
3.2.7 Pre-emption <RAB> DCR (%)
(Percentage of RT <RAB> released due to pre-emption).
20B
Where the string “(RAB)” must be replaced by one of the following RAB types: CS_VOICE (CS_V), CS_CONV (CS_V), CS_STREA (CS_S), PS_CONV (PS_C),
PS_STREA (PS_S), PS_INTER (PS_I), PS_BACKG (PS_B). Note: In brackets, the string to be used for counters “…_UNSPE_ER_CN”.
For <Reason> PS DCR, counters for both PS_INTER and PS_BACKG are to be added in the formula.
Note that these 2 RAB types (PS_INTER and PS_BACKG) do not have counters for drops due to pre-emption (P_EMP).
Pre-emption is not done for NRT RABs (interactive and background). NRT DCHs can be released to make room for RT RABs, but this is not called preemption.
High value (e.g. >2%) indicates retainability problems related to the UE.
3.2.8 RNC (OTHERS) <RAB> DCR (%)
(Percentage of <RAB> calls dropped caused by some reason not covered by the other failure counters)
21B
R A B I _L A_ (CNR TCA _ BF )A _ R
1 *0 0
R A B M_ AP C+_ R(T RA _ ABC LB_O_A)( CRN TA+ C _B R ) _E S
R A B L _ _A ( CRE TAM+R_B PRA ) _BE LP_ _ A ( CR S ATP _BE R+)_ _E
Where the string “(RAB)” must be replaced by one of the following RAB types: CS_VOICE (CS_V), CS_CONV (CS_V), CS_STREA (CS_S), PS_CONV (PS_C),
PS_STREA (PS_S), PS_INTER (PS_I), PS_BACKG (PS_B). Note: In brackets, the string to be used for counters “…_UNSPE_ER_CN”.
For <Reason> PS DCR, counters for both PS_INTER and PS_BACKG are to be added in the formula.
Note that these 2 RAB types (PS_INTER and PS_BACKG) do not have counters for drops due to pre-emption (P_EMP).
R A
RC OA
RC OA
C O
B I _L A_ (CUR+RT A A_ BFB )IA _L AI_ (CAR TD+A _ IBFO )A _
BN IS __L _DA_ H (RCTHRC+PTSROAHS_ AB_F+ CUIQB)AIO_L__L B_RAN_ DS(TC_UR_D+TRHAR_HWBPF OS)AR+__ _UI R
N S _ _D H R HPP OCS H+_ CDI _ ORL N_T SD_ _D H R H_P RO+S T_ RI
B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _
High value (e.g. >2%) indicates retainability problems related to OTHER reasons.
For Voice DCR, there is a contribution that should be reviewed already at this level:
3.2.9 IRAT Speech DCR (%)
(Percentage of Voice IRAT dropped calls, i.e., CS_VOICE calls that drop (“lost calls”) after the ‘HO from
UTRAN’ command is sent to UE).
22B
N S _ _D H R H_P RO+S CT_ OEI CN SN_ _DOH R HMP OS + _ IR M T _
N S _ _D H R HGP OS_ +C_ EIA ML LE R
N HD OR __ LI SIBM_+_ CH_R ROE TNS H_D OR __ TLI SBO __+THP_ RR
N HD OR __ TLI SOB __+TCHP_ OTR XNT H_D OR __+ SI SB _ _ HR T
N HD OR __ _LI SB _C_+ CHR_ ORS NTV SR_ _D H R HRP OST _ WI
C O
C O
C O
C O
1 *0 0
R A B M_ A P C_ TEC+R_S CA_ OVB OL_ _AI CC S_T _S_ V+R ONE ICC E
R A B L_ _A CC S_T _P_ V_R+REOE MAI CBP EL_ _A CC S_T _U_ VRN OECS I+ PNC E
R A B I_L A_ C ETS __+RI FVU AO B I IC_L A_ C ETS __ RFV+ AO D I CI O
R A B I_L A_ C ETS __ +BFRV TAOA S BI CI_L A_ C ETS __ +I FVU AOR I C
R A B I_L A_ C ETS __ +RFVR NAOA CBI CI_L A_ C ETS __ UFV AEO I C
Note that calls that attempt an IRAT HO:
•
•
•
Either succeed in getting the 2G system (Successful IRAT HO),
or return to UTRAN if they cannot get the 2G system (IRAT HO Failure)
or drop (= are LOST, if they fail to get the 2G system and also fail to get back to the 3G system)
This formula shows the contribution of the Voice IRAT drops to the total Speech DCR (%).
High value (e.g. >2%) indicates specific retainability problems associated to IRAT HO.
4 PERFORMANCE ANALYSIS
3B
Following the Hierarchical KPIs methodology described in Claro internal doc. Ref. Claro ####.## ,
Optimization process, 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 NSN 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:
•
o
o
•
o
o
o
•
•
RADIO: Radio coverage issues:
Uplink problems
Downlink problems
BTS: Mobility issues:
Handover failures
Missing neighbor relations
IRAT/IF handover issues
PRE-EMPTION: Capacity issues
Other faults (Iu, Iur, UE, Unspecified Errors, RNC).
4.1 Radio Coverage Issues
10B
Any condition related to 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 different algorithms that
monitor:
UEs in DCH state (also valid for HS and EUL)
UEs in cell FACH state or URA_PCH state
4.1.1.1 Radio Connection Supervision for UE in Cell_DCH
47BU
When the UE detects a radio link failure due to loss of L1 synchronisation in Cell_DCH state, the UE
initiates a cell selection procedure. If a new cell is found during the time supervision, the UE changes its
RRC state to Cell_FACH state, and performs a cell update procedure.
The RNC checks whether the radio links in the active set of the UE are synchronised by setting a radio
link-specific "in sync"/"out of sync" status based on the indications received from the BTS(s). Radio
link(s) with "out of sync" status are not deleted immediately, since the UE has a T313-specified number
of seconds to re-establish a L1 synchronisation before radio link failure criteria is fulfilled.
When all the radio links in the active set are in "out of sync" state, the RNC starts the corresponding
time supervision and starts to wait for a NBAP: Radio Link Restore Indication (or RNSAP:Radio Link
Restore Indication) procedure from the BTS(s) (or DRNS). Once the time supervision ends, the RNC
checks the timer T315, and depending on its value and the used service (RT, NRT or both), an RRC
connection re-establishment or an RRC:RRC Connection Release procedure is initiated as follows:
•
In case of a RT-only service, all RT radio bearers are released locally (T314 = 0) and the Iu release
request is sent to the CN.
•
If T315 is set to zero, all NRT radio bearers (also the RT RB(s), if existing) are released locally, and the
Iu release request is sent to the CN(s).
•
If T315 > 0, the waiting of a RRC connection re-establishment is initiated, that is, a supervision timer
corresponding to the UE timer T315 is started. All RT radio bearers are released locally, and the Iu release
request is sent to the CS-CN.
During T315, the UE must to be able to select a suitable UTRAN cell, and initiate the cell update
procedure, otherwise the RNC initiates the Iu release request with cause value 'Radio Connection With
UE Lost' towards the PS-CN.
4.1.1.2 Radio Connection Supervision for UE in Cell_FACH
47BU
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.
In the Cell_FACH state, the location of the UE is known at cell level in the RNC. A cell update procedure
is used to report to the RNC when the UE executes cell reselection. In the Cell_FACH state, the cell
update procedure replaces handover.
When the UE is switched to the Cell_FACH state (for example, Cell_DCH to Cell_FACH transition, paging
the UE from the PCH states or by UE initiated Cell/URA update), the RRC entity starts a supervision timer
and waits for a periodic cell update. This timer is derived from UE parameters T305, T307, N302 and
T302.
If the UE is switched immediately back to the PCH states (for example, after the periodic update), the
supervision timer is (re)started from the initial value, to wait for periodic cell update.
While the UE stays in the Cell_FACH state, the supervision timer is (re)started from the initial value, to
wait for periodic cell update, each time a Cell/URA update is received from the UE.
If the UE - after inactivity detection in Cell_FACH state - is switched directly from Cell_DCH to the PCH
states (via Cell_FACH state), the supervision timer is kept running to wait for periodic cell update.
Radio Connection Supervision Parameters :
Final recommended setting under discussion. Trial ongoing to be completed.
U
U
UL
DL
(**) Hardcoded.
U
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
MAXIMUM_PRXTOTAL (dBm): check the 90th perc or the max value. Results higher than -95 dBm can
be associated with UL synch problems
o
Averaged value of UL RSSI. Values higher than -90 dBm can be associated with UL synch problems.
Refer to the Optimization Guidelines: Capacity in NSN for further details regarding how to calculate it.
4.1.2 Downlink Problems
25B
Algorithms similar to uplink Radio Connection Supervision 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.
For further investigation:
Check following counters in Measurement: Packet Call (M1022):
PS_REL_RL_FAIL_HS_E_INT & PS_REL_RL_FAIL_HS_E_BGR
PS_REL_RL_FAIL_HS_D_INT & PS_REL_RL_FAIL_HS_D_BGR
PS_REL_RL_FAIL_D_D_INT & PS_REL_RL_FAIL_D_D_BGR
The number of HS-DSCH/E-DCH (or HS-DSCH/DCH or DCH/DCH) packet call releases caused by radio link failures for the
interactive (background) traffic class.
Updated: When a packet call is released due to a radio link failure, that is, all radio links go out of the sync state during a packet call
and thus the dedicated user plane is released.
Check following counters in Measurement: Traffic (M1002):
REL_ALLO_RL_FAIL_HS_DSCH_INT & REL_ALLO_RL_FAIL_HS_DSCH_BGR
The number of HS-DSCH allocation releases due to radio link failure, RLC protocol reset or uplink RLC unrecoverable
error for interactive (background) class connections.
Updated: When the user's HS-DSCH allocation is released due to radio link failure, RLC protocol reset or uplink RLC
unrecoverable error (Cell Update sent by UE).
REL_EDCH_RL_FAIL_INT & REL_EDCH_RL_FAIL_BGR
The number of E-DCH releases for interactive (background) class connections due to a radio link failure, an uplink RLC
unrecoverable error, or due to the UE not responding to an RRC message sent by the RNC.
Updated: When the E-DCH is released due to a radio link failure, an uplink RLC unrecoverable error, or due to the UE not responding
to an RRC message.
Check following counter in Measurement: RRC signalling (M1006):
CELL_UPDATE_ATT_R_LINK_FAIL:
A number of cell update attempts due to a radio link failure.
Updated: When the RRC signalling entity receives a CELL_UPDATE message with CAUSE 'Radio link failure'.
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.
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.
If the number of retransmissions of the RLC RESET PDU exceeds the upper limit in UE-RLC, the UE sends
a cell update message (with cause value "RLC unrecoverable error") to the RNC. The UE should indicate
in the message whether the unrecoverable error exists in the signalling radio bearer SRB2, SRB3 or
SRB4 or in another radio bearer (RB>4).
When this L2 signalling error occurs, the RNC initiates an RLC Reestablishment procedure for the UE.
For further investigation:
Check counters in Measurement Traffic (M1002) suggested in previous section 4.1.2
Check following counter in Measurement: RRC signalling (M1006):
CELL_UPDATE_ATT_RLC_ERR
A number of cell update attempts due to an RLC unrecoverable error.
Updated: When the RRC signalling entity receives a CELL_UPDATE message with CAUSE 'RLC unrecoverable error'.
RRC_CONN_REL_RNC_INT
The number of RRC connection releases due to RNC internal reason.
Updated: When RLC unrecoverable error happens in CELL_DCH or CELL_FACH state with PS connection.
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)
For further investigation:
Check following counters in Measurement: RRC signalling (M1006):
AS_UPDATE_RL_ADD_FAIL_UE:
The number of failed radio link additions with an active set update procedure due to the UE responding with an RRC: ACTIVE SET
UPDATE FAILURE message.
Updated: When the serving RNC receives an RRC: ACTIVE SET UPDATE FAILURE message from the UE, this counter is updated
by the number of radio links that were attempted to be added to the UE's active set with the active set update procedure, also in a cell
replacement procedure. The counter is updated for the cells which were attempted to be added to the active set. In case of a DRNC
cell, the WBTS-0/WCEL-0 object is used.
AS_UPDATE_RL_ADD_NOREPLY:
The number of failed radio link additions with an active set update procedure due to the UE not responding to an RRC: ACTIVE SET
UPDATE message.
Updated: When the serving RNC does not receive a reply to an RRC: ACTIVE SET UPDATE message sent to the UE, this counter is
updated by the number of radio links that were attempted to be added into the UE's active set with the active set update procedure,
also in a cell replacement procedure. The counter is updated for the cells which were attempted to be added into the active set. In
case of a DRNC cell, the WBTS-0/WCEL-0 object is used.
Check following counters in Measurement: Soft handover (M1007)
Note that an active set update can be part of branch addition, branch deletion or branch replacement.
UNSUCC_UPDATES_ON_SHO_FOR_RT:
The number of unsuccessful active set updates for RT traffic.
Updated: When the RNC receives an RRC: ACTIVE SET UPDATE FAILURE message from the UE or the RNC does not receive
RRC: ACTIVE SET UPDATE COMPLETE message from the UE within a certain time period. This counter is updated in every cell
belonging to the active set before changes.
UNSUCC_UPDATES_ON_SHO_NRT:
The number of unsuccessful active set updates for NRT traffic.
Updated: When the RNC receives an RRC: ACTIVE SET UPDATE FAILURE message from the UE or the RNC does not receive an
RRC: ACTIVE SET UPDATE COMPLETE message from the UE within a certain time period. This counter is updated in every cell
belonging to the active set before changes.
4.1.5 Radio Environment Evaluation
28B
NSN TOOLs similar to W-MRR, GPEH,… ???
To completed by NSN.
Evaluating radio environment characteristics by counters:
•
•
Radio Environment straight indicators
Radio Environment Statistics (RES) and OSS W-MRR
4.1.5.1 Primary Straight Indicators
48BU
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 Secondary Indicators
49BU
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)
•
R99)
•
•
•
Compressed mode average number of users / Traffic Erlang of services that can start CM (Speech, PS
Number of IRAT execution/ Normal RAB releases
CQI Distribution
CELL_UPD_ATT_RE_ENT_S_AREA (number of cell update attempts due to a re-entered service area)
4.1.5.3 W-MRR
50BU
Similar TOOL in NetAct. OPTIMIZER Capabilities?
4.1.5.4 GPEH for Radio Coverage Analysis
51BU
Similar TOOL in NetAct. OPTIMIZER Capabilities?
4.1.5.5 RRC measurement Reports
52BU
In case measurements type RES in E/// are 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 2dEc/No use the Measurement Identity information element retrieved from the fully decoded message (13
and 12 respectively)
NSN Measurement “Soft handover” (M1007) provides information on the CPICH Ec/No distribution
through counters:
CPICH_ECNO_CLASS_# (where # = 0 to 9)
Number of received 1A intra-frequency measurement reports in which the CPICH Ec/No value is inside the Class # range (see table
below for the CPICH Ec/No distribution classes (mapping based on 3GPP TS 25.133)).
The Ec/No counter is updated to the best SRNC side cell, which can be either one of the current active set cells or one of the eventtriggered cells.
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
Missing neighbor relations
•
•
IRAT Handover failures
IF Handover Failures
Refer to Claro internal doc. Ref.####.##: Optimization Guidelines – Mobility in NSN for further details
regarding Mobility in general.
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.
Some RNCs implements special measures to avoid UL problems in the target cell and they could even
decide to release a dangerous connection. [To be confirmed with NSN if this is also implemented in NSN
RNCs]
•
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 + “a certain offset”, then the call will be released.
•
If the UE reports a measurement from a neighbour cell, that is stronger than the current active set + “a
certain offset”, cannot be added to the active set for any reason, then the call will also be released.
Most common reason to have handover failure is because the target cell cannot accept incoming call
due to admission block or failure in other resources allocation failure (e.g. transport or DL channelization
code). Also the RL Setup or RL Addition procedures may fail (NBAP Radio link Setup Failure / NBAP Radio
link Addition Failure received) or the Active Set Update procedure fails (RRC Active Set Update Failure
received) or Active Set Update procedure times out in the UE.
We have build following Mobility metric based in counters already described in section 4.1.4 (ASU
procedures for RL addition):
Soft HO failure rate (%):
(AS_UPDATE_
100 *
(A
S_U
PD
A
TE
_R
L_A
D
D
_SU
R
L_A
D
D
_FA
I
C
C +A
S_U
PD
A
TE_
L_U
E
+A
S_U
PD
A
TE_
R
L_A
D
D
_FA
I
L_U
E
R
L_AD
D
_N
O
R
+A
S_U
PD
A
TE_
EPLY
)
R
L_A
D
D
_N
O
R
EPLY)
Poor SHO failure rate could explain dropped calls in the neighbours.
For further investigation on the reasons why the RL additions are failing, check following counters in
Measurement: L3 signalling at Iub (M1005). Counters in this section are updated only for base stations
using 3GPP NBAP protocol.
BRANCH_ADD_FAIL_SRNC_BTS_NR
A number of radio link branch addition failures for softer HO on SRNC side caused by the fact that a BTS is not responding. If the
BTS does not respond in the allowed time.
Updated: When a dedicated NBAP signalling entity does not receive any response from a BTS to a
RADIO_LINK_ADDITION_REQUEST message.
BRANCH_ADD_FAIL_SRNC_RNL
The number of radio link branch addition failures for softer HO on SRNC side due to radio network layer cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK ADDITION FAILURE message from a BTS.
BRANCH_ADD_FAIL_SRNC_TRL
The number of radio link branch addition failures for softer HO on SRNC side due to transmission layer cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK ADDITION FAILURE message from a
BTS.
BRANCH_ADD_FAIL_SRNC_PROT
The number of radio link branch addition failures for softer HO on SRNC side due to protocol cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK ADDITION FAILURE message from a
BTS.
BRANCH_ADD_FAIL_SRNC_MISC
The number of radio link branch addition failures for softer HO on SRNC side due to miscellaneous cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK ADDITION FAILURE message from a BTS.
BRANCH_ADD_FAIL_DRNC_BTS_NR
A number of radio link branch addition failures for softer HO on DRNC side caused by the fact that a BTS is not responding.
Updated: When a dedicated NBAP signalling entity does not receive any response from a BTS
RADIO_LINK_ADDITION_REQUEST message.
to
a
BRANCH_ADD_FAIL_DRNC_RNL
The number of radio link branch addition failures for softer HO on DRNC side due to radio network layer cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK ADDITION FAILURE message from a BTS.
BRANCH_ADD_FAIL_DRNC_TRL
The number of radio link branch addition failures for softer HO on DRNC side due to transmission layer cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK ADDITION FAILURE message from a
BTS.
BRANCH_ADD_FAIL_DRNC_PROT
The number of radio link branch addition failures for softer HO on DRNC side due to protocol cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK ADDITION FAILURE message from a
BTS.
BRANCH_ADD_FAIL_DRNC_MISC
The number of radio link branch addition failures for softer HO on DRNC side due to miscellaneous cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK ADDITION FAILURE message from a BTS.
4.2.2 Missing Neighbour Relations
30B
The most common cause for a missed handover is the missing neighbour relation.
Any NSN tool in NetAct (Optimizer) similar to E/// WNCS that can help in missing neighbour relation
identification??
4.2.3 IRAT Handover Failures
31B
IRAT HO should reduce the dropped calls
by moving the connections towards GSM
before they drop.
1
2
The real user perception of retainability
however 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 is basically a 3-steps process:
•
Step 1: Preparation Phase
•
Step 2: Execution Phase
•
Step 3: Confirmation Phase
Preparing the 2G network for the incoming
HO.
3
Ordering the UE to handover to the 2G
network.
Receiving confirmation from the
network that IRAT HO was successful.
2G
Different metrics can be defined to get a complete understanding of the IRAT Performance:
In Section 3.2.9 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 (MultiRAB, SRB Standalone, CS streaming).
Speech Relocation Preparation Failure Rate (%)
Percentage of IRAT HO Failures due to Preparation Phase issues (over the total number of positive IRAT
HO decisions taken by the RNC: inter-system HHO attempt is started = RANAP: RELOCATION REQUIRED
message sent to CN).
100 *
ABLE_EXEC_
ISHHO_RT
UTRAN_NOT_
IS_HHO_CS_
RT_ATTEM
PT
S
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
(%):
Attempts here refer to the number of HANDOVER FROM UTRAN sent to the UEs.
C S OU NC SO_C _D_H RLI SHBOCP _O_SHTHP_+__SH+RIUNCQUXLOR_C__RTNODTC TS__ _DLI HSBOR _H_WPTHPOS+_ HRTN+_ _XIU
C S OU NC SO_C _D_H RLI SHBUP _O_CSLHC__+H+ SHCINDA_UOPRRL CA_NTTOCDS__ __D LIHSRBDH__P_LHROSC+ +_ TH_AN IR P
C S OU NC SO_C _D_H RLI SHBSP_ _OR_SC+HCR_T+_ SHIOESN UCVNR CSNRT_OC_D_O H_ RLI HMSPBI MO_SS_ H+ _R__+ INHREM RTS
C S OU NC SO_C _D_H RSI S+HBPSG_OS_U_H N_+CHIEROAC MTL_ ULEI S R_L _ N_ H+ DRH CT H _ Q
C S OU NC HODC OR_ UI_ S LWIES_BI _MH_R_T+ +HCHRS_R RNOUEX TRSNC_ OH_TPCD O_R DI _S PLTI _SWB_OH_D_+THR+ PP__R
C S OU NC HODC OR_ CI_ S CLTIP S_BOIPHC_ +_THSHCPN_UTO_R CXRNTO_CSHD _ ORCI S_NP+ S_I ISOHCB +__H_HN R _
U SN US CHU OCHC _ COI MS__RTI_L_STOHBI _+MHUT_ PS_N R_ SNTXHU HC CO __ TILSOB_+ T_ P_
C O N HD OR _ L_I SSB _C_+ HCR_ ORS VTN SR_ _D H R HPR OST _ IW
U
11 *00[* -100 N S HU HC CO R__ IL_S SB_+CU_ R_N RSS VTHU HC CO __ LILSI BM_+ _] _R
U NI( SI S_ HU_H H__HCHLRHCOOBT+O__U__TIST_PSAAN_-CBSUR_T+NTSI_SXTSTTHURRR_EHTCTHTAMACO_OHNBLP__+OB_ILWSNE_ITS_POA__HSET+NTT H_XXT_RRE_O T
U NI S S_ HUH _HCHL COOB ___LIQUCSA_ +_L_AN+UT IR_STPRNDT_ATSCH_HU_HHULHC OBCO _L__CA_IPUSNA+TWE_T+PR _RAT _
U NI S S_ HUH _HCHL COOB _H__CID_RSA _PL_S+TNIW+_SVTURD_RNTPH_S_CHRSLHU TOBHC _MCORA R__+ETNICSSST RCP_+_ IP
U NI S S_ HUH _HCHS COOB E+__I_ISCSAN _NP_T+RHUIOTC_THNU_H ORSL_ HUT_N DAHC+R TCCOTTH__ RII+_SMTQ_ _ _ I
U NI S S_ HUH _HCHU COOE_C__IRESAT _M_LRT+NILETXS RR_ THGP _WH_D OL _W AD RTP+ _TC N
1 0* 0 I S _ H _ HC OP _IP CA_ H+NT I S_TR R_ T HS _ CHC OP I_OCA _HT+ N _T RE
I( SI S_ _H H__HIRHMOTO___TT_IAAM-CSUTT SSTT _REN AMAR NBP _L NEI SO_ HET HX_ EO C
Percentage of Speech IRAT HO Failures (due to Command rejected by UE, Physical Channel
Failure and other reasons) (%):
Also in this case, over the total number of attempts (HANDOVER FORM UTRAN sent to the UEs).
Similar metrics can be defined for PS calls and IRAT Cell Changes:
Outgoing IRAT Cell Change Failure Rate (%):
This metric gives the rate of CC Failures over the total number of CC from UTRAN sent to the UEs.
And again, also for IRAT CC, some PS connections succeed in getting the 2G system (Successful Cell
Change), some others don’t (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 don’t (these “lost”
connections are IRAT PS drops).
Following metric gives the percentage of CC’s from UTRAN lost, i.e., IRAT PS drops:
Percentage of Outgoing IRAT Cell Change Drops (%):
C O N HD OR _ ILTSBO_ _HTP+ C_ RNOXRN_ THD OR _ ILTSBO_ _HT P+ _ TN X R _ T
C O N HD OR _ IL_SBU _ _LH+C_C NAO PR NAT HD OR _ IL_SBD_ _LH+C_ NA PR AT
CN OS UHN CHHD COOR ___ ITLILS_SOBBS__ __+CTHUPR+ __CNRSNOXSVRR NUHRTT HDCH ORCO ___ ILITLSSBIOB__M__HT+ +R_P_ NETN RS _T
U
U CN OS UHN CHHD COOR _A__ I LIS_+SSCBUB__O_+L_HUCN_ NASR_ SPRD_T UHHTR CHHPC COOSH __A___IILU_S+QBD_L __+_LNCD_ RNA T
U CN OS UHN CSH_ D_CO H_RR_ IHLPS_R BOSS_X _C_+__URIU_P NSN+EWCSVR_ ORUHTT _NCH NS_CO RD___HTIRLSHIBPP_M OS+_C _R__HNIDE _ TLP+ _W
U CN OS UHN CSH_ D_CO H_R_+ IHUSPHS OSNB__ _R__S INCSUH + RPCCH ITPOCCO __N_NISUQ_SRD_L_ +TH_NR DHRPH COST_ H_E_ IC + PN I OC
U CN OS UHN CSH_ D_CO H_R_ IHPUPMS WOSE_S ___+_RUITI NM_RNNR_XSRTI UHT CH CO _H_ I DS_ P_L W_ + D R
1 0* 0
U N S I UHS _CH HCO _H_R_L IOCSB _PC__ TA+IPPUC_TR_ HNN+ TNXI S_SRR_ _UHTTHCHO _HCOL O_EB_ I _C_S TAPPN_ _TI+ ONC+ TX _HR_ T O
U N S UH CH CO __ INISM+ RU_ _TEI M_ NSE O_ ET X_ HAE OBC _L_ NI SR HT
I S _ H _H L OB __ LAC _TAN+ TIPSR A_T _H U_H L OB __ LAC _TAN+ TPR A T _ D
1 0* 0
I S _I SH __H HL OB_H _L_OATBP __TR_ CNA+RTXI _TSRS_N+ T_TVI SHROR__HT_HL OSB_H L__OATBP __T_MANR+TX T_RE_+NTTS R_ LT I
I S _I SH __H HL OB_H _S_OALCB __+TA_INA+STNIP SRT_RAH_TT T_H_HUU_HOLLO_B_ A_ND_ ALTCR+C_TTATNH+TP R_AQT _ _
I S _I SH __H HL OB_H _U_OACRE _T_S_ AN+RTTVI TS_RRRTN_+ TXI_HSRS_ __HTP LHOWB_H_D_ MOARL T__E_+NAWTSD TR_PR TLT+C_ NH R_
I S _I SH __H HS O_BH _C+ _OIASPN _T_I RPCATH T_HT_HN+ TU_I OSRRL __T_SHANDC _THR+CCTOTHP __I OCAQ HT__ +NT_ ER CT N
I S _I SH __H HUO_HE _I _MOART _T_RTAITN+MXITSR_ST_PT_HWN _H RDO L _ _ AWD T PRT C+_ NH R
I S _ H _H CO P _I APC _TH N+T_I SRR _TS H C _H CO P _I ACO TH_ T+N_ ER CT
I S _ H _H I OM _ ATI MT ST _ N R
It is also interesting to estimate the contribution of CC’s from UTRAN for which the UE fails to get 2G,
but manages to return to old channel in 3G. Therefore, the “Cell change order from UTRAN failure”
(RRC) message is received from the UE. It doesn’t trigger a dropped call, but it can be responsible of
dropped calls for poor coverage due to the delay in the IRAT CC execution:
Percentage of Outgoing IRAT Cell Change Failures (%) –not including drops-:
4.2.4 IF Handover Failures
17B
•
•
•
drop)
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
Percentage of RT IF HO lost (dropped) (%):
C O N HD O R _ _TLI FOB _+_TCHP_ OR NXT HD_ OR _ _TLI OFB _+_T HP_ TR XT
C O N HD O R _ _ _LI SFB C_+_ CHR_ ORS NTV HDR O R _ _LLI IFBM _+ _ H_R R E TS
C O N HD O R _+_ CSI FBO _ _NHRF _ _TDH RHC P OHS _+_ UQI L_ _R DT
C O N F _ _ DH RHR P OXS __ PU+I CWE O _ RNT F_ _ R_ DHT RHP P OC S H__ DI_+ PL
C O N F _ _ DH RH P O_ S R__ +SCIC CPO IP CN_F _R_ DTH RH P O_ S E__ C+ I NP
C O N C HD OOR N_ FLIT_F_BDO_H_HTRP+HMC_PRNOOSSX R_N__ ITRIHDM TOR_ _I ILTF BO_ _HTP+ _ TN X R_ T
C 1O *0N 0HD OR _ LI_FBD_ _HL +C_C NA O PR NAT HD OR _ LI_FBU_ _LH C_ NA PR AT
C O N HD OIR F _ _ LI_FHBS__ H_CHL R+ _OBC SNO_TVRPAN_RT+RTRHIDFXTTOR_ __H TLI_FHOBLI _MO_BH +R__TNEPA_ RS+TTR _T XTT _ T
C O N HD OIR F _ _ SI+ FHCB__OH_HL NOB FR__C_DTRAH_R+ STIRHFPCTVTOS_ HRH_ _I_UH+QLSL O_B_ ND_M RRA _+TETR TST _ L
C O N F_ _DI HFR _HPRHOSX_ H_S_ IUOPB+ +EIWC_F_ARO_RT HT_N _NTHF_UR_DOLHTR_HRPPAD+ OSTCTC_HTIHD _ TL_P+ _QW _
C O N F_ _D HR HPH OS_ _R ICS + PC I POC _NN F_ R_D THR HPH OS_ _E ICC +PN I OC
C O N F_ _DI HFR _HPMHOS S_ H_U_I ONME R___RAITT +TRIR TXT _ P_ HWD OL _WAD RTP+ T_C R H
I F _ H _ HC OP _IPCA_ +HTRI F _TT _R H S_ HC OP _IOCA _H+ TR _T TE C
1 0* 0
I F _ H _ HI MO _ IAM T ST _ R T
I F _ H _H L OB __ ATP _TR N+TXI FR_ _T H O _H L OB __ ATP _TT N+TX R_ T O
Percentage of NRT IF HO lost (dropped) (%):
IF _ H
IF _ H
IF _ H
IF _ H
IF _ H
IF _ H
_H L OB __ ALC _TAN+TIP FR A_T _H D_H L OB __ ALC _TANT P RA T _ U
A correct definition of neighbors is critical for both IRAT and IF HO.
_H L OB __ ACR T_S N+TVI FRR_ T_H S_H L OB __MAR T_E +NTS R_ LT I
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
_H UO E _ _ART T_R TN+ XI FR_ _ PT H W _H DO L _ _ AWD T PRT C+ _ NH R_
_H CO P _ I APC _TH N+T_I FRR _TSH C _H CO P _ I AOC TH_ +TN_ ER CT N
_H I OM __ ATI MT ST _ N R
_H S O B _+ _IAFN T_ RHT T _H UO L _ _ AND TR+C T TH _ Q _
Refer to internal Claro docs. Ref. ####.##: Multicarrier Strategy in Claro, Ref.####.##: PSC Plan and
Neighbor List Strategy in Claro.
4.3 Capacity Issues: Congestion Monitoring
12B
Following counters in Measurement: Cell resource (M1000) should be considered in the analysis:
CH_CODE_DOWNG_RT
The number of HSDPA channelisation code downgrades due to congestion of NRT DCH requests.
Updated: When the code downgrade is started due to a RT over HSDPA prioritisation.
CH_CODE_DOWNG_NRT_DCH
The number of HSDPA channelisation code downgrades due to congestion of RT DCH requests.
Updated: When the code downgrade is started due to a NRT DCH over HSDPA prioritisation.
Radio bearer downgrades and releases due to congestion:
RB_DOWNGR_DUE_OLC_TFC_SUBS
The number of radio bearer downgrades by the enhanced overload control using the TFC subset method.
Updated: When the RNC sends RRC: TRANSPORT FORMAT COMBINATION CONTROL to the UE.
RB_DOWNGR_DUE_DYLO_RL_POWER
The number of radio bearer downgrades by the dynamic link optimisation for NRT traffic due to RL power congestion.
Updated: When the RNC receives an NBAP: RADIO LINK RECONFIGURATION READY message from the BTS.
RB_DOWNGR_DUE_PBS_AAL2
The number of RB downgrades by priority-based scheduling (PBS) due to AAL2 congestion.
Updated: When the radio bearer is successfully downgraded.
RB_DOWNGR_DUE_PBS_BTS
The number of RB downgrades by priority-based scheduling (PBS) due to BTS congestion.
Updated: When the radio bearer is successfully downgraded.
RB_DOWNGR_DUE_PBS_INTERF
The number of RB downgrades by priority-based scheduling (PBS) due to interference congestion.
Updated: When the radio bearer is successfully downgraded.
RB_DOWNGR_DUE_PBS_SPREAD
The number of RB downgrades by priority-based scheduling (PBS) due to spreading code congestion..
Updated: When the radio bearer is successfully downgraded.
RB_DOWNGR_DUE_PRE_EMP_AAL2
The number of RB downgrades by pre-emption due to AAL2 congestion.
Updated: When the radio bearer is successfully downgraded.
RB_DOWNGR_DUE_PRE_EMP_BTS
The number of RB downgrades by pre-emption due to BTS congestion.
Updated: When the radio bearer is successfully downgraded.
RB_DOWNGR_DUE_PRE_EMP_INTERF
The number of RB downgrades by pre-emption due to interference congestion.
Updated: When the radio bearer is successfully downgraded.
RB_DOWNGR_DUE_PRE_EMP_SPREAD
The number of RB downgrades by pre-emption due to spreading code congestion.
Updated: When the radio bearer is successfully downgraded.
RB_DOWNGR_DUE_OLC_RL_RECONF
The number of radio bearer downgrades by the enhanced overload control using the radio link reconfiguration method.
Updated: When the radio bearer is successfully downgraded.
RB_RELEASE_DUE_DYLO_RL_POWER
The number of released radio bearers by the dynamic link optimisation for NRT traffic due to RL power congestion.
Updated: When the radio bearer is successfully released.
RB_RELEASE_DUE_PBS_AAL2
The number of released radio bearers by priority-based scheduling (PBS) due to AAL2 congestion.
Updated: When the radio bearer is successfully released.
RB_RELEASE_DUE_PBS_BTS
The number of released radio bearers by priority-based scheduling (PBS) due to BTS congestion.
Updated: When the radio bearer is successfully released.
RB_RELEASE_DUE_PBS_INTERF
The number of released radio bearers by priority-based scheduling (PBS) due to interference congestion.
Updated: When the radio bearer is successfully released.
RB_RELEASE_DUE_PBS_SPREAD
The number of released radio bearers by priority-based scheduling (PBS) due to spreading code congestion.
Updated: When the radio bearer is successfully released.
RB_RELEASE_DUE_PRE_EMP_AAL2
The number of released radio bearers by pre-emption due to AAL2 congestion.
Updated: When the radio bearer is successfully released.
RB_RELEASE_DUE_PRE_EMP_BTS
The number of released radio bearers by pre-emption due to BTS congestion
Updated: When the radio bearer is successfully released.
RB_RELEASE_DUE_PRE_EMP_INTF
The number of released radio bearers by pre-emption due to interference congestion.
Updated: When the radio bearer is successfully released.
RB_RELEASE_DUE_PRE_EMP_SPREA
The number of released radio bearers by pre-emption due to spreading code congestion.
Updated: When the radio bearer is successfully released.
RB_RELEASE_DUE_OLC_RL_RECONF
The number of radio bearer releases by the enhanced overload control using the radio link reconfiguration method.
Updated: When the radio bearer is successfully released.
4.4 Other Faults
13B
Section 3.2.8 describes the OTHERS Speech DCR (%).
For further analysis of this dropped calls contribution, try to correlate with Transport Network, RNC,
CORE,… issues.
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. Ref. ####.##: Optimization Guidelines: Transport Network in NSN for
further details.
For further investigation, check following counters in Measurement: L3 signalling at Iub (M1005)
Counters in this section are updated only for base stations using 3GPP NBAP protocol.
RL_FAIL_SRNC_RNL
The number of radio link failures on SRNC due to radio network layer cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK FAILURE message from a BTS.
RL_FAIL_SRNC_TRL
The number of radio link failures on SRNC due to transmission layer cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK FAILURE message from a BTS.
RL_FAIL_SRNC_PROT
The number of radio link failures on SRNC due to protocol cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK FAILURE message from a BTS.
RL_FAIL_SRNC_MISC
The number of radio link failures on SRNC due to miscellaneous cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK FAILURE message from a BTS.
RL_FAIL_DRNC_RNL
The number of radio link failures on DRNC due to radio network layer cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK FAILURE message from a BTS.
RL_FAIL_DRNC_TRL
The number of radio link failures on DRNC due to transmission layer cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK FAILURE message from a BTS.
RL_FAIL_DRNC_PROT
The number of radio link failures on DRNC due to protocol cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK FAILURE message from a BTS.
RL_FAIL_DRNC_MISC
The number of radio link failures on DRNC due to miscellaneous cause.
Updated: When a dedicated NBAP signalling entity receives an NBAP:RADIO LINK FAILURE message from a BTS.
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] NED 5.5. NSN Electronic Documentation Library
Nokia WCDMA RAN, Rel. RAS06, System Library v.6
Nokia Siemens Networks WCDMA RAN, Rel. RU10, System Library, v. 1
Nokia Siemens Networks Flexi BSC, Rel. S14, Site Documentation, v.1
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 userperceived call drops.
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:
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 measurements–CRC 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.
