How to perform trouble shooting based on counters

Company Confidential
1 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials
How to perform trouble shooting based on counters
• Pre-requisite: Capture ALL the measurement dumps (e.g., ServLev, CellRes,
RRC, L3 signalling, etc)
• Calculated each PI with the breakdown on the failure cause(s)

RRC Connection Setup Phase
• RRC Connection Setup Phase is from RRC Connection Request to RRC
Connection Setup message
• In the RRC Connection Setup Phase, there are 8 possible setup failure causes
• For each failure cause, we can look into analyzing (or trouble shooting the Top-N
cells)
8 failures causes

1. RRC_CONN_STP_FAIL_AC
• For e.g, in the previous slide, we see that there were 1085 RRC Setup failure due
to AC reason
• Then we zoom into Top-N cells for further analysis. For instance, the worst cell is
WBTS: 110B9WC, WCEL-3

RRC_CONN_STP_FAIL_AC
• First check the alarm history is there any alarm happened to this site/cell on that
day
• Once confirmed there was alarm happened, you may skip to analyze this
site/cell. This is because when alarm happened, no one can confirm it affects the
way counter is triggered or not
• Check any parameter(s) error.
• Failure due to AC has to be further analyzed is because of UL or DL
• Next, we look into Cell Resource table on this WCEL (i.e. 110B9WC-3)
• For UL, then we will look into AVE_PRX_NOISE, MAX_PRX_NOISE_VALUE,
MIN_PRX_NOISE_VALUE, and AVE_PRXTOT_CLASS_x, where x is from 0 to
4 (a sample will be presented in next slide)
• For DL, then we will look into AVE_PTXTOTAL_CLASS_x where x is from 0 to 4

Prxtotal Performance
• The Prxnoise look quite reasonable, i.e., no high noise. The max. & min. noise is
also quite alright. So the failure is likely not in UL
• Next, look at Ptxtotal (DL) performance
Actual value=(value/100) then put a –ve sign??

Ptxtotal Performance
• The sample in class 3 is quite high. Indicate there could be DL power issue (AC
rejection due to DL)
Some problem in term
of value here??

