79118694 Optimization Guidelines Retain Ability NSN Draft1

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 DCR (%)..........................................................................................................................14 3.2.2 20BIu DCR (%)...................................................................................................................................15 3.2.3 21BIur DCR (%)..................................................................................................................................15 3.2.4 21BBTS DCR (%)...............................................................................................................................16 3.2.5 20BUE DCR (%).................................................................................................................................16 3.2.6 21BUnspecified Error DCR (%)..........................................................................................................16 3.2.7 20BPre-emption DCR (%)...................................................................................................................16 3.2.8 21BRNC (OTHERS) 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_: 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__: 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__ +_ER_VC ERMOA MEBPINLCP __VEAC _ CPS ET_ _CV+  RE_ RUE _N C S N B I L_ _A CEC_ S+I_TRUI_ _UAVCF BOAI L_IN_CA CVEC_ SR_T _+R+A_ CVFAD  OADI ONI I CO V

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 ROA NI C V

 B I L_ _A CEC_ SR_T+R_ N_ VCNAF C OABCI LIN_ C _AV CEC_ SU_T _UE_ CVFE OA NI C V B M _ AP _CE+CRT SA_ _CB LVCO__OAC INC_SCS STVR_+ + R_CVN RNOC  ECNI C V E _ B L __ AC C_PS PT__ +_ER_VC ERMOA MEBPINLCP __VEAC _ CPS ET_ _CV+  RE_ RUE _N C S N B I L_ _A CEC_ S+I_TRUI_ _UAVCF BOAI L_IN_CA CVEC_ SR_T _+R+A_ CVFAD  OADI ONI I CO V  B I L_ _A CEC_ SB_T+RB_T_ VCATFS OSAB I LI_NC_A VCEC_ SI_T+U+_I _URCVF ROA NI C V  B I L_ _A CEC_ SR_T+R_ N_ VCNAF C OABCI LIN_ C _AV CEC_ SU_T _UE_ CVFE OA NI C V

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_ URE _N C S N  R A B I L_ _A CAC S+_TR_I _USAF TBAI RL_ _AE CAC S_T _R+_ SFA T AD R I EO  R A B I L_ _A CAC S_T+_RB_ SAFT TASB IRL_ E_A CAC S_T+_I _USF  RTA R E  R  A B _LA_ CP TS P_ REI _ _EUE+ NRR SA_ CB N_L A_ CP TS P_ RBE E_ UE+  RN _S C N  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+ACAI UAS_TC_U_K S FE TA R E 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 I O  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 E A  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_ URE N_ CS N  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_DR RUE I EO_N C S N  R  RAR BAA _I ALBB II_CLL__P T__ASAR_ PC__FAACCI+ UANSRS_+_TTE+TAR_R_BI __EBUSASATFF_ITTALBAASBI_IRCRL_LP_T_EASE_GA_ C_PFAC_ABCAUSSA_T_TE+_CR_+I__SUKSFAFTTRADA RR I EOE   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 E  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 A R E 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 FEG TA R E  R  AR B A _LAB_ MCP_ TS PAP_ REI_C_A_+EPURET+ NSRRA_ SA__CBCBSL ON__LT_A_APRCP C_STSE PS__TRBE+ RS_E_ UERTN+  RNREC_S CE NA  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_I OURE N_ CS N  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 ADR I EO  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 A R E    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 A R E  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 GD_ 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_ OIOD_H LMRR___EI_ NOLHBH )T_S GNS_ ODR R_ B 1 *0[ -10 ]R 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 O _ H H _ _ R S B _ G  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 G R  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 ES _ D  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 SHCLSOG__ F_RS D_ARE _NI_LB D_ +GRH SRLS _C_ D _  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_ HTSOIH L_HS _R___ F EDOBHA L_I _GLBS+O_G HRT R HS _  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 _ D _   R E L L _ _ FDA A SL+RI CLL EOH_ L LH__ _ RISFDAN A_ SL T I LCL O_H H__ RSB _G  R

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 _ OE _R B G R ] S _ MR E_ HL +P_S NS_ _OE MR_R IE_ N HL +T_S N _  OE _R B G R S _ _R E E M LI NP_+PP_T SHR _ ES_R _E EEM L_B P_ +GP_ HR ES _ E _ S _ FR A E I LI N+_ P RTH S LS_ _F_R AE E I_ LB _+G RH R LS _ _ E _  S _ _R F E A L_ I _IL+NPO_ STHT _ SH_R _F EEA L_ I _BL + O_G HT R HS _ E LS_ __EES F_WDT +AIORN_C+ PH_ITELHSHS _S_L_ ES__LI__WDNRT_E_BIO_FT+GDH_ AH+RS CS_I _LHD _ _ _B R G  TS_ _ HEES _WDET INION_R+CP+TH_ RSDT_HS _ _E_FES D__WLA_TOTIGO_I_ LRHH_E DS_DE_ BD RC_G B_H RF _ A O

