02 RN31572EN20 PM Monitoring

3G RANOP RU20
Module 2 – Performance Monitoring & Data Analysis
Soc Classification level

1 © NSN Siemens Networks Presentation / Author / Date
Course Content
KPI overview
Performance monitoring
Air interface and neighbor optimization
Capacity & traffic optimization
Paging and inter-RNC optimization

Module Objectives
At the end of the module you will be able to:
• Describe 3G RAN performance monitoring process
within R99/R5/6
• High level KPIs -> PIs -> Counters
• Busy Hour problematic & reporting periods
• Describe the mechanism for call analysis related to
• RRC/RAB setup/access failure
• Session setup failure (NRT, HSDPA, HSUPA)
• SHO/ISHO session/event failures
• HSDPA setup & throughput and their failures
• List possible reasons for failures & improvement activities

KPI analysis hierarchies
Call/Session setup monitoring & analysis by tools
Release 99: call setup (RRC/RAB)
R99: Call Drop
- Radio link failure rate
- Radio link success rate
R99: Mobility (SHO, HHO, ISHO)

HSPA setup
HSPA mobility
- Serving Cell Change
RRC states
Appendix –
- failure events

KPI analysis hierarchy - performance layers
issues
Performance indicator strategy
Call/Session setup monitoring

& analysis by tools
Define tools, interfaces, counters,
and indicators to monitor the NW
performance. Therefore detect at
different phases KPI’s. Release 99: HSPA
Tune RAN parameters and
call setup call setup
optimize the quality of the NW
call drop call drop
Mobility (HO’s) mobility
RRC states
Iub
WBTS

KPI analysis – hierarchy of evaluation levels
Performance data hierarchy
The available data could be classified as in the figure below
There is no point looking at detailed data if the “bigger picture” is not clear
KPIs (OCSR, CSSR, CCR) Traffica data

More details
More Service Level
understanding Traffic
More
complexity SHO ISHO IFHO HHO
More cost &
time in Cell Resource
acquisition Signalling (RRC, Iub, Iu, Iur, Relocation)
PMI Tickets NSRP (internal) Probe statistics
ICSU logs (internal) Interface trace Subscriber trace

KPI analysis – hierarchy layers
What is cell-specific, what is not
- Handover Performance
- Traffic
- Cell Resources
- Iub Signalling
Monitor Cell/Neighbour cells
Indicators, counters and parameters Availability - missing cell has impact
detect faults at different layers to neighbouring cells performance also
Iub
WBTS
- Cell Availability
- Failures due to Radio, to BTS, to transport
KPI analysis - RAN parameter RU10 objectives
RAN parameter and performance strategy
RNC
WBTS
RRM optimisation
and tuning at different levels/
NW - elements
WCEL

KPI analysis – hierarchy of cell layer
What is cell-specific, what is not
The Complexity of the performance data increase with

the number of cells in the network, if it is not properly
summarized. Almost all data has to be analysed at
WCELL or WBTS level for the worst cells -> Evaluation
over time and comparison between large areas (Cities,
RNCs) is still required
• Cell Availability Monitor Cell/Neighbour cells
Availability - missing cell has impact to
• Failures due to Radio, to BTS, to transport neighbouring cells performance also
• Handover Performance
• Traffic
• Cell Resources
• Iub Signalling
Some data is better analysed at RNC level->
Here only the time evolution and RNC comparison is
useful
• Failures due the RNC, Iu, Iur
• Iur, Iu, Relocation Signalling
KPI analysis hierarchy
How to Prioritize Analysis ?
WEEK 43
Number of Drop ratio
Site ID CI RNC Cell Name Ongoing actions WHO ? WHEN ?
drops (%)
610003 44451 21 London 26 33.77 WAM changed 26/10. MHA fault => Intervention Operations W44
611349 64743 21 Paris 25 62.50 WAM counters activated Lavoix W44
611105 64541 31 Helsinki 24 12.12 Decrease coverage (tilt 0°) Radiolainen W46
TOP 10 Number of 611150 64662 31 Berlin 22 13.84 Neighbour sites ? Analyse last field measurements Ramstein W45
370037 43109 21 Bern 20 3.33
drops RAB Voice+CS 200089 45091 11 Athens 19 10.80 Terminal testing ? Pistopoulos W46
Conv 940028 41796 31 Rome 18 22.50 Some Iur drop => Check inter-RNC neighbour definition, monitor Iur performance
610078 50686 31 Madrid 18 32.14 Updated neighbour list Sanchez W44
611346 64736 31 Brussels 17 1.27
610297 44220 31 Den Haag 17 7.46 Decrease coverage (tilt 2°) van den Hoop W46
List top 10-20 worst cells

• Too big lists of results will irritate
consultants.
• Main impacts must be visible and
manageable for hands – on tasks
• Different tables of different data
warehouse must be verifiable
• Data/KPI benchmark should be
easy

How to Prioritize Analysis ?
Because of the large number of cells in the network, it is

not feasible to analyse all the cells. Analyses has to
focus on manageable list of elements.
• Exception to this is the handling of customer VIP
complaints, where detailed analysis of specific cells
(otherwise irrelevant) is needed
Good methodology is to list top 10-20 worst cells per

region and to build and follow an action plan on those
• This required a part-time or dedicated tracking role
• Interaction with Operations is required to open
relevant HW/SW tickets and follow changes.

Prioritizing cell with the highest number of failures
Cells order by nb of drops
100%
90%
Quick fault diagnostics due to worst cells causes
80%
10 worst cells (1% of the area)

Cumulative percentage of drops
70%
cause 14% of the drops
60%
50% Cells order by nb of drops
40%
30%
20%
10%
0%
1 56 111 166 221 276 331 386 441 496 551 606 661 716 771 826 881 936 991 1046 1101
Nb of cells

Prioritizing cell with the highest number of failures
Either total number of failures or failure rate (%)

could be used
• Coverage hole, missing neighbour or capacity
problem
It may be required with some periodicity (e.g. one

month) to reach a more uniform performance, in
addition with the top number of failures
• Larger time periods are preferable, together with

a filter a minimum number of attempts/failures
per cell (depending on network traffic)

KPI analysis - hierarchies
The Key I got …
… for performance
Indicator I still
improve
Thank You !
Call/Session monitoring & analysis
R99: Call Drop

HSPA setup
HSPA mobility
RRC states
Appendix –
- failure events

Performance layers
issues

& analysis by tools
There are several tools for
detecting of NW faults. Related to
sessions, call setup, or RAB
establishments, signalling flows can Release 99: HSPA
indicate NW performance.
call setup call setup
call drop call drop
RRC states
Iub
WBTS

Call/Session monitoring with tools
Daily, Weekly or Busy Hour ? NetAct
MAX (CS_VOICE_CALL_DL + CS_DATA_CALL_CONV_DL +
CS_DATA_CALL_STREAM_DL + PS_DATA_CALL_CONV_DL +
PS_DATA_STREAM_DL + PS_DATA_CALL_INTERA_DL +
PS_DATA_CALL_BACKG_DL)
NetAct Busy Hour

definition: RT and NRT is summed every hour
Traffic sum: The hour with maximum value is taken for BH
RT/NRT
by NetAct
1h
1h
1h
BH
1h CDR
CSSR
0 12 h 24 h
Call/Session monitoring
Daily, Weekly or Busy Hour ?
Voice, R99NRT and HSDPA peak traffic can happen at different times
Blocking is not necessarily happening during the BH
NetAct Busy Hour definition is that the RT and NRT is summed every hour and
the hour with maximum value is taken for BH
• Where xxx_DL= SUMi ( Bit_Ratei * Allocation_Durationi). In Loaded
networks the Weekly Busy Hour CSSR is relevant
• The failures originate mostly from congestions (Iub, BTS HW (CEs), radio)
• The call blocking probability is designed for the BH
In Unloaded networks the Weekly Busy Hour CSSR may not yield the hour
with highest blocking as NRT traffic is taken in the account as well as RT traffic
In cell level it is needed to compute BH statistic based on absolute time period
(e.g. 16-18h every day). Daily data may not be accurate enough due to big
variations of results (due to ongoing operatios, system failures, sleeping cells,
alarms etc.)

19
16
/1
1
16 /20
0
1
2
3
4
5
6
/1 07
1 0
16 /20 0
/1 07
1 0

16 /20 1
/1 07
1 0
16 /20 2
/1 0
1 70
© NSN Siemens Networks

16 /20 3
/1 07
1 0
16 /20 4
/1 07
1 0
16 /20 5
/1 0
1 70
16 /20 6
/1 07
1 0
16 /20 7
/1 07
1 0
16 /20 8
/1 0
1 70
16 /20 9
/1 07
1 1
16 /20 0
/1 07
Presentation / Author / Date

1 1
16 /20 1
/1 0
Hourly traffic example, RNC level
1 71
16 /20 2
/1 07
1 1
16 /20 3
/1 07
1 1
16 /20 4
/1 0
1 71
16 /20 5
/1 07
1 1
16 /20 6
/1 07
1 1
16 /20 7
/1 0
1 71
16 /20 8
/1 07
1 1
16 /20 9
/1 07
1 2
16 /20 0
/1 07
1 2
16 /20 1
/1 07
1/
20 22
07
23
Voice, GB (AF50%)
R99_UL, GB (25 % AF)

R99_DL, GB (25 % AF)
GB = Giga Byte
HSDPA DL, GB (100% AF)
AF activity factor
Hourly traffic example, cell level
1.0
0.8
0.6
Load
Load
0.4
0.2
Cell 1 Cell 2
0
15 16 17 18 19 20 21 22 23 24
Cell 3 Cell 4
Alternative measure for traffic on DL

Load = TCP / maximum power
Call/Session monitoring & analysis with NetAct
NSN NetAct tools
NSN NetAct contains variety of tools which can be used for
Performance monitoring and data analysis:
NetAct Reporting tools – KPI/Report Browser, Reporting Suite
Traffica Tools – Real Time Traffic Monitoring and Troubleshooting
NetAct Monitoring - Subscriber and equipment trace
Reporting Tools

Reporting In NSN NetAct
Reporting Suites
-With enhanced Report Set
-2G BSS Reporting suite
Report Builder & Browser
-with default Report Sets
-Reports created with Report builder can be
accessed from web via the Report Browser
Network Doctor for BSS

- incl. Network Doctor Browser
NetAct
PM DB
NetAct reporting suite
Contains ready made reports for analysing network

performance. Most of the reports are based on collected PM
data and NSN-defined KPI’s. Some reports also include radio
network parameters and alarm information
User can also create own customized report with own KPI
definitions for Reporting Suite.
Ready made
reports

Export To
excel

Ready made report definitions as well as KPI/PI

formulas can be found from help menu

Traffica – Real-Time traffic monitoring and troubleshooting
Real-time traffic monitoring and troubleshooting tool for Multi-

vendor networks
Analysis of subscriber behaviour, roaming, mobile types, used
services. Receives and stores a record of each:
• Call & Call attempt
• sent or received SMS,
• PDP context event etc.
Updates counters and present the traffic in real-time graphs:

• Number of events
• Number of failures
• Clear Codes etc.
Traffica can be used monitoring, for example, congestion,
dropped calls, setup failures, RNCs/BSCs, RACs/LACs,
SACs/cells and CGRs. They can also verify the effect of
changes in the configuration in real-time.
RNC monitoring (clear codes) in RAS06 !!

Subscriber and Equipment Trace
• Trace viewer is tool to start/stop traces

• Monitor results by using graph or textual reports
• Trace data can be exported to CSV.

Subscriber and equipment trace
Subscriber and Equipment Trace Provide detailed

radio interface data from GSM, GPRS and 3G
networks. Call can be traced by using subscriber's
IMSI, MS-ISDN or equipment’s IMEI number
Subscriber trace can be used for:

• In system testing and provisioning phase for
trouble shooting and network optimisation. E.g.
Ascertain cell coverage, network integrity & QoS
Limited multi-vendor support

• Trace data is collected only from NSN elements
and viewed by TraceViewer

Why KPI’s do not smell like

these sausages?
… than I would detect
them more easily
Thank You !

R99: Call Drop

HSPA setup
HSPA mobility
RRC states
Appendix –
- failure events

Performance layers
issues

& analysis by tools
W-CDMA specific issues:
There are several phases to
allocate call performance/quality:
Starting at RRC connection setup, Release 99: HSPA
connection access and RRC active
& mobility states call setup call setup
call drop call drop
RRC states
Iub
WBTS

Call setup (RRC/RAB)
RRC Connection Set-up recourse allocation
Air Interface WBTS HW Resources Transport RNC
UL interference
DL transmisson power
DL Codes During call set-up [RRC, RAB] several
resource areas are checked and
physical/ logical resources allocated.
DSP processing
RLC/MAC
IuB
FSP/ WSP capacity (N*) E1 capacity / AAL2