RRC_CONN_STP_FAIL_AC
• Next, check the M1002 (Traffic table)
• Check M1002C1 DCH Request for Signalling Link Reject in UL
(DCH_REQ_LINK_REJ_UL_SRNC)
• Check M1002C2 DCH Request for Signalling Link Reject in DL
(DCH_REQ_LINK_REJ_DL_SRNC)
• From the traffic table, we can conclude that the AC reject is due to DL (proven that the
“guessing” in previous slide is correct
• Suggestion: Try to tune Ptxtarget to a high value (if there is still room to tune) and monitor
the performance
• Note: It could be BTS problem as well (like WSP, BTS s/w problem, etc). But this should
be solved by the latest BTS s/w release.

Another Example on Failure Due To AC (UL Problem)
Suspect it is due to UL
Because there is Class_4
triggered
Confirmed from
Traffic measurement

2. RRC_CONN_STP_FAIL_BTS
• The second failure cause for RRC Connection Setup is due to BTS reason
• Check alarm history if there is any alarm happened to this site/cell on that day
• Once confirmed there was alarm, you may skip to analyze this site/cell. This is because
when alarm happened, no one can confirm it affects the way counter is triggered or not
• Check L3 Iub counter (M1005) for the followings
• M1005C10 RL Setup Fail for 1st RL due to O&M intervention (SETUP_FAIL_RL_O_M_INTERV)
• M1005C11 RL Setup Fail for 1st RL due to already active (SETUP_FAIL_RL_ALREADY_ACTIV)
• M1005C12 RL Setup Fail for 1st RL due to HW resource not available
(SETUP_FAIL_FIRST_RL_HW_RES)
• M1005C13 RL Setup Fail for 1st RL due to not enough resource
(SETUP_FAIL_RL_NOT_ENOUGH_RES)
• M1005C14 RL Setup Fail for 1st RL due to BTS not responding
(SETUP_FAIL_RL_BTS_NOT_RESP)
• M1005C15 RL Setup Fail for 1st RL due to BTS general reason
(SETUP_FAIL_RL_BTS_GEN_REA)
• Sometimes failure could be due to wrong configuration data in BTS. If still fail due to not
enough resource (no alarm), then check configuration data
• Check also pool capacity to determine any WSP bottleneck
• If failed due to no respond from BTS and no alarm  could be sleeping cell. Delete COCO
& recreate it (or reset the site to see if helps)

RRC_CONN_STP_FAIL_BTS
May need to check
BTS alarm!!!

3. RRC_CONN_STP_FAIL_TRANS
• Check BTS/AXC/Transmission alarm history
• Check physical layer for ATM alarms and link “error seconds”
• Normally happen to site with 2xE1 IMA links
• Check parameters setting (esp. COCO, TRS related) vs. planned value
• Could be due to TRS capacity bottle neck. Need to confirm will this trigger
M1001C5 or C399?
• Check UNI measurement (M548)??
• See next slide for parameter mismatched case

RRC_CONN_STP_FAIL_TRANS
2xE1 config here
But 1xE1 setting in
AAL2 UP

4. RRC_CONN_STP_FAIL_HC
• Problem at initial link setup inside RNC handover program block (HA3)
• Usually a data build issue, e.g. CellID (wcel does not exist)
• This counter shouldn’t be triggered
• Suggestion: Check RNC data build for failure cell

5. RRC_CONN_STP_FAIL_RNC
• Check BTS & RNC alarm history
• Difficult to trouble shoot as this is likely due to some RNC unit alarm
• Could be due to parameter mismatch (what parameter???), timer expiry, L2
problem, etc

6. RRC_CONN_STP_FAIL_FROZBS
• Check BTS alarm
• Based on counter description, this counter seems only trigger when AC block call
setup to ensure the setup of emergency calls
• Never encounter this counter triggered yet. Likely to observe it when there is high
load in the system AND also emergency calls initiated

7. RRC_CONN_STP_FAIL_RNTI_ALLO
• Check RRMU loading
• Check RNC alarm??? (any RRMU unit restart, etc??)
• Never encounter this counter triggered yet

8. SPARE_1_SERVICELEVEL
• This counter represents RRC Setup Fail due to Iub AAL2 Transmission reason
• Never encountered this counter triggered yet. Why? Need to load the right OSS
s/w & CD level??
• May have to cross check with M1001C5 RRC_CONN_STP_FAIL_TRANS (RRC
Connection Setup Failure due to Transmission reason) to determine which
counter is triggered
• Check BTS/AXC/TRS alarm
• Check AXC/TRS related parameter consistency (like the case in failure due to
TRS reason)

RRC Connection Access Phase
• In RRC Connection Access Phase, there are 3 failures causes
• M1001C9 RRC_CONN_ACC_FAIL_RADIO (RRC Connection Access Failure due to radio
interface synchronization)
• M1001C10 RRC_CONN_ACC_FAIL_MS (RRC Connection Access Failure due to Uu
interface)
• M1001C11 RRC_CONN_ACC_FAIL_RNC (RRC Acc Fail due to RNC Internal Reason)

1. RRC_CONN_ACC_FAIL_RADIO
• Check RRC Access failure per
establishment cause to determine whether
failure is mainly due to inter-RAT cell
reselection or registration, etc
• If there is high attempts/failures on the
inter-RAT cell reselection or registration,
then likely to be coverage issue
• May indicate the inter-RAT cell reselection
parameter need to optimized in case high
inter-RAT cell reselection attempts/failures
Distribution for Establishment Cause
36%
17%
12%
8%
7%
3%
2%
2%
2%
2%
2%
1%
1%
1%
1%
1%
1%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
intr_rat_cell_re_select_c
radio_interface_c
registration_c radio_interface_c
registration_c ms_c
intr_rat_cell_re_select_c ms_c
orig_conversational_call_c
radio_interface_c
orig_conversational_call_c ms_c
orig_high_prior_signal_c
radio_interface_c
term_conversational_call_c
radio_interface_c
term_conversational_call_c
ms_c
term_low_prior_signal_c ms_c
term_low_prior_signal_c
radio_interface_c
orig_low_prior_signal_c
radio_interface_c
orig_high_prior_signal_c ms_c
orig_interactive_call_c ms_c
orig_low_prior_signal_c ms_c
orig_interactive_call_c
radio_interface_c
detach_c radio_interface_c
call_re_establishment_c
radio_interface_c
term_interactive_call_c ms_c
detach_c ms_c
orig_background_call_c
radio_interface_c
term_interactive_call_c
radio_interface_c
call_re_establishment_c ms_c
term_background_call_c
radio_interface_c
term_cause_unknown_c
radio_interface_c
orig_background_call_c ms_c
Likely be coverage issue

RRC_CONN_ACC_FAIL_RADIO
• Check any parameter inconsistent
• Check Prxnoise, and Ptxtot performance
• Probably can tune T312 to 6sec & N312=2 or 1 to see any performance
improvement
• Perform drive test to confirm any DL coverage problem. It could be due to UE not
receiving RRC Connection Setup message (i.e., SCCPCH power not enough) ->
Tune SCCPCH power if required
• Failure could be UE model related. Reason: Some UE models perform badly
when the RF performance is no good (e.g., when Ec/No < -11dB). Need to use
Traffica/ICSU log to confirm UE model. This check is tedious and should be done
only after all checks and the problem still occurring.
• In some projects, it has noticed that Sony Ericsson Z1010 perform badly when
RF is weak (similarly to other models on EMP – Ericsson Mobile Platform, eg.
LG) – see next slide

RRC_CONN_ACC_FAIL_RADIO
• Different UE performance vs. initial Ec/No
Success Rate for Initial Synch in RRC Access :
Nokia/LG
50.00
55.00
60.00
65.00
70.00
75.00
80.00
85.00
90.00
95.00
100.00 -25
-22
-20
-17
-15
-12
-9.5
-7
-4.5
-2
EcNo
Success
Rate
%
Nokia 6630, 6680
Nokia 7600
LG 8130, 8138, 8180,
8330
LG U8110, 8120

2. RRC_CONN_ACC_FAIL_MS
• This failure should be much lesser than L1 synch problem
• It is triggered when RNC received NBAP: Synchronization Indicator. BUT there is
no RRC Connection Setup Complete received
• Check any UL interference
• It indicates there is some problem with UL coverage. Try to tune CPICH to have
more balance between UL & DL coverage (if it is not UL interference)
• Maybe due to BTS problem. Try to reset the WBTS to see problem still exist
• May due to WSP problem (refer to John’s WBTS trouble shooting for 35003WC)

3. RRC_CONN_ACC_FAIL_RNC
• Normally this counter does not have high triggers
• If there is high failure due to RNC, pls check RNC alarm

RRC Connection Active Phase
• RRC Active Phase has 8 failure causes
• M1001C15 – RRC Active Fail due to Iu Interface (RRC_CONN_ACT_FAIL_IU)
• M1001C16 – RRC Active Fail due to Radio Interface
(RRC_CONN_ACT_FAIL_RADIO)
• M1001C17 – RRC Active Fail due to BTS Reasons (RRC_CONN_ACT_FAIL_BTS)
• M1001C18 – RRC Active Fail due to Iur Interface (RRC_CONN_ACT_FAIL_IUR)
• M1001C19 – RRC Active Fail due to Ciphering Fail (RRC_CONN_ACT_FAIL_CIPH)
• M1001C20 – RRC Active Fail due to Integrity Check
(RRC_CONN_ACT_FAIL_I_CHK)
• M1001C21 – RRC Active Fail due to RNC Internal Reasons
(RRC_CONN_ACT_FAIL_RNC)
• M1001C391 – RRC Active Fail due to UE (RRC_CONN_ACT_FAIL_UE)
• Majority of the failures seem to be:
• RNC Internal
• Iu
• Radio
• UE

RRC Connection Active Phase
Majority of failures
This counter
is not triggered
Correctly in
RN2 GCD1.0

RRC_CONN_ACT_FAIL_IU
• Generally is signaling connection fails between the RNC and CN
• Next to check RNC & CN alarm. In case the problem happen consecutively for
many days (eg. 4 to 5 days) and the same cells. Then some ICSU logs need to
take on the particular WBTS/WCEL to find out the root cause
• Wrong parameter setting in MSC (INFO IN SCCP C-REF MESSAGE
SUPPORTED was enable), this counter was incremented during the detach
procedure nevertheless the detach was successfully - Need confirmation???

RRC_CONN_ACT_FAIL_RADIO
• In general, this is due to “radio link failure” because of loss of L1 synchronization
• Need to check coverage
• This is the top 1 failure in most of the network
• Possible cause could also be due to some UE not responding to Radio Bearer
Reconfiguration message from RNC
• Check the Radio Bearer Reconfiguration Success Rate from RRC (M1006) table:
100*(RB_RECONF_COMPLETE/RB_RECONF). If the success rate is very low, this is
very likely due to UE not responding to RB Reconfiguration message. It could be either UE
problem or coverage issue
• CPICHToRefRABOffset is 0dB (new default) which give 2dB more power than the old
default value. Hopefully this can provide more power to sustain a call in poor coverage
area
• If the problem continuously happen to a WBTS/WCEL for many days. Perform a drive test
to check any coverage issue. Else, ICSU log need to be taken and analyze the PMI ticket
to see the high failure cause

RRC_CONN_ACT_FAIL_RNC
• Check RNC alarm
• Typically this is due to some timer expired in RNC
• Check is the failure also happen to WBTS/WCEL near to RNC border
• For e.g., SRNC relocation failure may result in this counter incremented
(t_reloc_prep timer expired)
• It may be due to some timer value set too small in RNC. For e.g., Iu-PS signaling
cell delay variation time
• Check L3 SRNC relocation counter??? (additional information need to be added
here. Will be added in future!!!)

RRC_CONN_ACT_FAIL_BTS
• Normally this is failed due to BTS alarm
• So far this cause is not the majority

RRC_CONN_ACT_FAIL_Iur
• No idea for trouble shooting yet
• Could be related to inter-RNC SHO or SRNC relocation or anchoring problem

RRC_CONN_ACT_FAIL_I_CHK
• No failure yet
• If failure occurred, likely to be some system or UE issue??
• Integrity check is not RF issue

RRC_CONN_ACT_FAIL_CIPH
• No failure yet
• If failure occurred, then likely to by system or UE issue
• Ciphering is not RF issue

RRC_CONN_ACT_FAIL_UE
• This counter is not trigger correctly in RAN04 GCD1.0
• GCD2.0 or 2.1 will have correction
• Currently this is due to no response of RRC message from UE
• But Cell FACH <-> Cell DCH transition will also cause this counter to be updated
-> causing inaccuracy

How to perform trouble shooting based on counters

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

Similar to How to perform trouble shooting based on counters

Similar to How to perform trouble shooting based on counters (20)

Recently uploaded

Recently uploaded (20)

How to perform trouble shooting based on counters