P P P P R  R E  LP  P R E L IL _   1 *0 0  R E L O_ ER D+MR CE_ HIL NO_ TENR D+M C _ HB _G N R

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 _ _B R G R  L T_ HE DE I NRC+R T_H EF _ LA OT_I LHE _DE B RCG _H RF _ A O I L _

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 O

 R A BL _A AC V_CS GP DT_+_R_V_ERARTOMNAMBELI PCBV__ A_EC HPCS ELT_ _V+C_ ER_O RUE _ N C S N  R A BI L _ _A CE C S+_ RT I_ U_AV F BOI AL _ I_AC CE C S_ T R+_ _ VAF ODA I CO 0*  R0 A0 B L _ AC PCS _T_+ERC_ MARO BEPLN _ VAC _PCS ET_ _C+ _ ER_ RUE _ N C S N  RR AA BBII LL__ __AA CCE_CC S+IS_ +RTUTRB__ _A_VCAT FFBOISBOAIAL _L _IN_AC_AC_CVCECRS S_T++T_AI__UC_ VDF FROAOIAONI C V 0* R 0 A 0 BI L _ _A CE C S_ +T R_ _ VANF OBCAI L _I C_A CE C S_ T U_ _ VEF OA I C  R A BI L _ _A C_C BS+TR_T _ ACSF BOIA L _N_A CV_C SI +UT _ _RC F OA N V  R A BI L _ _A C_C RS +TR_N _ CA FC OBAI L _N _A VC_C US T _E_ C F OA N V  

3.1.3.2 Video Minutes per drop

6

3.1.3.3 HS Minutes per drop 42BU

6


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_ REU _N C S N  R A B I L_ _A CEC S_+T R_I _UVAF OBAI L_I C_A CEC S_T _R+_ VFA OAD I ICO 0*  0 0 R A B I L_ _A CEC S_T+_BR_ VTFA OASB I IL_ C _A CEC S_T+_I _UVF  ROA I C  RR AA BBIL L__ _AACCECPCSS_T_+T_+_R_ERCV_ FNAMAROOABCBIEPLINL_C__AVACCEC_PCSS_TET__U_ _VC+_FE EROA_ RUEI C_ N C S N  

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 OAI ON V 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 OA N V  R A BI L _ _A C_C RS+TR_N _ CA CF BOAI L _N_A VC_C US T _E _ C F OA N V  

3.1.4.3 HS drops per hour 45BU


3.1.5 Overall Service Retainability - OSRET (%) 18B