call setup (RRC/RAB)
High level PM data analysis and assessment
System Program (PLMN)
Using Reporting Suite 3G RAN Reports or MS
Weekly KPI
Access KPI Queries
No No action
( PLMN)
needed
<X%
System Program (RNC)
Yes
Weekly KPI
No Mapinfo
(RNC) Matching failure
<X%? distribution into
network topology Solution Proposal
Yes
System Program (WCEL) Others 3G RAN Reports

Identify Top50 Worst
Cells based on
Daily KPI
highest number of root
(WCEL)
causes failures
< X%
System Program (WCEL) Others 3G RAN Reports

Yes Identify Call failure Identify failures root-
phases of bad causes and failure
performing KPIs, for distribution of bad KPIs
example CSSR

call setup failures
RRC and RAB phases RRC connection setup
RAN resources are reserved for
signaling connection between UE
and RNC
Phase: Setup Access Active RRC access
Connection between UE and RRC
RRC active
UE has RRC connection. If
Active
Active dropped, also active RAB is
Success
Setup Access Complete dropped.
Setup Access Complete
Complete Complete RAB setup
Complete Complete Attempts to start the call
Access
Active
Active
RAB setup access
Release
Release
RAB active phase
RRC UE has RAB connection
Attempts
Active
Active Drop
Failures
Failures CSSR affected if any of the followings
take
place.
Access failures
• RRC Conn. Setup Fail
• RRC Conn. Access Fail
Setup failures • RAB Setup Fail
(blocking) • RAB Setup Access Fail

PM Data analysis process
1. Assess weekly average PLMN KPI performance to identify KPIs below targets
• Start from bigger picture assessment (PLNM -> RNC -> Cluster -> WCEL )
• Weekly average will smooth the performance and gives better accuracy of performance
assessment as daily performance varies a lot especially in unloaded network
2. Assess network performance at RNC/Area level to check if bad performance
happens across network or only particular RNC/Area
• Compare different RNC/Regions performance
3. Apply drill down approach to assess bad performing KPIs in WCEL level
• Identify the failure call phases
• Categorizing failure ratio or distribution of each counters (radio, AC, transmission, BTS,
RNC)
• Identify main cause of underperforming KPIs
4. Prioritize analysis
• Filter using high number of failures or high number failure ratio (weighting)
• Identify top 50 worst cells
5. Matching failure distribution in the network topology (rural, RNC border,
expressway)
6. Solution proposal of network KPIs below KPI targets
RRC Connection set-up: Signaling & trigger
UE Node B RNC M1001C0
Three phase for RRC
Counter
[RACH] RRC:RRC Connection Request
AC to check to accept
or reject RRC
Connection Request
RRC Connection Setup NBAP: RL Setup Request
Allocation of UTRAN
phase Start TX/RX
NBAP: RL Setup Response

resources
ALCAP:ERQ
ALCAP:ECF
M1001C0
[FACH] RRC: RRC Connection Setup 1. KPI
M1001C1 M1001C1
Start TX/RX
RRC Connection Access
L1 Synchronisation
phase
New NBAP: Synchronisation Indication Waiting for UE reply
improvement
within RU20
[DCH] RRC: RRC Connection
M1001C8
Setup Complete
RRC Connection Active phase
RRC active complete drop Pre-Emption SRNS Relocation
call setup (RRC/RAB) new within RU20
Fast L1 Synchronisation
Quicker access due to post verification of QoS
UE starts transmitting
If CPHY-Sync-IND primitive quality is without
The total delay before UE starts UL
sufficiently good, UE starts 70 ms quicker transmission is reduced by 70 ms. Post Verification
40 ms window
[DCH] RRC Setup Complete
40 ms window
RRC Connection Access phase
40 ms window
50 ms window
Node B starts transmitting 40 ms window
[FACH]: RRC Connection Setup UE starts transmitting UE stops transmitting if

with Post Verification verification check fails
10 ms radio
frames
40 ms window
UE starts receiving,
mobile is listing on FACH Post verification
UE L1 collects 40 ms
check
of quality
measurements

call setup failures
RRC and RAB phases
RRC/RAB Setup & Access Analysis Process Flow Chart
Top (N) RRC Setup Top (N) RAB Setup/Access
and Access failures or PS Setup failures
Setup
Failure
Cause? setup Setup
Sites OK ? /Access
RNC
Cell and Neighbour Troubleshooting
Cells availability Yes BTS/TRANS/FROZBS
Alarms/Tickets AC UL/DL
setup Access
Setup Interference
/Access (DL codes)
Capacity
Optimisation
Access
Yes
3G cell at
SRNS Relocation
inter-RNC
troubleshooting
border ?
NO
Interference
Coverage/Inte
RF Optimisation
rference
Coverage
RRC Connection & Access Fail - Analysis
Admission Control and RRC Setup Failure Distribution Example - RAS51
BTS are the dominant 2% 2%0%

10%
%
failure reasons here HC

BTS AC
BTS
TRANS
50%
RNC
45%
FROBTS
RNTI Allo
IUB AAL2 TRANS
Example
RAS 5.1
KPI ID example RNC_94c

RRC Access Fail - Analysis
Radio Interface Synchronisation is

dominant failure reason here
Example
RAS51
Setup and Access Complete ratio is ~99.5 %

RRC Access Fail - Analysis
RRC Access Failure reasons
L1 Synchronisation
RRC: RRC Connection Setup Complete (DCH) X

NBAP: Synchronisation Indication
UE BTS
X RNC
RRC Access Failures for L1 synchronization
RRC Access Failures due to MS (QoS)
Cell reselections L1 Synchronisation
(no error) NBAP: Synchronisation Indication
RRC: RRC Connection Setup Complete (DCH)
UE BTS
X RNC

call setup – RAB for NRT
RAB setup failures
RAB setup fails if some of the needed resources (RNC, BTS, Radio, transport) are not available.
• BUT RNC does not reserve radio interface resources in RAB setup phase for NRT
AC TRANS
Example
RAS51
RAB Setup Complete success ratio is close to ~100 %

Counters for RAB and DCH Setups and Failure Cases
• RAB setup fails for CS Voice due to M1001C625
M1001C621
ServiceLevel
ServiceLevel
RAB_STP_FAIL_CS_VOICE_IU_CS
RAB_STP_FAIL_CS_VOICE_IUR_TR
Iu-cs/Iur or transport failures M1001C619 ServiceLevel RAB_STP_FAIL_CS_VOICE_LIC
• fails/rel due to AMR capacity license

exceeded (for new RNC2600)
M 10 01 C62 0 S erviceL evel RA B _A CT_RE L _CS _V O ICE _ PRE _ LIC
• RAB setup fails for UDI & CS M 10 01 C62 2 S erviceL evel RA B _S TP_ FAI L_ CS_ CO NV _I UR_TR
streaming due to Iu-cs/Iur or transport M 10 01 C62 3 S erviceL evel RA B _S TP_ FAI L_ CS_ S TRE _ IUR_TR
failures M 10 01 C62 6
M 10 01 C62 7
S erviceL evel
S erviceL evel
RA B _S TP_ FAI L_ CS_ CO NV _I U_CS
RA B _S TP_ FAI L_ CS_ S TRE _ IU_CS
• RAB setup fails for PS streaming due M 10 01 C62 4 S erviceL evel RA B _S TP_ FAI L_ PS _ STRE _IUR _TR
to Iur transport
• RRC active release after successful

Directed Retry DR (RAN 928)
M 10 01 C64 0 S erviceL evel RR C_A CT_RE L_ DIRE CTED_ RE TRY

RAN 1126: Counters for RAB and DCH Setups and
Failure Cases M 10 22 C83
M 10 22 C84
P acket_call
P acket_call
INIT_D CH_RE Q _ 64 _UL
INIT_D CH_RE Q _ 64 _DL
M 10 22 C85 P acket_call INIT_D CH_RE Q _ 12 8_ UL
M 10 22 C86 P acket_call INIT_D CH_RE Q _ 12 8_ DL
• New counters to Initial DCH request M 10 22 C87

M 10 22 C88
P acket_call
P acket_call
INIT_D CH_RE Q _ 25 6_ UL
INIT_D CH_RE Q _ 25 6_ DL
(from RAB(0/0) or cell_fach/PCH to M 10 22 C89

M 10 22 C90
P acket_call
P acket_call
INIT_D CH_RE Q _ 38 4_ UL
INIT_D CH_RE Q _ 38 4_ DL
cell_DCH) and success counters M 10 22 C99 P acket_call S UCC_I NIT_ A LL O _6 4_ UL
• DCH user plane upgrade request & M 10 22 C10 0

M 10 22 C10 1
P acket_call
P acket_call
S UCC_I NIT_ A LL O _6 4_ DL
S UCC_I NIT_ A LL O _1 28 _UL
success counters (to the target bitrate) M 10 22 C10 2

M 10 22 C10 3
P acket_call
P acket_call
S UCC_I NIT_ A LL O _1 28 _DL
S UCC_I NIT_ A LL O _2 56 _UL
M 10 22 C10 4 P acket_call S UCC_I NIT_ A LL O _2 56 _DL
M 10 22 C10 5 P acket_call S UCC_I NIT_ A LL O _3 84 _UL
M 10 22 C10 6 P acket_call S UCC_I NIT_ A LL O _3 84 _DL
M 10 22 C91 P acket_call DCH_ UPG R _RE Q _6 4_ UL

M 10 22 C92 P acket_call DCH_ UPG R _RE Q _6 4_ DL
M 10 22 C93 P acket_call DCH_ UPG R _RE Q _1 28 _UL
M 10 22 C94 P acket_call DCH_ UPG R _RE Q _1 28 _DL
M 10 22 C11 5 P acket_call S UCC_UP G _ NRT_ DCH_ 64 _UL

M 10 22 C11 6 P acket_call S UCC_UP G _ NRT_ DCH_ 64 _DL
M 10 22 C11 7 P acket_call S UCC_UP G _ NRT_ DCH_ 12 8_ UL
M 10 22 C11 8 P acket_call S UCC_UP G _ NRT_ DCH_ 12 8_ DL

Not every successful setup is

that important
Thank You ! … but easier

R99: Call Drop

HSPA setup
HSPA mobility
RRC states
Appendix –
- failure events

Call Drop analysis
Top (N) drops
Neighbours’ Performance Traffic
(use SHO success per adjs
counters to identify badly
Cell and its Neighbour performing neighbours) & Map
Cells availability Site OK ?
Alarms/Tickets Audit adjacent sites for alarms,
Availability, configuration and
YES capacity
NO
Configuration &
Parameter audit Conf OK ?
3G Cell at RNC YES Iur
border? performance Investigation Iur
YES
SHO SHO Success YES

Rate < 90%?
NO New site ?
ISHO ISHO NO Analyse last detailed RF and IFHO neighbour

Failures radio measurements optimisation
YES
3G cell covers
3G cell at inter-
over a coverage
RNC border ?
Top issues hole ?
No cell found YES RF and ISHO neighbour

ratio >40 % optimisation
2G Cell Doctor
NO
No cell found
2G Investigation : ratio > 90 % Wrong reference clock
TCH blocking or YES ISHO Success and enough (10MHz tuning)
TCH seizure failure Rate < 90% ADJG
(interference)

Radio Link Failure
Iub Counter table measurements can be used to detect Radio Link Deletion rate
due the active L1 synchronisation failure
The KPI measures the percentage of radio link deletions to the total number of
radio links that were successfully established i.e. initial, soft and softer handover.
Use raw counters for following KPI to detect cells with high synchronisation failures
Compare Cell Level KPI to RNC Level KPI
NUMBER OF RADIO LINK

DEL _ SHO _ SRNC _ ACT _ RL _ SYN _ FAIL DELETION FOR ACTIVE
UL _ LOST _ ACT = SYN FAILURE
RL _ BRANCH _ ADD _ SUCC _ SHO _ SRNC +
RL _ SETUP _ SUCC _ FOR _ FIRST _ RL + NUMBER OF ACTIVE RADIO
LINKS IN THE IUB
RL _ SETUP _ SUCC _ FOR _ SHO _ RL
Downlink radio link failure results in

an UL synchronization loss since
the UE stops transmitting.

RAS06 new SHO counters
It is possible to see the ASU performance counters:
• M1006C121 ACTIVE SET UPDATE RL ADD ATTEMPTS
• M1006C122 ACTIVE SET UPDATE RL ADD SUCCESS
• M1006C123 ACTIVE SET UPDATE RL ADD FAILURE UE
• M1006C124 ACTIVE SET UPDATE RL ADD FAIL NO REPLY
• M1006C125 ACTIVE SET UPDATE RL DEL ATTEMPTS
• M1006C126 AS_UPDATE_RL_DEL_SUCC

R99: Call Drop
Hu”auwei” E 870
Thank You !
CDR can have several
reasons …
but sometimes only
specific handsets gives
response at Iub

R99: Call Drop