A V GD _ _ R T NAM VB _ _C H S L _ C O

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 R B L _ _ A ( CRE TAM+R_B PRA ) _EB LP _ _ A ( CR S TAP _BE R+ )_ _EE U R N _ C N B I _L A_ (CUR+RT A A_ BFB )AI _L AI_ (CAR TD+A _ IBFO )A _ R  B I _L A_ (CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _ I  B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _ U 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 DCR (%) (Percentage of 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 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 to the Overall DCR. High value (e.g. >2%) indicates retainability problems related to the RF environment. 3.2.2 Iu DCR (%) (Percentage of 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 R B L _ _ A ( CRE TAM+R_B PRA ) _BE LP _ _ A ( CR S TAP _BE R+ )_ _EE U R N _ C N B I _L A_ R(CUR+ART ABA_ IBF_LB )AAI_ _L (CUAI_R (TCRAAR_TDB+AF _ )AIBFO_ )AI _ R  B I _L A_ (CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _ I B M_ AP C+_ R (T RA _ ABC L B_O_ A) ( CRN TA+ C _B R ) _E S R B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _ U B L _ _ A ( CRE TAM+R_B PRA ) _BE LP _ _ A ( CR S TAP _BE R+ )_ _EE U R N _ C N B I _L A_ (CUR+RT A A_ BFB )AI _L AI_ (CAR TD+A _ IBFO )A _ R  B I _L A_ (CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _ I  B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _ U

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 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 DCR (%) (Percentage of Voice calls dropped caused by drift RNC procedures; for example, radio link reconfiguration failure in DRNC) 21B


High value (e.g. >2%) indicates retainability problems related to Iur-interface.

3.2.4 BTS 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  R A B L _ _A ( CRE TAM+R_B PRA ) _BE LP_ _ A ( CR S ATP _BE R+)_ _EE U R N_ C N


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 _ R  (CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _ I  R(CNR A+TRCA B_ ABI F_L B)AA_I_ _L(CRERA_ T(ACER_ BTFA _)A B_F U)A _ U

High value (e.g. >2%) indicates retainability problems related to Iur-interface.

3.2.5 UE DCR (%) (Percentage of 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 R B L _ _ A ( CRE TAM+R_B PRA ) _BE LP _ _ A ( CR S ATP _BE R+ )_ _EE U R N _ C N


B I _L A_ (CUR+RT A A_ BFB )IA _L AI_ (CAR TD+A _ IBFO )A _ R  B I _L A_ (CTR +TSRA _ ABF B)AI__L BA_ (CUR +TRA _ BF )A _ I  B I _L RA_ A(CNRB+TIRCA_L_ AB_F (BC)ANRI_ _LTSRAA__ PB(CFERE)AT _A _UEBF R)A _ UC N 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 R BB LM__ _ AAP( CCR+_ER (TTAM+RAR__B ABPCRA )L B__OBE_ ALP) (_ _CRAN( TA+ CRCS_BATPR )_BE_ER+ )_S _EERU R N _ C N BB IL __L _ AA_ ( (CCRUER+RTTAM+ARA__B BPRAFB) )IA_BE_L LPA_I_ _ A(C(ARCRTSD+ATA_PIBF_OBE R)A+ )__ _EER U R N _ C N BB II __LL AA__ ((CCUTRR++RTTSRAA A__ ABBFFBB))AIAI_L__L ABI_A_ (C(ACRURT+DT+ARA_ _IBFBOF )A)A_ _ RI  BB II __LL AA__ ((CCTNRR ++TTSRRCAA __ AABBFF BB))AAII___L_L RBAA__ ((CCUERR+TTRAA __ BBFF )A)A __ IU   B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _ U

High value (e.g. >2%) indicates retainability problems related to the UE.

3.2.6 Unspecified Error DCR (%) (Percentage of active releases with "unspecified failure" cause received from CN). 21B


High value (e.g. >2%) indicates retainability problems to be investigated further, likely CORE, TX, Protocol,… issues. 3.2.7 Pre-emption DCR (%) (Percentage of RT 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 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) DCR (%) (Percentage of 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  R A B L _ _A ( CRE TAM+R_B PRA ) _BE LP_ _ A ( CR S ATP _BE R+)_ _EE U R N_ C N


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 _ R  BN IS __L _DA_ H (RCTHRC+PTSROAHS_ AB_F+ CUIQB)AIO_L__L B_RAN_ DS(TC_UR_D+TRHAR_HWBPF OS)AR+__ _IUI R E T _ P N S _ _D H R HPP OCS H+_ CDI _ ORL N_T SD_ _D H R H_P RO+S T_ RI S C P B I _L A_ (CNR +TRCA _ ABF B)A I_ _L RA_ (CER T A _ BF )A _  U

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 _ I  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 XT _  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 OTS _ WI P S _

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+ PNC EE _ E R  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:

•

RADIO: Radio coverage issues: Uplink problems Downlink problems

•

BTS: Mobility issues: Handover failures Missing neighbor relations IRAT/IF handover issues

• •

PRE-EMPTION: Capacity issues

o o o o o

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+_ _XIURR_ETTT _ P  C S OU NC SO_C _D_H RLI SHBUP _O_CSLHC__+H+ SHCINDA_UOPRRL CA_NTTOCDS__ __D LIHSRBDH__P_LHROSC+ +_ TH_AN IR PR SAT C_ 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 _ T_I L  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+ +HCHR_SR RNOUEX TRSNC_ OH_TPCD O_R DI _S PLTI _SWB_OH_D_+THR+ PP__RCRN XHT R__ T  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 _ RTE TC  U SN US CHU OCHC _ COI MS__RTI_L_STOHBI _+MHUT_ PS_N R_ SNTXHU HC CO __ TILSOB_+ T_  P_ RT XT C O N HD OR _ L_I SSB _C_+ HCR_ ORS VTN SR_ _D H R HPR OST _ IW  P S _   U 11 *00[* -100 N S HU HC CO R__ IL_S SB_+CU_ R_N RSS VTHU HC CO __ LILSI BM_+ _] _R R E T S  U  NI( SI S_ HU_H H__HCHLRHCOOBT+O__U__TIST_PSAAN_-CBSUR_T+NTSI_SXTSTTHURRR_EHTCTHTAMACO_OHNBLP__+OB_LIWSNE_ITS_POA__HSET+NTT H_XXT_RRE_OTTC_ O_R 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 __RRD XT  U  NI S S_ HUH _HCHL COOB _H__CID_RSA _PL_S+TNIW+_SVTURD_RNTPH_S_CHRSLHU TOBHC _MCORA R__+ETNICSSST RCP_+_ ITPLC _I HR _T  U  NI S S_ HUH _HCHS COOB E+__I_ISCSAN _NP_T+RHUIOTC_THNU_H ORSL_ HUT_N DAHC+R TCCOTTH__ RII+_SMTQ_ _ _ I M S  U  NI S S_ HUH _HCHU COOE_C__IRESAT _M_LRT+NILETXS RR_ THGP _WH_D OL _W AD RTP+ _TC N H R _ TP   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 TC N  I( SI S_ _H H__HIRHMOTO___TT_IAAM-CSUTT SSTT _REN AMAR NBP _L NEI SO_ HET HX_ EO C_ _R T )  

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 AT  CN OS UHN CHHD COOR ___ ITLILS_SOBBS__ __+CTHUPR+ __CNRSNOXSVRR NUHRTT HDCH ORCO ___ ILITLSSBIOB__M__HT+ +R_P_ NETN RSXR _T 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 TPR T  U  CN OS UHN CSH_ D_CO H_RR_ IHLP_SR BOSS_X _C_+__URIU_P NSN+EWCSVR_ ORUHTT _NCH NS_CO RD___HTIRLSHIBPP_M OS+_C _R__HNIDE _RTSLP+ T _WD R _ N R  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 _ N R T  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 RP _CN R T 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 _CS_ TAPPN_ _TI+ ONC+ TX _HR_NT_ RO T  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+ TPR 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 RO_ 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 _ _D  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_I NH R_ PT  I S _I SH __H HS O_BH _C+ _OIASPN _T_I RPCATH T_TH_HN+ TU_I OSRRL __T_SHANDC _THR+CCTOTHP __I OCAQ TH__ +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_ PT  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 N  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 XT _  C O N HD O R _ _ _LI SFB C_+_ CHR_ ORS NTV HDR O R _ _LLI IFBM _+ _ H_R R E TS _  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 W_ D R _ R  C O N F _ _ DH RH P O_ S R__ +SCIC CPO IP CN_F _R_ DTH RH P O_ S E__ C+ I NP IOC _ R T  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 AT  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 XTT _ T O  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 I  C O N F_ _DI HFR _HPRHOSX_ H_S_ IUOPB+ +EIWC_F_ARO_RT HT_N _NTHF_UR_DOLHTR_HRPPAD+ OSTCTC_HTIHD _ TL_P+ _QWD _ R _ N R  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 _ N R T  C O N F_ _DI HFR _HPMHOS S_ H_U_I ONME R___RATIT +TRIR TXT _ P_ HWD OL _WAD RTP+   T_C R H T _ P I F _ H _ HC OP _IPCA_ +HTRI F _TT _R H S_ HC OP _IOCA _H+ TR _T TE C N  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 RA 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_ PT  _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.

T

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.

79118694 Optimization Guidelines Retain Ability NSN Draft1

Recommend Documents