HSPA setup
HSPA mobility
RRC states
Appendix –
- failure events

R99: Mobility - SHO Overhead
Check SHO Overhead to see how big is SHO area, if it is too small SHO may
fail and if too big capacity is wasted (see calculations)
100 * ( sum((ONE _ CELL _ IN _ ACT _ SET _ FOR _ RT + ONE _ CELL _ IN _ ACT _ SET _ FOR _ NRT )
+ (TWO _ CELLS _ IN _ ACT _ SET _ FOR _ RT + TWO _ CELL _ IN _ ACT _ SET _ FOR _ NRT )
+ (THREE _ CELLS _ IN _ ACT _ SET _ FOR _ RT + THREE _ CELL _ IN _ ACT _ SET _ FOR _ NRT ))
SHO _ Overhead =
sum((ONE _ CELL _ IN _ ACT _ SET _ FOR _ RT + ONE _ CELL _ IN _ ACT _ SET _ FOR _ NRT )
+ (TWO _ CELLS _ IN _ ACT _ SET _ FOR _ RT + TWO _ CELL _ IN _ ACT _ SET _ FOR _ NRT ) / 2
+ (THREE _ CELLS _ IN _ ACT _ SET _ FOR _ RT + THREE _ CELL _ IN _ ACT _ SET _ FOR _ NRT ) / 3 − 1)
• SHO success (RNC_195a)

100 * sum( SUCC _ UPDATES _ ON _ SHO _ FOR _ RT + SUCC _ UPDATES _ ON _ SHO _ FOR _ NRT )
SHO _ Success _ ratio =
sum(CELL _ ADD _ REQ _ ON _ SHO _ FOR _ RT + CELL _ REPL _ REQ _ ON _ SHO _ FOR _ RT
+ CELL _ DEL _ REQ _ ON _ SHO _ FOR _ RT + CELL _ ADD _ REQ _ ON _ SHO _ FOR _ NRT
+ CELL _ REPL _ REQ _ ON _ SHO _ FOR _ NRT + CELL _ DEL _ REQ _ ON _ SHO _ FOR _ NRT )
SHO success and SHO OH can be calculated separately

for RT & NRT these examples contains both

R99: Mobility - SHO Overhead on RNC level (1/4)
# radio links
E1A CPICH E1B CPICH
# users
Offset 4dB Offset 6dB
SHO
area
cell
cell11
Factors are
ONE _ CELL _ IN _ ACT _ SET _ FOR _ RT / NRT + RL (1, 2 ,3 ) cell
cell22
TWO _ CELL _ IN _ ACT _ SET _ RT / NRT × 2 + of users
THREE _ CELL _ IN _ ACT _ SET _ RT / NRT × 3
ONE _ CELL _ IN _ ACT _ SET _ RT / NRT + # of users
TWO _ CELL _ IN _ ACT _ SET _ RT / NRT +
Users THREE _ CELL _ IN _ ACT _ SET _ RT / NRT
who stays
within
different
AS size
53 © Nokia Siemens Networks RANKPI /BAs / 05.05.2009
Reminder:
Low # of UE's
UE's within AS 1(1 cell) UE's within AS 2 (2 cells) UE's within AS 3 (3 cells) within AS 3 (5-8%)
1 link per UE 2 links per UE 3 links per UE
Total # of links
# of UE within AS 1 # of UE within AS 2 # of UE within AS 3
1 AS 1 + 2 AS 2 + 3 AS 3
# UE AS 1 + # UE AS 2 + # UE AS 3
# of UE linked
within AS 1+2+3
ONE _ CELL _ IN _ ACT _ SET _ FOR _ RT / NRT + Total # of

TWO _ CELL _ IN _ ACT _ SET _ RT / NRT × 2 + links within
cluster SHO overhead
THREE _ CELL _ IN _ ACT _ SET _ RT / NRT × 3
ONE _ CELL _ IN _ ACT _ SET _ RT / NRT +
= within cluster
Total #
TWO _ CELL _ IN _ ACT _ SET _ RT / NRT + UE's within
cluster
THREE _ CELL _ IN _ ACT _ SET _ RT / NRT

Simple example
1 link, 2 links, AS2

AS1
ONE _ CELL _ IN _ ACT _ SET _ FOR _ RT / NRT +

cell
cell11
TWO _ CELL _ IN _ ACT _ SET _ RT / NRT × 2 +
THREE _ CELL _ IN _ ACT _ SET _ RT / NRT × 3 1.5 SHO
cell
cell22
TWO _ CELL _ IN _ ACT _ SET _ RT / NRT +
1 UE within AS 1 1 UE within AS 2 Total: 3

links
within
1 AS 1 + 2 AS 2 cluster
=
2 UE's
1 cell in 2 cells in
Active Set Active Set AS 1 + AS 2
within
cluster
1 1 (1UE within AS1) (1UE within AS2)
Cell 1
Cell 2 0 1
Simple example
Attempt to apply formula on cell level
1 link, 2 links, AS2

AS1
1 UE within AS 1 1 UE within AS 2
cell
cell11
1 AS 1 + 2 AS 2
= 1.5 for cell 1 cell
cell22
AS 1 + AS 2
(1UE within AS1) (1UE within AS2) Average 1.75
0 UE within AS 1 1 UE within AS 2
deviates strongly from
result 1.5 on RNC level
2 AS 2
= 2.0 for cell 2
AS 2
(0UE within AS1) (1UE within AS2)
R99: Mobility - SHO Overhead on cell level (1/4)
Fair calculation of Average AS size at (RNC 192b) cell specific

Total #
THREE _ CELL _ IN _ ACT _ SET _ RT / NRT cells # Users
=
ONE _ CELL _ IN _ ACT _ SET _ RT / NRT + Total # cell
TWO _ CELL _ IN _ ACT _ SET _ RT / NRT / 2 + effective # of
cells
THREE _ CELL _ IN _ ACT _ SET _ RT / NRT / 3
cell
cell11
cell
cell22
57 © Nokia Siemens Networks RANKPI /BAs / 05.05.2009

Calculation of UE link performance at cell level
Total # UEs
within cells
(# of UE; AS1) (# of UE; AS2) (# of UE; AS3)
AS 3
# UE AS 1 + # UE AS 2 + # UE
1 UE 1 UE AS 3
1 cell + 2 cells + 3 cells Total effective

# of cells
Averaged cell
AS 1 AS 2 area/user
With # of UE's With # of UE's With # of UE's
100% sharing of cell 50% sharing of cell 33% sharing of cell

Total #
THREE _ CELL _ IN _ ACT _ SET _ RT / NRT cells SHO
ONE _ CELL _ IN _ ACT _ SET _ RT / NRT + = overhead
per cell
Total # of
TWO _ CELL _ IN _ ACT _ SET _ RT / NRT / 2 + cells
Simple example

TWO _ CELL _ IN _ ACT _ SET _ RT / NRT + cell
user B
cellAA user A
TWO _ CELL _ IN _ ACT _ SET _ RT / NRT / 2 +
cell
cellBB
(1UE; AS1) (1UE; AS2) Total # UE

1 in Active 2 in Active within cells
Set Set
AS 1 + AS 2 2
1 1
Cell A =
Cell B 0 1 100% of 1 UE 50% of cell 1 UE
Sum 1 2
cell area A
is related + area B is
related to
1.5
(Cell) to User A 1 cell 2 cells Total effective
User B
# of cells
AS 1 AS 2

Simple example
(1UE; AS1) (1UE; AS2)
AS 1 + AS 2
= 1.33 for cell 1
100% of 1 UE 50% of cell 1 UE
cell area A
is related + area B is
related to
to User A 1 cell 2 cells
User B
Average 1.67
AS 1 AS 2
Agrees better with result 1.5
on RNC level
(0 UE; AS1) (1UE; AS2)
AS 2
= 2.00 for cell 2
50% of cell 1 UE
area B is
related to 2 cells
User B
AS 2
R99: Mobility - SHO Success per Adjacency
The HO success rate per adjacency can be used to detect badly performing neighbours
• can be calculated by using formulas below
SHO Success per Adjacency (M1013 AutoDef SHO)
100 * sum(SHO _ ADJ _ INTRA _ FREQ _ SHO _ COMPL)
SHO _ success _ per _ ADJS _ RNC _ 900a =
sum(SHO _ ADJ _ INTRA _ FREQ _ SHO _ ATT)
IFHO Success per Adjacency (M1014 AutoDef IFHO)

100 * sum(HHO _ ADJ _ INTER _ FREQ _ HHO _ COMP)
IFHO _ success _ per _ ADJI _ RNC _ 901a =
sum(HHO _ ADJ _ INTER _ FREQ _ HHO _ ATT)
ISHO Success per Adjacency (M1015 AutoDef ISHO)
100 * sum(HO _ ADJ _ INTER _ SYS _ HHO _ COMPL)

ISHO _ success _ per _ ADJG _ RNC _ 902a =
sum(HO _ ADJ _ INTER _ SYS _ HHO _ ATT)

R99: Mobility - ISHO analysis Flow Chart
ISHO Success Rate RT

RNC_300c < No
No action
X% needed
Top N cells Yes
Low ISHO
CM Start Not No No
Measuremen No Low ISHO
Possible? t Success ?
success ?
Yes
Yes
Yes
Missing ADJG or Missing or wrong Half Rate in 2G
Check admission Bad Neighbour 2G parameters in Ncell ?
control rejection -> planning ? 2G MSC or SGSN
PrxTotal & PtxTotal (BCCH, LAC,
Poor GSM
CellID)
Coverage
Wrong 2G Ncell
Parameter (BSIC) Missing neighbour
Or BSIC collision 2G Ncell list after re-
Congestion selection after cell
change order
Too low ISHO occured
triggering threshold or
Non-optimum
Strict ADJG minimum
Compressed mode threshold
parameter set (ADJGRxLevMinHO)

R99: Mobility ISHO analysis
1. Analysis should be performed for each service (i.e. AMR, PS etc.)
2. Breakdown ISHO analysis into three phases:
Compressed mode performance
Inter-system measurement success
Inter-system handover success
70
60
50
IS_ C O M _ M O D _ S T A _ NO T _ P
40 O S_RT
samples
30 UE _ P W R _ R T
20
ISHO compressed mode not possible
10
0
20040908
20040909
20040910
20040911
20040912
20040913
20040906
20040907

R99: Mobility ISHO analysis
3. If high ISHO compressed mode start not possible
Check busy hour data of PrxTotal , PtxTotal and M1000C22 AVE_PTXTOT_CLASS_4 and
M1000C20 AVE_PTXTOT_CLASS_3 for AC rejection

You see not only mobiles can stay in SHO
Thank You !
… just married and static HO

R99: Call Drop

HSPA setup
HSPA mobility
RRC states
Appendix –
- failure events

Performance layers
issues

& analysis by tools
HSPA specific issues:
There are several phases to
allocate call performance/quality:
Starting at RRC connection setup, Release 99: HSPA
connection access and RRC active
& mobility states call setup call setup
call drop call drop
RRC states
Iub
WBTS

HSDPA Accessibility failure analysis
HSDPA Accessibility User Point of View Ratio
No No action
RNC_605b< X %
needed
Top X cells Yes

No No No No No Setup Fail Too
Setup Fail UL Setup Fail Iub Setup Fail RNC
Setup Fail BTS Setup Fail UE internal Many Users
return Channel Transport
Yes Yes Yes Yes

Yes Yes
Check CE Check AAL2 Iub Check RB Check RNC Unit Check number of
resource usage UL power resource reconfiguration load (DMPG) and simultaneous
at BH congestion congestion at BH Failure rate faulty alarms HSDPA users
BH ?
No

HSDPA Accessibility analysis
1. Identify root cause of failure distribution and main failure contributor
2. If high HSDPA Access Failure _too many HSDPA users

• Check simultaneous HSDPA users (RNC_646a to RNC_654a)
• DCH selected due to too many HSDPA users, rnc_660a
3. If high HSDPA Access Failure_UL DCH (RNC_662a)
• Rejected HS-DSCH return channel due to lack of radio (lack of power resource)
• Monitor UL load
• Increase PrxTarget
4. If high HSDPA Access Failure_UE
• Check RB reconfiguration failure rate
• ICSU log for UE types troubleshooting ?

5. If high HSDPA Access Failure_BTS
Lack of UL channel resources (check CE resource utilisation using M5001 counters at BH)
Too high SHO overhead – all branches must have enough CE capacity if UE is in SHO when HS-DSCH
allocation is started
Failures (BH)
1200 30 (%)
1000 25
800 20
SETUP_FAIL_BTS_HS_DSCH_BGR (Traffic)
600 15
AVE_AVAIL_PERC_POOL_CAPA_UL (Cellres)
400 10
200 5
0 0
1 14 27 40 53 66 79 92 105 118 131 144 157 170 183 196 209 222 235 248 261 274 287 # cells

6. HS-DSCH return channel setup fail due to Iub transport

Breakdown the failure distribution (64,128,384,MAC-d)
Evaluate number of reconfiguration failure due the transmission
Check M1005C128 CANC_ADD_SRNC_TRAN_STP_FAIL
Check RAB_STP_FAIL_XXX_IUB_AAL2, M1001C531-C533
HSUPA Accessibility Analysis
• In case of congestion with Iub or RNC:
– RNC sends HSUPA Congestion Control indications to the BTS based on detected
received Iub FP frame delay build up or RNC HW overload. Following counters count
those messages:
– M1022C69 IUB_DELAY_CC_DELAY_IND
– M1022C70 HW_OVERL_CC_DELAY_IND
• RNC sends HSUPA Congestion Control indications to the BTS based on detected
received Iub FP frame frame loss due to Iub delay, traffic loss or RNC HW overload.
• Following counters count those messages:

– M1022C71 IUB_LOSS_CC_FRAME_LOSS_IND
– M1022C72 IUB_DELAY_CC_FRAME_LOSS_IND
– M1022C73 HW_OVERL_CC_FRAME_LOSS_IND

HSPA setup
Thank You !
Please consider
Release 99 users will partly suffer
due to HSPA speed and capability

R99: Call Drop

HSPA setup
HSPA mobility
RRC states
Appendix –
- failure events

Active Set Update and Serving Cell Change (A-DCH)
Active set update and serving cell change with associated DCH
EC/I0 HSDPAServCellWindow
RNC; 0..6; 0.5; 2 dB CPICH 1 R99
Drop
CPICH 2 R5/6
window
Addition 6dB
window
4dB
periodic reports as
Addition Time long UE in SHO area
SHO for A- Periodic Serving cell change
time
DCH initiated reports initiated CPICH 2 active
R 99 R 5/6 One RL only
75 © Nokia Siemens Networks RN30095EN20GLA0

Inter-BTS serving cell change
1. Serving cell change started due to ASU update

2. Serving cell change started due to CPICH Ec/No
3. Serving cell change started due to UL SIR Error
4. Serving cell change started due to other reason
(e.g. RL Failure, event 6F)
5. Serving cell change prevented due to timer
6. Serving cell change failure due to AC
7. Serving cell change failure due to BTS
8. Serving cell change failure due to transport
9. Serving cell change failure due to UE
10. Number of successful inter-BTS serving cell
changes

Intra-BTS serving cell change
1. Serving cell change started due to active set update

2. Serving cell change started due to CPICH Ec/No
3. Serving cell change started due to UL SIR Error
4. Serving cell change started due to other reason (e.g. RL
Failure, event 6F)
5. Serving cell change prevented due to timer
6. Serving cell change failure due to AC
7. Serving cell change failure due to BTS
8. Serving cell change failure due to transport
9. Serving cell change failure due to UE
10. Number of successful intra-BTS serving cell changes
Attempt and failure counters are updated to the current
serving cell. Successful counters are updated to the new
serving cell

HSDPA SCC Analysis
HSDPA SCC Success Rate
No
RNC_733a < X % No action
needed
Top N cells
Yes
No No No No No
SCC Fail SCC Fail
SCC Fail Prevention
SCC Fail BTS SCC Fail AC SCC Fail UE Others
Transmission timer
Yes Yes Yes Yes Yes

Yes
Check CE Check AAL2 Iub Check RB Check RNC Check

resource usage DL power resource reconfiguration internal transport HSDPACellChangeMinI
at BH congestion congestion at Failure rate resources nterval parameter
BH ? BH (DMPG) – ICSU
troubleshooting
No
OVSF code Check Maximum

congestion BH No number of
HSDPA users

HSDPA SCC analysis
1. Determine SCC success rate, SCC failure rate and failure cause distribution
2. Check target cells HSDPA Setup performance (M1002C401 – M1002C428) if source
cells SCC failure rate is high
• To find out which target cells are causing the SCC failure
3. If high SCC_FAILED_due_to_AC
• Check target cells M1000C22 AVE_PTXTOT_CLASS_4 and M1000C20 AVE_PTXTOT_CLASS_3 if SCC
failures due to the lack of DL power (SCC_Failed_due_to_AC) – this is not visible in HSDPA accessibility
KPI- Check target cells number of simultaneous active HSDPA users
HSPA started

HSDPA SCC Analysis
4. If high SCC_FAILED_due_to_BTS
• Check target cells M1002C416/424 SETUP_FAIL_BTS_HS_DSCH_XXX
• Check target cells CE resource utilisation at BH using M5001 counters for lack of UL return channel
resource
• Check NBAP Radio Link Reconfiguration Failure rate
• Check SHO overhead – all branches must have enough CE capacity if UE is in SHO when HS-DSCH
allocation is started
5. If high SCC_FAILED_due_to_UE
• Check target cells M1002C415/423 SETUP_FAIL_UE_HS_DSCH_XXX
• Check RB reconfiguration Failure rate
• Require ICSU troubleshooting for UE types monitoring
6. If high SCC_FAILED_due_to_TRANS
• Check target cells of M1002C414 SETUP_FAIL_IUB_MAC_D_INT or M1002C422
SETUP_FAIL_IUB_MAC_D_BGR
• Evaluate number of reconfiguration failure due the transmission
• Check M1005C128 CANC_ADD_SRNC_TRAN_STP_FAIL
• Check M1001C531-C533 RAB_STP_FAIL_XXX_IUB_AAL2
7. If high SCC_FAILED_due_to_Others
• Check RNC internal transport resources usage (DMPG)
• Require ICSU troubleshooting

HSDPA SCC upgrade within RU20
Fractional DPCH Deactivation of R99
- F-DPCH replaces the downlink DPCCH
Rel. 6: Fractional DPCH: F-DPCH - SRB on HSPA capabilities
F-PDCH HHSS- -SC

DPDCH SCCCH
H
HS - DSCH HHSS--DS
DSCCH
Node H
FF-D
-DP
PCCHH
B
RNC
Iub HHSS-D
-DPC
PCCCH
H
HHSSUUPA
PA ccha
F-DPCH:
F-DPCH: hannnnel
elss
Fractional
FractionalDedicated
DedicatedPhysical
PhysicalChannel
Channel
Rel.
Rel.66DL
DLchannel
channel
inincase
case of pureHSDPA
of pure HSDPA&&HSUPA
HSUPA
data
data transmission (withouta-DCH)
transmission (without a-DCH) 1 Slot = 2/3 ms = 2560 chip
carries
carriesonly
onlyL1
L1TPCs
TPCs
TPCs
TPCsforforup
upto
to1010users
users F-DPCH slot
users TX OFF TPC TX OFF
usersTPCs
TPCsare
aretime-multiplexed
time-multiplexed
256⇒
SF DPCH slot
SF==256 ⇒1515ksymb/s
ksymb/s
1user:
1user: 1 TPC(=(=22bit)
1 TPC bit)information/slot
information/slot Data block 1 TFCI
TPC optional Data block 2 Pilot
SRBs on HS-DSCH if no a-DCH
SRBs on HS-DSCH if no a-DCH

Allocating F-DPCH & HSPA SRB (I) RU20
All cells activated
• F-DPCH shall be allocated whenever possible, i.e. not only if 'CPC' or 'CS voice over
HSPA' requires it
• The RNC shall allocate the F-DPCH if:
• UE supports Release 7 F-DPCH
• Release 7 F-DPCH is enabled in all cells of the current DCH active set
• E-DCH active set is equal to DCH active set
• F-DPCH is allowed for the used service as defined by the
FDPCHAndSRBOnHSPATC parameter
• Any services which requires DCH do not exist (AMR on DCH)
• HS-DSCH is allocated or is possible to allocate for the UE
• E-DCH is allocated or is possible to allocate for the UE
• SRB can be mapped to HS-DSCH
• SRB can be mapped to E-DCH
• Free F-DPCH slot format is available

Allocating F-DPCH & HSPA SRB (II) RU20
• SRB can only be allocated HSUPA with 10 ms TTI if HSDPA is allocated in the downlink
• If HSDPA is not allocated in the downlink, SRB can be allocated HSUPA with 2 ms TTI,
i.e. HSUPA/DCH configuration is possible
• SRB can only be allocated HSDPA if F-DPCH can be allocated
• If the UE is in soft handover, the CPICH Ec/Io of the HSDPA serving cell must be
relatively strong compared to the active set cell with the highest CPICH Ec/Io
• The CPICH Ec/Io of the HSDPA serving cell must be at least equal to CPICH Ec/Io
of the active set cell with the highest CPICH Ec/Io - HSDPASRBWindow
Name Range Default Description

HSDPASRBWindow 0 to 6 dB, step 1 dB The parameter determines the maximum allowed difference
0.5 dB between the best cell and the SRB on HS-DSCH cell. The
(RNC) window is relative to the best cell in the active set. If the SRB
on HS-DSCH cell change is outside the window, SRBs on HS-
Window for best active cell - HSDPA DSCH cell change procedure is initiated. If the SRBs on HS-
serving cell. If adjacent cell is (1dB) DSCH cell change fails, it triggers SRBs on HS-DSCH
transport channel type switch to DCH. DCH The measured
stronger, than no F-DPCH allocated
quantity is CPICH Ec/No, which is received periodically from
the UE.

Allocating F-DPCH & HSPA SRB (III) RU20
• There must be at least one cell in the active set with a CPICH RSCP greater than the
threshold defined by CPICHRSCPThreSRBHSDPA
• If HSPDA is already allocated then the serving cell must have a CPICH RSCP which is
greater than the threshold defined by CPICHRSCPThreSRBHSDPA

CPICHRSCPThreSRBHSDPA -115 to -25, -103 This parameter defines the coverage area of the
step 1 dBm dBm SRBs on HS-DSCH within the HSPA serving cell.
(RNC)
Min. coverage
required for F-DPCH
Default Ec/Io is -6dB

required for F-DPCH

Allocating F-DPCH & HSPA SRB (IV) RU20
• The RNC continuously monitors the rules for F-DPCH allocation
• Channel type switching from F-DPCH to DPCH is triggered if any of them are not
satisfied while a F-DPCH is allocated
• Likewise, channel type switching from DPCH to F-DPCH is triggered if they are all
satisfied while a DPCH is allocated
• The minimum interval between two consecutive F-DPCH allocations for a specific UE is
defined by the FDPCHAllocMinInterval parameter
• A timer is started for this minimum interval after F-DPCH to DPCH switching
• The timer is stopped if a RAB establishment procedure is initiated, i.e. F-DPCH
allocation is not restricted during RAB establishment

FDPCHAllocMinInterval 0 to 10 s, 3 sec The parameter determines the minimum interval
step 1 s between two consecutive Fractional DPCH (F-DPCH)
(RNC) allocations of the certain UE. Timer is started after every
interval between two successfully executed F-DPCH to DPCH
reconfiguration. During the time period, F-DPCH
consecutive F-DPCH allocation is forbidden. If the value of the parameter is
allocations of UE, time set to 0, consecutive F-DPCH allocations are not
hysteresis F-DPCH off / on - restricted. Timer should be stopped when new RAB is
UE reports interval set up, i.e. F-DPCH allocation is not restricted in RAB
setup phase.
Mobility RU20
• Combined ASU and Serving Cell Change is supported to avoid L3 signaling and /
or SRB - detection errors in downlink
other (non AS cell) HSPA cell gets stronger
HSPA serving cell
Window for F-DPCH allocation

has same value as SCC window ASU & SCC in one procedure
Therefore we consider smaller
SCC window (1dB instead of 2dB
for HSDPA than with A-DCH)
EcN0 criteria: CPICH_ECNOADD >= CPICH_ECNObest_cell - HSDPASRBWindow

Active Set Update and SCC (F-DPCH) RU20
Active set update and serving cell change with fractional DPCH
EC/I0 HSDPASRBWindow
RNC; 0..6; 0.5; 1 dB CPICH 1
CPICH 2
Addition
window
periodic reports as
Addition Time long UE in SHO area
Just periodic Serving cell change AND time
reports active set update initiated
CPICH 2 not
active yet

HSPA mobility
High Ec/No
or CQI
HSPA
Thank You !
low Ec/No or CQI

Serving Cell
change – no
HSPA
R99: Call Drop

HSPA setup
HSPA mobility
RRC states
Appendix –
- failure events

Performance layers
issues

RRM specific issues: & analysis by tools
To manage maximum capacity we
consider advanced connection states.
Therefore counters indicates UE Release 99: HSPA
performance at different states e.g.
FACH, Cell_DCH, Cell_PCH, URA. call setup call setup
call drop call drop
RRC states
Iub
WBTS

Performance state upgrade within RU20
Common Channel Setup
UE setup via CELL FACH implemented within RU20
NW access of UE via Cell FACH
RACH and FACH transport channels are used for call setup
Call setup on CCH is faster than DCH
All time consuming procedures moves to Cell DCH
Depending on Ec/Io and CCH load/PwR calculation, UE moves to Cell DCH
RRC Idle Cell_PCH

Cell_DCH • UE’s cell known
• no UE Location • DCH allocated • UE to be paged
Information • UE’s cell known (DRX functionality
in UTRAN → PICH)
• only LAI / RAI
in CN
• no data transfer
possible
With i- phone • RRC Connection
establishment via
Cell_FACH URA_PCH
RACH/FACH • common channel • similar to Cell_PCH
Not possible signaling allocated (FACH, • no Cell Update,
New RACH, CPCH, DSCH) but URA Update
Quicker access Establish • UE’s cell known
/ Release
via RACH/FACH RRC Connection mode
Connection
for UE
Common Channel Setup
Extra slide
• Allocation of RACH and FACH or DCH is based on establishment

cause received from UE (22 causes)
• Available SRB DCH bitrates are 3.4 kbps or 13.6 kbps

• Parameter to set appropriate bit-rate per establishment cause
• RACH and FACH load is continuously monitored in RNC

• Common channel setup increases load to RACH-FACH channels
• Air interface quality (CPICH EcNo) criteria has impact on CCH

allocation
• Algorithm checks minimum required EcNo when triggered

DRA - performance improvement - RU 20
Direct Resource Allocation for HSPA
Prior for a NRT service without "wasting time" for CR (RU20)
UE must support HSDPA and HSUPA transport channels
DRA is always used when UE has F-DPCH allocated
HSDPA and HSUPA must be enabled in the cell
Prior to RU20 for NRT user allocation of 0/0 DCH by AC
If a Capacity Request (CR) was received, RNC made channel type selection
If no Capacity Request received by RNC, UE was moved to Cell FACH
RRC Idle Cell_PCH

Cell_DCH • UE’s cell known
• DCH allocated
DRA
• no UE Location • UE to be paged
Information • UE’s cell known (DRX functionality In RU20 HSPA transport channels
in UTRAN → PICH)
• only LAI / RAI
can be allocated directly in Cell DCH
in CN or
• no data transfer
possible Cell FACH (Common Channel
• RRC Connection
Cell_FACH URA_PCH Setup), without waiting for
establishment via
RACH/FACH • common channel • similar to Cell_PCHcapacity request CR
signaling allocated (FACH, • no Cell Update,
New RACH, CPCH, DSCH) but URA Update
Establish • UE’s cell known
/ Release
Soc Classification level RRC Connection mode
93 Connection
© NSN Siemens Networks Presentation / Author / Date
Continuous Packet Connectivity - CPC - RU 20
Introduction
• 3GPP Release 7 Continuous Packet Connectivity - CPC
• Main target is the reduction of UE power consumption

• Leads to increased packet connection time and on-line availability
• Reduces the power overhead in the cell / system
• Faster data transfer after data inactivity
• WCDMA control channel (Rel99, 4, 5, 6) need to be on-air continuously

• UL transmission & DL reception
• Eating UE battery power – therefore less battery lifetime experienced

Continuous Packet Connectivity - new within RU 20
• CPC eliminates the requirement for continuous transmission and reception during
periods when data is not transferred
• Exploits discontinuities in packet data services
• Designed to work with VoIP
Downlink Reduced CQI New Uplink DPCCH Uplink

DRX Reporting Slot Format DRX HS-SCCH Less
Operation
Uplink DTX
USER GAIN SYSTEM GAIN
UE Power Saving Inactive HSPA UE

Potential to keep
more inactive UE in require less resource
CELL_DCH
Reduced delay for
Increased talk re-starting data Increased
time transfer Capacity

RRC Re-Establishment for RT (RRC signaling)
UE Node B RNC MGW
M1006C186RRC_RE_EST_SUCC_RT : The number of successful RRC
[RACH] RRC:Cell Update (Cause: RL Failure) connection re-establishments for UEs with at least one RT RAB. Updated
when the RNC receives RRC: RADIO BEARER RECONFIGURATION
[FACH] RRC: Cell Update Confirm COMPLETE message from the UE after an RRC connection re-
[RACH] Utran Mobility Information Confirm establishment procedure and the UE has got at least one RT RAB
NBAP: RL Reconfiguration Prepare
M1006C187RRC_RE_EST_FAIL_UE_RT : The number of failed RRC
connection re-establishments due to the UE replying with a new RRC:
ALCAP:ERQ CELL UPDATE message, for UEs with at least one RT RAB. Updated
when the RNC receives RRC: CELL UPDATE message from the UE after
ALCAP:ECF an attempted RRC connection re-establishment procedure and the UE has
[FACH] RRC: RB Reconfiguration got at least one RT RAB
NBAP: Radio Link Reconfiguration Commit
M1006C188RRC_RE_EST_FAIL_NOREPLY_RT : The number of failed
[RACH] RRC:Cell Update (Cause: RL Failure) RRC connection re-establishments due to the UE not replying to an RRC:
CELL UPDATE CONFIRM message sent by the RNC, for UEs with at
[DCH] RRC: RB Reconfiguration Complete least one RT RAB. Updated when the RNC does not receive a reply to
RRC: CELL UPDATE CONFIRM message initiated by the RRC
connection re-establishment procedure and the UE has got at least one
RT RAB.
• T314 parameter tells when Cell update message should be coming after RL failure, def 4s
• Re-establishment can be done to different cell also

Multi RAB Re-Establishment
UE Node B RNC MGW
[RACH] RRC:Cell Update (Cause: RL Failure) M1006C189RRC_RE_EST_SUCC_MR : The number of successful RRC
connection re-establishments for UEs with at least two RABs. When the
[FACH] RRC: Cell Update Confirm RNC receives RRC: RADIO BEARER RECONFIGURATION COMPLETE
[RACH] Utran Mobility Information Confirm message from the UE after an RRC connection re-establishment
procedure and the UE has got at least two RABs.
M1006C190RRC_RE_EST_FAIL_UE_MR : The number of failed RRC

ALCAP:ERQ connection re-establishments due to the UE replying with a new RRC:
CELL UPDATE message, for UEs with at least two RABs. Updated when
ALCAP:ECF the RNC receives RRC: CELL UPDATE message from the UE after an
[FACH] RRC: RB Reconfiguration attempted RRC connection re-establishment procedure and the UE has
NBAP: Radio Link Reconfiguration Commit got at least two RABs.
[RACH] RRC:Cell Update (Cause: RL Failure) M1006C191RRC_RE_EST_FAIL_NOREPLY_MR : The number of failed

RRC connection re-establishments due to the UE not replying to an RRC:
[DCH] RRC: RB Reconfiguration Complete CELL UPDATE CONFIRM message sent by the RNC, for UEs with at
least two RABs. Updated when the RNC does not receive a reply to RRC:
CELL UPDATE CONFIRM message initiated by the RRC connection re-
establishment procedure and the UE has got at least two RABs.

RAS06 Packet Session failures
Failures are divided into Release due to RL Failure counters:
• RL fail M1022C57 PS_REL_RL_FAIL_HS_E_INT

M1022C58 PS_REL_RL_FAIL_HS_E_BGR
• Pre_emption M1022C59 PS_REL_RL_FAIL_HS_D_INT
M1022C60 PS_REL_RL_FAIL_HS_D_BGR
• Other M1022C61 PS_REL_RL_FAIL_D_D_INT
M1022C62 PS_REL_RL_FAIL_D_D_BGR
are incremented in case RL Failure is received from BTS and cannot be acquired
back during specific time (see Dropped RAB analysis in coming slides for further
info)
Release due to Other Failure counters:

M1022C63 PS_REL_OTH_FAIL_HS_E_INT
M1022C64 PS_REL_OTH_FAIL_HS_E_BGR
Release due to Pre-Emption counters: M1022C65 PS_REL_OTH_FAIL_HS_D_INT
M1022C51 PS_REL_PRE_EMP_HS_E_INT M1022C66 PS_REL_OTH_FAIL_HS_D_BGR
M1022C52 PS_REL_PRE_EMP_HS_E_BGR M1022C67 PS_REL_OTH_FAIL_D_D_INT
M1022C53 PS_REL_PRE_EMP_HS_D_INT M1022C68 PS_REL_OTH_FAIL_D_D_BGR
M1022C54 PS_REL_PRE_EMP_HS_D_BGR are incremented in case the PS allocation is released due to any other reason
M1022C55 PS_REL_PRE_EMP_D_D_INT expect normal, pre-emption or RL failure
M1022C56 PS_REL_PRE_EMP_D_D_BGR
are incremented in case higher priority call pre-empts the existing connection i.e.
RT over NRT

RAN 1601:Complementary Counters in RU10
• RAN 1601: Complementary Counters M1001C632
M1001C634
ServiceLevel
ServiceLevel
SUCC_RRC_SETUP_INTERA
SUCC_RRC_SETUP_OTHER
in RU10,Radio Access Bearer M1001C631 ServiceLevel SUCC_RRC_SETUP_STREA
Services M1001C633
M1001C630
ServiceLevel
ServiceLevel
SUCC_RRC_SETUP_BACKG
SUCC_RRC_SETUP_CONV
• RAN 1601: Complementary Counters M1001C639
M1001C636
ServiceLevel
ServiceLevel
SRB_ACT_FAIL_OTHER
SRB_ACT_FAIL_STREA
in RU10,MS Connection Establishment M1001C638 ServiceLevel SRB_ACT_FAIL_BACKG
M1001C635 ServiceLevel SRB_ACT_FAIL_CONV
M1001C637 ServiceLevel SRB_ACT_FAIL_INTERA
• AAL2 setup time
• RRC connection request-setup time M 10 06 C19 4

M 10 06 C19 5
RR C S UM_ TIM E_ A AL 2_ S ETUP
RR C DE NO M_ TIM E _A AL 2_ S ETUP
M 10 06 C18 2 RR C S UM_ RES _ AL LO _ TIM E _RRC_ S ETUP

M 10 06 C18 3 RR C DE NO M_ RES _ AL LO _ TM _RRC_ S ETUP

RRC states
Thank You !
– finally finished

R99: Call Drop

HSPA setup
HSPA mobility
RRC states
Appendix –

call setup failures
Starting criteria for setup failure analysis
RRC or RAB setup failures could be due issues related to

• Coverage or interference
• Inter RNC problem
• Capacity
Capacity issues could results to the RRC/RAB setup failures related to
• BTS for Channel Element (WSP & FSM) capacity issues, TRANS for Iub
capacity issues or AC for radio capacity issues (UL Load, DL Load and DL
spreading codes)
Some type of RRC/RAB failures should NOT be present
• RRC_CONN_ACT_FAIL_RNC
• RAB_ACT_FAIL_xxx_RNC
SRNC relocation issues will also cause RRC/RAB failures
• See more info in RRC access failure scenario (at the end of this module)
RF optimization (+drive testing) may be needed also
RRC_CONN_STP_FAIL_AC
• Check UL Interference, DL Power & Code occupancy if there is need to upgrade radio capacity
• UL Power Spikes -> Disable UL Admission Control to if the number of failures is critical
• M1002C1 CH_REQ_LINK_REJ_UL_SRNC ----> Evaluate Prx Resource Problem
RRC_CONN_STP_FAIL_BTS
• Evaluate NBAP counters (radio link reconf. Failures) and KPIs for troubleshooting BTS resources
• M1002C2 CH_REQ_LINK_REJ_DL_SRNC ----->Evaluate Ptx Resource Problem
• Check BTS configuration in terms of WAM and CE allocation – Use Channel Element (5001)
Counters in order to evaluate lack of Channel Elements
• Expand the Capacity or decrease the traffic offered to the site
• In case BTS is not responding delete and re-create COCO
RRC_CONN_STP_FAIL_TRANS
• Evaluate Number of reconfiguration failure due the transmission
• Check COCO Configuration
• Use AAL2 Mux in case of two WAM
• Expand the capacity or decrease the traffic offered to the site
RRC_CONN_STP_FAIL_RNC
• Typically RNC fault or Incoming SRNC Relocation Failure (inter-RNC border)
• Required ICSU log tracing if no RNC fault or SRNC relocation problem

RRC_CONN_STP_FAIL_RNTI ALLO FAIL
• RNC decides to reject RRC connection request due to RNTI allocation failure caused by RRMU
overload
RRC_CONN_STP_FAIL_IUB_AAL2_TRANS
• Updated when there is shortage or blocking of AAL2 resource
• A subset of RRC_CONN_FAIL_TRANS which include ERQ/ECF fail due to some reason such as
DMPG problem in RNC + ERQ/ECF fail due to transport resource needed in RNC between RNC/MGW
RRC_CONN_ACC_FAIL_RADIO
• Dominant failure causes
• Perform drive test to detect if UL or DL coverage
• UL Coverage -> Tune Cell Dominance if the cause is UL interference
• DL Coverage -> Tune SCCPCH Power if UE does not receive the RRC Setup Message
-> If UE does not synchronize, reduce N312 from 2 to 1 (depends on UE model) or tune
CPICHToRefRABOffset vs.Qqualmin (or Qrxlevmin)
RRC_CONN_ACC_FAIL_MS
• UL Coverage -> Tune Cell Dominance (or CPICH) in order to balance UL and DL
(if UL interference if not the cause)

call setup - RAB
RAB setup failures - Root Cause Analysis
Check the problem cells and its neighbouring cells of any faulty alarms
Identify root cause failure distribution and main failure
RAB_STP_FAIL_XXX_AC
Check UL Interference, DL Power & Code occupancy if there is need to upgrade radio capacity
• REQ_CS_VOICE_REJ_UL_SRNC -> Evaluate Prx cell resource
• REQ_CS_VOICE_REJ_DL_SRNC -> Evaluate Ptx cell resource
• NO_CODES_AVAILABLE_SF128/SF32 -> Evaluate AMR voice / PS64 code congestion
RAB_STP_FAIL_XXX_BTS
• Evaluate NBAP counters (radio link reconf. Add failures) and KPIs for troubleshooting BTS
resources
• Check BTS configuration in terms of WAM and CE allocation – Use Channel Element (5001)
Counters in order to evaluate lack of Channel Elements
• Expand the Capacity or decrease the traffic offered to the site
• In case BTS is not responding delete and re-create COCO

call setup - RAB
RAB_STP_FAIL_XXX_TRANS
• Evaluate Number of reconfiguration failure due the transmission
• Check M1005C128 CANC_ADD_SRNC_TRAN_STP_FAIL
• Check RAB_STP_FAIL_XXX_IUB_AAL2, M1001C531-C533
• Check COCO Configuration
RAB_ACC_FAIL_XXX_MS
• Evaluate Cell resource Prx and Ptx (for example high uplink interference)
• Check RB reconfiguration failure ration ( If ATO setting is insufficient )
RAB_ACC_FAIL_XXX_RNC
Note: RNC does not reserve radio interface

Soc Classification level resources in RAB setup phase for NRT
call setup - RAB
RAB_ACC_FAIL_XXX_MS
• Evaluate Cell resource Prx and Ptx (for example high uplink interference)
• Check RB reconfiguration failure ration ( If ATO setting is insufficient )
RAB_ACC_FAIL_XXX_RNC

RAS06 Packet Calls
Separate Packet call counters could be used in UL/DL to see the accessibility/re-tainability
of DCH radio bearers (R99 NRT, HSDPA, HSUPA)
• There could be multiple packets inside single RAB
Packet calls starts with user plane capacity allocation (transfer from FACH/PCH, DCH 0/0)
and ends with dedicated resource release (transfer back to FACH/PCH, DCH 0/0, RAB
release, outgoing relocation, HHO, ISHO)
There are counters for the following channel combinations
• Rel99 DL = DCH UL = DCH
• HSDPA DL = HS-DSCH UL = DCH
• HSUPA DL = HS-DSCH UL = E-DCH
There are counters for the following events
• Attempts,Allocations,Channel switches,Setup failures,Normal and abnormal releases

PS RAB Upgrade or HSDPA/HSUPA Activation
UE Node B RNC SGSN If RNC receives RRC: Measurement Report indicating event 4a
RANAP: RAB Assignment Request when UE has been allocated DCH0/0 or in cell_PCH state
RNC receives Cell Update indicating need for dedicated
AC to check to accept channel (i.e. cause UPLINK DATA TRANSMISSION), following
or reject RAB counter is incremented:
Assignment Request M1022C0 PS_SESSION_REQ_UL
[DCH] RRC: Radio Bearer Setup If the network wants to initiate any downlink activity and the UE
is in Cell_PCH state, it needs to make a paging request.
[DCH] RRC: Radio Bearer Setup Complete Counter M1022C1 PS_SESSION_REQ_DL is incremented
RANAP: RAB Assignment Response:
when RNC receives RRC: CELL UPDATE message with the
Success cause PAGING RESPONSE
[DCH] RRC: Measurement Control In case of inter RNC HHO or SRNC relocation counter
[DCH] RRC: Measurement Control M1022C2 PS_SESSION_REQ_OTHER is incremented when
RANAP: RELOCATION REQUEST message request is
Direct Transfer : Activate PDP Context Accept
received
[DCH] RRC: Measurement Report Note: PS ISHO do not use relocation signaling as it is a normal
PS call setup where the resources are reserved by UL/DL
AC to check to accept
or reject Capacity capacity request
request
NOTE: These counters are NOT incremented when resources

(DMPG) are re-allocated due to: Direct switching from DCH
NBAP: RL Reconfiguration Failure xx/yy to HS-DSCH/E-DCH or HS-DSCH/DCH

RAS06 Packet Call failures
Initial Setup fail procedure
• AC failure : lack of DL power or high interference
• BTS failure: lack of HW capacity
• DMCU failure: lack of DSP resources in RNC
• TRANS failure: lack of Iub capacity (COCO parameters)
• UE failure: UE internal problem (not capability issue)
Separate Packet SSSR for R99 NRT, HSDPA and HSUPA to see the main failure
type
Reguests vs. allocations
• It is possible to see whether HSPA was not allocated DL/UL, but DCH instead
(capacity issue)
Separate PS release fail for R99 NRT, HSDPA and HSUPA to see the main failure
source

PS Call Counter failure - AC
Resource reservation happens during PS
user plane allocation.
UE Node B RNC SGSN
• If user plane allocation is rejected by the RANAP: RAB Assignment Request
admission control. RAS06 new PS call
counters AC to check to accept or
reject RAB Assignment
– M1022C9 Packet Call Setup Fail due to Request
AC for Interactive [DCH] RRC: Radio Bearer Setup

– M1022C10 Packet Call Setup Fail due to [DCH] RRC: Radio Bearer Setup Complete
AC for Background RANAP: RAB Assignment Response:
Success
are updated [DCH] RRC: Measurement Control
[DCH] RRC: Measurement Control
Direct Transfer : Activate PDP Context Accept
[DCH] RRC: Measurement Report
AC to check to accept or
reject Capacity request
In case the starting state of the terminal is Cell_FACH (Cell_PCH) or DCH 0/0
and AC rejects the bit rate allocation and terminal stays at Cell_FACH or
DCH0/0, following counters are incremented:
M1022C9 PS_SETUP_FAIL_AC_INT
M1022C10 PS_SETUP_FAIL_AC_BGR
Note: These counters are only incremented in case of initial allocation for
terminal has been Cell_FACH (Cell_PCH) or DCH0/0.
Successful Packet Call setup allocations and allocation attempts due to
Incoming relocation or Inter-RNC HHOs are not counted separately.
Call Drop analysis
1. Check high call drop cells and its neighbouring cells of any faulty alarms
2. Identify call drop root cause failure distribution and main failure contributor (radio, Iu, BTS,
Iur, MS, RNC)
3. Check SHO KPI if performance < 90% ( leads to radio failure)

• Check if cells are at RNC border (check Iur capacity and SRNC relocation problem)
• Detect badly performing neighbours using HO success rate per adjacency counters (M1013)
• High incoming HO failure rate in all adjs – check sync alarms
• Assessing neighbor list plan and visualization check with map
• Evaluate HO control parameters and trigger threshold
4. Check ISHO KPI if RT ISHO < 90% or NRT < 80% (leads to radio failure)
Check missing neighbour (M1015), GSM frequency plan neighbour RNC and MSC database
consistency audit, check alarm of reference clock in 3G or in 2G, check 2G TCH congestion
Check RRC Drop ISHO RT / NRT
Call Drop analysis
5. Detecting DL or UL path loss problem if RAB drop due to radio (dominant call
drop cause > 50%)
Check UL Lost Active KPI from Iub counters (active L1 synchronization failure) to check UL/DL
path loss problem
Check ASU failure rate (UNSUC_ASU) which link to NO RESPONSE FROM RLC
Mapping radio failures with Tx power and CPICH related parameters ->
CPICHToRefRABOffset, PTXDPCH MAX
Check Call reestablishment timer -> T315
Ecno distribution for bad coverage issue (M1007C38-M1007C47)
6. Check core network parameter setting if RAB_ACT_FAIL_XXX_IU
Check SCCP SGSN/RNC IuPS Tias/Tiar if RAB_ACT_FAIL_BACKG_IU
7. If high RAB_ACT_FAIL_XXX_BTS
Check if any BTS faulty alarm (7653 cell faulty alarm)
If no alarms, COCO detach/attach
8. If high RAB_ACT_FAIL_XXX_MS
• Check physical channel reconfiguration failure rate (IFHO, ISHO, code optimisation)

RAS06 PS setup fail comparison with RAS5.1 PS RAB
setup, RNC level
0.060
RNC_376a RAB setup failures for PS caused by

0.050 the AC
transmission
RNC's internal reasons
0.040 RNC_380a RAB setup failures for PS caused by
anchoring RNC reject.
RNC_381a RAB setup failures for PS due to a
frozen BTS
PS_SETUP_FAIL_AC_p
0.030
PS_SETUP_FAIL_AC_p
PS_SETUP_FAIL_BTS_p
PS_SETUP_FAIL_BTS_p
PS_SETUP_FAIL_DMCU_p
0.020 PS_SETUP_FAIL_DMCU_p
PS_SETUP_FAIL_TRANS_p
PS_SETUP_FAIL_UE_p
PS_SETUP_FAIL_UE_p
0.010 PS_SETUP_FAIL_OTHER_p
PS_SETUP_FAIL_OTHER_p
0.000
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
3.
3.
3.
3.
4.
4.
4.
4.
5.
.0
.0
.0
.0
.0
.0
.0
.0
.0
08
15
22
29
05
12
19
26
03

RAS06 PS setup fail comparison with RAS5.1- HSDPA
setup, RNC level
0.180
RNC_661a HSDPA Access failures due to UL

DCH
0.160
RNC_663a HSDPA Access failures due to RNC
RNC_665a HSDPA Access failures due to Iub

0.140
RNC_667a HSDPA Access failures due to UE
0.120 RNC_669a HSDPA Access failures due to too

many HSDPA users
RNC_671a HSDPA Access failures due to Multi-
0.100 RAB
RNC_673a HSDPA Access failures due to BTS
0.080 PS_SETUP_FAIL_AC_p
PS_SETUP_FAIL_AC_p
PS_SETUP_FAIL_BTS_p
0.060 PS_SETUP_FAIL_BTS_p
0.040 PS_SETUP_FAIL_TRANS_p
PS_SETUP_FAIL_UE_p
PS_SETUP_FAIL_UE_p
0.020
0.000
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
3.
3.
3.
3.
4.
4.
4.
4.
5.
.0
.0
.0
.0
.0
.0
.0
.0
.0
08
15
22
29
05
12
19
26
03

Radio Link Failure
The counter DEL_SHO_SRNC_ACT_RL_SYNC_ FAIL measure the number of
Radio link deletions on SRNC side due to an active radio link synchronisation
failure.
Counter is updated when a BTS loses synchronisation on an active RL and is not
able to re-establish synchronisation during the allowed time.
RL_SETUP_ATT_FOR_SHO_ON_SRNC
RL_BRANCH_ADD_SUCC_SHO_SRNC
DEL_SHO_SRNC_ACT_RL_SYN_FAIL
RL_SETUP_ATT_FOR_FIRST_RL
U L_LO ST_AC TIVE

R N C -C ITTA
UL_LOST_ACTIVE
R N C _ID
D AY
RNC-CITTA
RNC2
CELL_ID
RNC_ID
NE-RNC-2 MILANO1 20050117 10.0%

average:
DAY
NE-RNC-2 MILANO1 20050118 10.3%

NE-RNC-2
NE-RNC-2
62272
62272
MILANO1
MILANO1
20050117 770
20050118 606
401
363
206
241
295
267
21.4%
22.1% NE-RNC-2 MILANO1 20050119 10.1% 10%
NE-RNC-2 62272 MILANO1 20050119 669 493 161 308 23.3% NE-RNC-2 MILANO1 20050120 9.8%
NE-RNC-2 62272 MILANO1 20050120 777 460 166 357 25.4%
NE-RNC-2 62272 MILANO1 20050121 1215 672 265 464 21.6%

RAB Active Phase Failures
Cells having high RAB drop ratio due the Radio or UE can be identified by service
level counters
Formula below count CS voice RAB drop ratio due the radio from network
perspective.
100*
RAB_ ACT _ FAIL_ CS _ VOICE_ RADIO
[%] RAB Drop ratio can
RAB_ ACT _ COMP_ CS _ VOICE+ RAB_ ACT _ REL_ CS _ VOICE_ P _ EMP+
per RAB type or RAB
RAB_ ACT _ REL_ CS _ VOICE_ SRNC+ RAB_ ACTIVE_ REL_ CS _ V _ UNSPE_ ER _ CN +
RAB_ CS _ VOICE_ IN _ REF _ CELL− RAB_ CS _ VOICE_ OUT _ REF _ CELL+
drop rate containing
all RABs
∑ RAB_ ACT _ FAIL_ CS _VOICE
all _ failures
The counters RAB_Active_Fail_XXX_Radio/UE can be used to measure air interface

. Following failures are related to counters
OUT FAIL SOURCE OUT REASON OUT DETAILED REASON Counter Service Level
radio_interface_c radio_link_failure_c radio_conn_lost_c Active_Fail_Radio
radio_interface_c no_resp_from_rlc_c default_c Active_Fail_Radio
ms_c physical_ch_reconf_fail_c timer_expired_c Active_Fail_UE
ms_c radio_conn_lost_c timer_expired_c Active_Fail_UE

Radio Connection Lost- RAB Reconfiguration fail
RAB Reconfiguration Success Rate KPI is ~2% lower than at RNC level
cell has other kind of “radio” failures

Drop voice is 3% 100 *
RB_RECONF_COMPLETE
[%]
RB_RECONF
CELL level RNC level
RB_RECONF_SUCCESS_RATE
RB_RECONF_SUCCESS_RAT
RB_RECONF_COMPLETE
RB_RECONF_COMPLETE
RB_RECONF
RB_RECONF
RNC-CITTA
DAY
CELL
DAY
MILANO1 20050117 128890 127617 99.0%

62542 20050117 284 283 99.6%
62542 20050118 1619 1570 97.0% MILANO1 20050118 138597 137227 99.0%
62542 20050119 2169 2102 96.9% MILANO1 20050119 142997 141604 99.0%
62542 20050120 1857 1787 96.2% MILANO1 20050120 136753 135481 99.1%
62542 20050121 1168 1132 96.9% MILANO1 20050121 118625 117340 98.9%

R99: Mobility - RRC Drop during ISHO RT
When the source RCC Connection drops (and the RNC sends the RANAP : Iu
Release Request to the CN) during the ISHO, one of the following counter is
triggered:
UE BTS RNC CN
RRC: Measurement Control
RRC: Measurement Report (3,4,5) M1010C21 CON_DRPS_IS_HHO_UL_DCH_Q_RT
AC check for CM M1010C25 CON_DRPS_IS_HHO_UE_PWR_RT
NBAP: Radio Link Reconfiguration Prepare M1010C29 CON_DRPS _IS _HHO_DL_DPCH_RT
NBAP: Radio Link Reconfiguration Ready M1010C33 CON_DRPS _IS _HHO_RSCP_RT
M1010C37 CON_DRPS _IS _HHO_ECNO_RT
RRC: Physical Channel Reconfiguration
M1010Cxxx
RRC: Physical Channel Reconfiguration Complete
CON_DRPS_IS_HHO_LSHO_triggers_RT*
RX Level measurement phase for NBAP: Compressed Mode Command • If neither the target BSC has received the HO complete
all ISHO neighbours message nor the source RNC has received a failure from the
mobile, the source RNC sends the “IU RELEASE REQUEST”
RRC: Measurement Report
message to the CN.
BSIC verification phase for target cell NBAP: Compressed Mode Command • For RT: TRelocOverall (def. 8s, from Relocation
RRC: Measurement Control Command to Iu Release Command) expires.
RANAP: Relocation Required
RRC: Handover from UTRAN Command RANAP: Relocation Command

RANAP: IU Release Request
R99: Mobility RRC Drop - SHO NRT
Iu Radio Link Failure
When the source RCC Connection drops (and the RNC sends the RANAP : Iu Release
Request to the CN) during the ISHO, one of the following counter is triggered:
UE BTS RNC CN
RRC: Measurement Report (3,4,5)
AC check for CM M1010C21 CON_DRPS_IS_HHO_UL_DCH_Q_NRT

M1010C25 CON_DRPS_IS_HHO_UE_PWR_NRT
NBAP: Radio Link Reconfiguration Prepare
NBAP: Radio Link Reconfiguration Ready M1010C29 CON_DRPS _IS _HHO_DL_DPCH_NRT
NBAP: Radio Link Reconfiguration Commit M1010C33 CON_DRPS _IS _HHO_RSCP_NRT
RRC: Physical Channel Reconfiguration M1010C37 CON_DRPS _IS _HHO_ECNO_NRT
RRC: Physical Channel Reconfiguration Complete
M1010Cxxx
RX Level measurement phase for NBAP: Compressed Mode Command CON_DRPS_IS_HHO_LSHO_triggers_NRT*
all ISHO neighbours
• If neither the target BSC has received the HO complete
message nor the source RNC has received a failure from the
mobile, the source RNC sends the “IU RELEASE REQUEST”
message to the CN.
BSIC verification phase for target cell NBAP: Compressed Mode Command
RRC: Measurement Control • For NRT: IU release request is sent after 8s from
RRC: Measurement Report sending Cell Change Order.
RRC: Cell Change Order from UTRAN
RANAP: SRNS Context Request
RANAP: SRNS Context Response
RANAP: SRNS Data Forward Command
Soc Classification level RANAP: IU Release Request
R99: Mobility ISHO Analysis
4. If Low ISHO Measurement Success Rate
• Check ADJG neighbour list for missing neighbours
• Check parameter discrepancy (BSIC) or BSIC collision due to too tight reuse
• Check Compressed mode parameter set
• Check ISHO triggering Threshold – too slow triggering
• Check EcNo Distribution (M1007C38-M1007C47) to indicate low coverage /
interference problem
5. If Low ISHO Success Rate (RT <95% & NRT < 80%)
• Check missing or wrong 2G parameter in MSC/SGSN (LAC, CellId, BCCH)
• Check discrepancy of Cell information in RNC
• Check 2G cell GPRS/EGPRS data congestion
6. May require further troubleshooting with ICSU logging to determine root cause of failure
Handover -> Report RSRAN018

Handover -> Report RSRAN019
Handover-> Report RSRAN023

HSDPA Retainability Failure Cause Analysis
HSDPA Retainability for NRT Traffic
No
RNC_609a < X % No action
needed
Top N cells
Yes
No No No No
HS_DSCH_ HS_DSCH_ HS_DSCH_ RL_FAIL_ OTH_FAIL_
PRE_EMP MOB_DCH OTH_DCH HS_DSCH HS_DSCH
Yes Yes Yes Yes Yes
Normal Release
Normal Release Normal Release Check SCC
(No action Check RB
(No action (No action Failure Rate –
needed) reconfiguration failure
needed) needed) Radio, Iub, CE
resource rate – UE responsed
congestion with failure or no
response at all
No
Check CQI
distribution and Check HSDPA mobility
Ecno distribution No parameter – Add/Drop
for coverage window, SCC parameter
issue

HSDPA Retainability analysis
1. Identify root cause failure distribution and main contributor of low retainability
2. If high HSDPA Radio Link Failures (NRT) – dominant cause

Compare to Cell Update ATT due to Radio link Failure (M1006C39) and Cell Update ATT due to RLC
Recoverable Error (M1006C40)
Check Serving Cell Change failure rate (RAN_KPI_0048) - high SCC failures lead to radio link failure
Check CQI distribution (M5000C8-M5000C39) or Ecno distribution for bad coverage issue (M1007C38-
M1007C47)
Check HSDPA FMCS Mobility Control Parameter (handover or SCC too late)
Check call re-establishment T315 timer due to radio link failure

HSDPA Retainability analysis
3. If high HSDPA Non- Radio Link Failures (NRT)
UE responding with some failure message or not responding to some message but no RL failure (timer
expiry)
Check RB reconfiguration, physical channel reconfiguration, NBAP RL reconfiguration failure rate
Required ICSU log for further troubleshooting ?

Complementaty counters: RRC Setup Time
UE Node B RNC M1006C182SUM_RES_ALLO_TIME_RRC_SETUP : Sum of HW, Transmission
and Radio resource allocation time in the RRC Connection Establishment
[RACH] RRC:RRC Connection procedure, defined as the time between
Request RRC: RRC CONNECTION REQUEST received by RNC and
AC to check to accept RRC:RRC CONNECTION SETUP sent to UE.
This counter, divided by the denominator, provides the average resource allocation
or reject RRC
time. Updated when the RNC sends RRC: RRC CONNECTION SETUP to the UE
Connection Request M1006C183DENOM_RES_ALLO_TM_RRC_SETUP : Denominator for
NBAP: RL Setup Request M1006C182, used for average calculation. Updated by value 1, then the measured
time is updated to counter M1006C182.
Start
NBAP: RL Setup
TX/RX M1001C630SUCC_RRC_SETUP_CONV is incremented
Response when the RRC connection is set up successfully, i.e. RNC receives RRC: RRC CONNECTION SETUP
ALCAP:ERQ COMPLETE and the establishment cause in the preceding RRC: RRC CONNECTION REQUEST has
been either Originating Conversational Call or Terminating Conversational Call.
ALCAP:ECF
M1001C631SUCC_RRC_SETUP_STREA is incremented
[FACH] RRC: RRC Connection Setup When the RRC connection is set up successfully, i.e. RNC receives RRC: RRC CONNECTION SETUP
COMPLETE and the establishment cause in the preceding RRC: RRC CONNECTION REQUEST has
Start TX/RX been either Originating Streaming Call or Terminating Streaming Call
M1001C632SUCC_RRC_SETUP_INTERA is incremented
L1 Synchronisation When the RRC connection is set up successfully, i.e. RNC receives RRC: RRC CONNECTION SETUP
NBAP: Synchronisation Indication been either Originating Interactive Call or Terminating Interactive Call.
[DCH] RRC: RRC Connection Setup Complete M1001C633SUCC_RRC_SETUP_BACKG is incremented

When the RRC connection is set up successfully, i.e. RNC receives RRC: RRC CONNECTION SETUP
RAB Setup & Access been either Originating Background Call or Terminating Background Call
M1001C634SUCC_RRC_SETUP_OTHER is incremented
When the RRC connection is set up successfully, i.e. RNC receives RRC: RRC CONNECTION SETUP
been some other cause.
Complementaty counters: SRB Active fail
UE Node B M1001C635SRB_ACT_FAIL_CONV is incremented When a standalone SRB is released due to some
RNC failure, i.e. when it is counted as RRC Active Failure in the old Service Level counters. The counter is
[RACH] RRC:RRC Connection updated when the establishment cause in RRC: RRC CONNECTION REQUEST is either Originating
Conversational Call or Terminating Conversational Call.
Request
AC to check to accept M1001C636SRB_ACT_FAIL_STREA is incremented When a standalone SRB is released due to
or reject RRC some failure, i.e. when it is counted as RRC Active Failure in the old Service Level counters. The
Connection Request counter is updated when the establishment cause in RRC: RRC CONNECTION REQUEST is either
Originating Streaming Call or Terminating Streaming Call.
NBAP: RL Setup Request
M1001C637SRB_ACT_FAIL_INTERA is incremented When a standalone SRB is released due to
some failure, i.e. when it is counted as RRC Active Failure in the old Service Level counters. The
Start counter is updated when the establishment cause in RRC: RRC CONNECTION REQUEST is either
TX/RX Originating Interactive Call or Terminating Interactive Call.
NBAP: RL Setup Response
ALCAP:ERQ M1001C638SRB_ACT_FAIL_BACKG is incremented When a standalone SRB is released due to
ALCAP:ECF some failure, i.e. when it is counted as RRC Active Failure in the old Service Level counters. The
counter is updated when the establishment cause in RRC: RRC CONNECTION REQUEST is either
[FACH] RRC: RRC Connection Setup Originating Background Call or Terminating Background Call
Start TX/RX M1001C639SRB_ACT_FAIL_OTHER is incremented When a standalone SRB is released due to

some failure, i.e. when it is counted as RRC Active Failure in the old Service Level counters. The
counter is updated when the establishment cause in RRC: RRC CONNECTION REQUEST is some
L1 Synchronisation other cause not covered by counters M1001C635-M1001C638.
NBAP: Synchronisation Indication
[DCH] RRC: RRC Connection Setup Complete
[DCH] RRC: RRC Connection Release
RAB Setup & Access

RAB Establishment- AAL2 setup time
UE Node B RNC MGW
RANAP: RAB Assignment Request
M1006C194SUM_TIME_AAL2_SETUP : Sum of Iub

AC to check to accept AAL2 Setup time, defined as the difference between
or reject RAB
Assignment Request ALCAP: Establishment Request (ERQ) and
ALCAP: Establishment Confirm (ECF). This counter,
NBAP: RL Reconfiguration Prepare divided by the denominator, provides the average
AAL2 setup time.
NBAP: RL Reconfiguration Ready
M1006C195DENOM_TIME_AAL2_SETUP :
ALCAP:ERQ Denominator for M1006C194, used for average
ALCAP:ECF calculation. Updated by value 1, then the measured
time is updated to counter M1006C194.

RAN 1232: Fast Call Setup from Cell_PCH State
• Packet data state transition M1006C170 RRC SUM_ST_TRANS_TIME_PCH_FACH
M1006C171 RRC DENOM_ST_TRANS_TIME_PCH_FACH
– Sum of state transition times from M1006C172 RRC SUM_ST_TRANS_TIME_FACH_DCH
M1006C173 RRC DENOM_ST_TRANS_TIME_FACH_DCH
Cell-FACH state to Cell-DCH/Cell-FACH M1006C174 RRC SUM_ST_TRANS_TIME_PCH_DCH
state M1006C175 RRC DENOM_ST_TRANS_TIME_PCH_DCH
Cell-PCH state to Cell-FACH/Cel_DCH M1006C176

M1006C177
RRC
RRC
SUM_ST_TRANS_TIME_DCH_FACH
DENOM_ST_TRANS_TIME_DCH_FACH
Cell-DCH state to Cell-FACH/Cell-PCH M1006C178 RRC SUM_ST_TRANS_TIME_DCH_PCH
M1006C179 RRC DENOM_ST_TRANS_TIME_DCH_PCH
Unit ms M1006C180 RRC SUM_ST_TRANS_TIME_FACH_PCH
M1006C181 RRC DENOM_ST_TRANS_TIME_FACH_PCH
• Resource allocation time: cell_fach
M 10 06 C18 4 RR C S UM_ RES _ AL LO _ TIM E _FA CH

M 10 06 C18 5 RR C DE NO M_ RES _ AL LO _ TM _FA CH

RRC State Changes from Cell_PCH/URA_PCH to
Cell_FACH/Cell_DCH & Time
UE Node B RNC
[FACH] RRC: Cell Update (paging response or M1006C199CELL_UPDATE_ATT_DATA_TR_TVM : The number of Cell Update
UL data transmission ) messages received with cause "uplink data transmission" and "traffic volume indicator"
IE set as true.
[FACH] RRC: Cell Update Confirm
Also M1006C36 is updated along with this counter. Updated when the RNC receives
[RACH] UTRAN Mobility Information Confirm
RRC: CELL UPDATE message with cause "uplink data transmission" and "traffic
NBAP: Radio Link Setup volume indicator" set as true.
NBAP: Radio Link Setup Response
ALCAP: ERQ
ALCAP: ECF
M1006C174SUM_ST_TRANS_TIME_PCH_DCH: Sum of state transition times from
[FACH] RRC: Radio Bearer Reconfiguration Cell-PCH or URA-PCH state to Cell-DCH state, defined as the time between:
[DCH] RRC: Radio Bearer Reconfiguration Complete RRC: Cell Update (cause: UL Data Transmission or Paging response) - RRC: Radio
[DCH] RRC: Measurement Control Bearer Reconfiguration Complete.
This counter, divided by the denominator, provides the average state transition time.
M1006C175DENOM_ST_TRANS_TIME_PCH_DCH: Updated by value 1, then the
measured time is updated to counter M1006C174
M1006C172SUM_ST_TRANS_TIME_FACH_DCH: Sum of state transition times from Cell-FACH state to Cell-DCH state, defined as
the time between: UL/DL capacity request, RAB Setup - RRC: Radio Bearer Reconfiguration Complete or RRC: Radio Bearer Setup
Complete.
M1006C173DENOM_ST_TRANS_TIME_FACH_DCH: Denominator for M1006C172 used for average calculation.
M1006C170SUM_ST_TRANS_TIME_PCH_FACH: Sum of state transition times from Cell-PCH or URA-PCH state to Cell-FACH state,
defined as the time between:
RRC: Cell Update (cause: UL Data Transmission or Paging response) and RRC: Utran Mobility Information Confirm (or any other UL-
DCCH message before UMIC). This counter, divided by the denominator, provides the average state transition time.
M1006C171DENOM_ST_TRANS_TIME_PCH_FACH: Denominator for M1006C170 used for average calculation.

RRC State Changes from Cell_DCH to Cell_FACH &
Time
UE Node B RNC M1006C154SUCC_HS_DSCH_TO_FACH : number of successful
[DCH] RRC: Radio Bearer Reconfiguration state transitions from HS-DSCH to DCH. Updated when the RNC
[RACH] RRC: Cell Update (Cell Reselection) receives RRC: RADIO BEARER RECONFIGURATION COMPLETE
message from the UE after a successful channel switch from HS-
DSCH to FACH
[RACH] RRC: Radio Bearer Reconfiguration Complete
[FACH] RRC: Measurement Control
NBAP: RL Deletion Request
NBAP: RL Deletion Response
ALCAP:Rel Req
ALCAP:Rel Conf
M1006C176SUM_ST_TRANS_TIME_DCH_FACH: Sum of state transition times from Cell-DCH state to Cell-

FACH state, defined as the time between: When RNC decides to initiate Cell_DCH to Cell_FACH transition -
RRC: Radio Bearer Reconfiguration Complete or Radio Bearer Release Complete.
M1006C177DENOM_ST_TRANS_TIME_DCH_FACH: Denominator for M1006C176 used for average calculation

RRC State Change time from Cell_DCH to Cell_PCH
UE Node B RNC
[DCH] RRC: Radio Bearer Reconfiguration
[RACH] RRC: Radio Bearer Reconfiguration

Complete
M1006C178SUM_ST_TRANS_TIME_DCH_PCH:Sum of state transition times from Cell-DCH state to Cell-PCH or

URA-PCH state, defined as the time between: When RNC decides to initiate Cell_DCH to Cell_PCH transition -
RRC: Radio Bearer Reconfiguration Complete or Radio Bearer Release Complete.
M1006C179DENOM_ST_TRANS_TIME_DCH_PCH: Denominator for M1006C178 used for average calculation

RRC State Change time from Cell_FACH to Cell_PCH
UE Node B RNC
[FACH] RRC: Physical Channel Reconfiguration
[RACH] RRC: Cell Update (Cell Reselection)
[RACH] RRC: Physical Channel Reconfiguration
Complete
M1006C180SUM_ST_TRANS_TIME_FACH_PCH Sum of state transition times from Cell-FACH state to Cell-PCH

or URA-PCH state, defined as the time between: When RNC decides to initiate Cell_FACH to Cell_PCH transition -
RRC: Physical Channel Reconfiguration Complete.
This counter, divided by the denominator, provides the average state transition time
M1006C181DENOM_ST_TRANS_TIME_FACH_PCH: Denominator for M1006C180 used for average calculation

Resource allocation time from Cell_FACH to Cell_DCH
UE Node B RNC M1006C184SUM_RES_ALLO_TIME_FACH : Sum of HW and Radio
resource allocation time between UL/DL capacity request or RT-RAB
[RACH] RRC: Measurement Report (e4a) Assignment Request received and
NBAP: RADIO LINK SETUP sent to NodeB.
NBAP: Radio Link Setup
This counter, divided by the denominator, provides the average
resource allocation time.
Updated : when the RNC sends NBAP: RADIO LINK SETUP to the
NodeB
M1006C185DENOM_RES_ALLO_TM_FACH : Denominator for

M1006C184, used for average calculation. Updated by value 1, then
the measured time is updated to counter M1006C184

Hard Handover Counters(Inter RNC, GAN)
•The number of RRC active releases
due to intra-frequency inter-RNC hard
handover M1001C642 ServiceLevel RRC_CONN_ACT_REL_INTRA_HHO
due to inter-frequency inter-RNC hard
M1001C800 ServiceLevel RRC_CONN_ACT_REL_HHO
handover/ISHO to GSM M1001C803 ServiceLevel RRC_CONN_ACT_REL_ISHO

due to inter-system handover to Generic
M1001C643 ServiceLevel RRC_CONN_ACT_REL_GANHO
Access Network (GAN).

RRC active releases due to HHO
UE RNC CORE M1001C642 RRC_CONN_ACT_REL_INTRA_HHO:
RAB Assignment Request (setup) The number of RRC active releases due to intra-
frequency inter-RNC hard handover. Updated when the
RNC receives RANAP: IU RELEASE COMMAND with
RANAP: Relocation Required cause "successful relocation" from the CN.
RANAP: Relocation Command

RRC: Handover from UTRAN Command
RANAP: IU Release Command M1001C643 RRC_CONN_ACT_REL_GANHO: The
number of RRC active releases due to inter-system
RANAP: IU Release Complete
handover to Generic Access Network (GAN). Updated
when the RNC receives RANAP: IU RELEASE
COMMAND with cause "successful relocation" from the
CN.
M1001C800 RRC_CONN_ACT_REL_HHO: The number of RRC active releases due to inter-frequency inter-RNC hard handover. Updated
when the RNC receives RANAP: IU RELEASE COMMAND with cause "successful relocation" from the CN.
M1001C803 RRC_CONN_ACT_REL_ISHO: The number of RRC active releases due to inter system handover to GSM. Updated when the
RNC receives RANAP: IU RELEASE COMMAND with cause "successful relocation" from the CN.

RRC Connection release due to Inactivity/RNC
HW resource
UE Node B RNC
UE in Cell_PCH/URA_PCH M1001C628RRC_CONN_REL_DUE_INACTIVITY: The number of

RRC connection releases due to user inactivity in Cell-PCH or URA-
RRC: Cell Update (RACH)
PCH state. When the RNC releases the RRC/Iu-PS connection based
RRC: Cell Update Confirm (FACH) on the MSActivitySupervision timer using release cause 'User Inactivity'
RRC: UTRAN Mobility Information Confirm (RACH) Also counter M1001C12 RRC_CONN_ACT_COMP is updated along
with this counter.
RRC: RRC Connection Release (FACH)
RRC: RRC Connection Release Complete (RACH)

M1001C629RRC_CONN_REL_DUE_HW_RES: The number of RRC
connection releases due to RNC HW resources.
Also counter M1001C12 is updated along with this counter. When the
RNC releases the RRC/Iu-PS connection due to the HW-resource
shortage in ICSU-units (amount of simultaneous RRC-connections) or
in DMCU-units (no L2 processing resources available for UE
DCCH/DTCH).

RRC connection release due to MSLOST_URA_PCH
UE Node B RNC
M1006C110RRC_REL_MSLOST_URA_PCH : The number of
[FACH] RRC: Physical Channel Reconfiguration RRC connection releases due to 'MS is lost' in URA_PCH state.
[RACH] RRC: Cell Update (Cell Reselection) Updated when a UE in URA_PCH state does not respond to
paging or does not make a periodic URA update within
URA_PCH supervision timer period and RNC releases the RRC
Connection resources
[RACH] RRC: Physical Channel Reconfiguration
Complete


02 RN31572EN20 PM Monitoring

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

02 RN31572EN20 PM Monitoring

Caricato da

Copyright:

Formati disponibili

3G RANOP RU20

Module 2 – Performance Monitoring & Data Analysis

Soc Classification level

Soc Classification level

Soc Classification level

R99: Mobility (SHO, HHO, ISHO)

Soc Classification level

Call/Session setup monitoring

Soc Classification level

KPIs (OCSR, CSSR, CCR) Traffica data

PMI Tickets NSRP (internal) Probe statistics

ICSU logs (internal) Interface trace Subscriber trace

Soc Classification level

Soc Classification level

The Complexity of the performance data increase with

List top 10-20 worst cells

Soc Classification level

Because of the large number of cells in the network, it is

Good methodology is to list top 10-20 worst cells per

Soc Classification level

10 worst cells (1% of the area)

50% Cells order by nb of drops

Soc Classification level

Either total number of failures or failure rate (%)

It may be required with some periodicity (e.g. one

• Larger time periods are preferable, together with

Soc Classification level

The Key I got …

R99: Mobility (SHO, HHO, ISHO)

Soc Classification level

Call/Session setup monitoring

Soc Classification level

NetAct Busy Hour

Soc Classification level

Soc Classification level

© NSN Siemens Networks

Presentation / Author / Date

R99_UL, GB (25 % AF)

Alternative measure for traffic on DL

Soc Classification level

Network Doctor for BSS

Contains ready made reports for analysing network

Soc Classification level

Soc Classification level

Ready made report definitions as well as KPI/PI

Soc Classification level

Real-time traffic monitoring and troubleshooting tool for Multi-

Updates counters and present the traffic in real-time graphs:

RNC monitoring (clear codes) in RAS06 !!

Soc Classification level

• Trace viewer is tool to start/stop traces

Soc Classification level

Subscriber and Equipment Trace Provide detailed

Subscriber trace can be used for:

Limited multi-vendor support

Soc Classification level

Why KPI’s do not smell like

Soc Classification level

R99: Mobility (SHO, HHO, ISHO)

Soc Classification level

Call/Session setup monitoring

Soc Classification level

Air Interface WBTS HW Resources Transport RNC

Soc Classification level