RANOP2 Module2 PM Monitoring Analysis RAS06 111008

3G RANOP2 RAS06 Module 2 Performance Monitoring & Data Analysis
Soc Classification level 1 Nokia Siemens Networks
Presentation / Author / Date
Module 2 Performance monitoring & data analysis

Objectives Describe the 3G RAN performance monitoring process & tools
High level KPIs -> PIs -> Counters Busy Hour problematic & Reporting periods
Describe the mechanism for call failure analysis related to RRC/RAB setup/access failure Session setup failure (NRT, HSDPA, HSUPA) RRC/RAB/SHO/ISHO active failure Active session failure HSDPA setup & throughput
List possible reasons for failures & improvement activities
Contents
Introduction KPI analysis hierarchy Busy Hour problematic Tools Call/Session Setup monitoring & analysis RRC setup RAB setup PS setup HSDPA setup/HSUPA setup Call/Session Drop monitoring & analysis RRC/RAB/SHO active HSDPA active/SCC/HSUPA active ISHO
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
Traffica data KPIs (OCSR, CSSR, CCR) Service Level Traffic SHO ISHO IFHO Cell Resource HHO
More details More understand ing More complexity More cost & time in acquisition
Signalling (RRC, Iub, Iu, Iur, Relocation)

PMI Tickets NSRP (internal)Probe statistics ICSU logs (internal) Interface trace Subscriber trace
PIs and raw counters from RAN measurement tables are marked blue
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 - missing cell has impact Failures due to Radio, to BTS, to transport Availability to 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
Soc Classification level 5 Nokia Siemens Networks Presentation / Author / Date
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 an minimum

number of attempts/failures per cell (depending on network traffic)
Cells order by nb of drops 100%
90%
80%
Cumulative percentage of drops
70%
60%
50%
Cells order by nb of drops
40%
10 worst cells (1% of the area) cause 14% of the drops
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
Contents
Introduction KPI analysis hierarchy Busy Hour problematic Tools Call/Session Setup monitoring & analysis Call/Session Drop monitoring & analysis
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
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)
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.)
16 /1 1/ 20 16
/1 1/ 20 20 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 20 /1 1/ 20 07 07 20 21 22 23 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 07 01 00 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ 1/ /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1 /1
07
16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16
Hourly traffic example, RNC level
Voice, GB (AF50%) R99_DL, GB (25 % AF) R99_UL, GB (25 % AF) HSDPA DL, GB (100% AF)
Contents
Introduction KPI analysis hierarchy Busy Hour problematic Tools Call/Session Setup monitoring & analysis Call/Session Drop monitoring & analysis
Nokia NetAct Tools

Nokia 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
RAS06 Reporting Suite

Contains ready made reports for analysing network performance. Most of the reports are based on collected PM data and Nokia-defined KPIs. Some reports also include radio network parameters and alarm information User can also create own customized report with own KPI definitions for Reporting Suite.
RAS06 Reporting Suite- system program
13
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:
RNC monitoring (clear codes) in RAS06 !
Call & Call attempt sent or received SMS, PDP context event etc.
Updates counters and present the traffic in realtime 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. Soc Classification level
18 Nokia Siemens Networks Presentation / Author / Date
Subscriber and Equipment Trace

Subscriber and Equipment Trace Provide detailed radio interface data from GSM, GPRS/PaCo and 3G networks. Call can be traced by using subscriber's IMSI, MSISDN or equipments 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 Nokia elements and viewed by TraceViewer
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.
Contents
Introduction Call/Session Setup monitoring & analysis RRC setup RAB setup PS setup HSDPA setup/HSUPA setup Call/Session Drop monitoring & analysis RRC/RAB/SHO active HSDPA active/SCC/HSUPA active ISHO
Call Setup Phases

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

Success
RRC Connection Setup & Access and Active

UE BTS RNC CN
RRC: RRC connection Request RRC SETUP phase RRC Setup time (Resource Reservation in RNC, BTS, Transport) RRC: RRC connection Setup RRC ACCESS phase (RNC waits for Reply from UE) RRC: RRC connection Setup Complete RRC ACTIVE phase RRC: Initial Direct Transfer RANAP: Initial UE Message UE-CN Signalling (E.g. RAB Establishment and Release) RANAP: Iu Release Command RRC: RRC connection Release RRC: RRC connection Release Complete Release RRC resources in RNC, BTS, Transport
RRC SETUP fails if some of the needed resources (RNC, BTS, AIR, Transport) are not available. When an RRC setup failure occurs the RNC sends an RRC: RRC CONNECTION REJECT message to UE RRC ACCESS fails if the UE does not reply to RRC: RRC CONNECTION SETUP message with the RRC: RRC CONNECTION SETUP COMPLETE message in given time, if the BTS reports a radio link synchronisation failure or in an RNC internal failure occurs
RRC ACTIVE fails when an interface related (Iu, Iur , Iub, or Radio) or RNC internal failure occurs, and the failure causes the release of the RRC Connection. When an RRC active failure occurs, the RRC send a RANAP: IU RELEASE REQUEST to all involved CNs and waits for RANAP: IU RELEASE COMMAND message (s)
RRC ACTIVE release cause can be either ISHO, IFHO, SRSN relocation or pre-emption
RAB Setup & Access and Active

UE BTS
RAB Access failures are not so Common
RNC
CN
RRC Connection Active Phase, UE-CN Signalling RANAP: RAB Assignment Request
RAB SETUP fails if some of the needed resources (RNC, BTS, AIR, Transport) are not available. When an RAB setup failure occurs the RNC sends a RANAP: RAB ASSINGMENT RESPONSE message to the CN with an appropriate failure cause RAB ACCESS fails if the UE replies with an RRC: RADIO BEARER SETUP FAILURE message or the connection cannot be established in a give time. When a RAB access failure occurs, the RNC sends a RANAP: RAB ASSINGMENT RESPONSE message to the CN with an appropriate failure cause. Immediately after this, the RNC sends also a RANAP: IU RELEASE REQUEST to the CN and waits for RANAP: IU RELEASE COMMAND message
RAB SETUP phase

RAB Setup time RAB Holding Time (Resource Reservation in RNC, BTS, Transport) RRC: Radio Bearer Setup RAB ACCESS phase (RNC waits for Reply from UE) RRC: RB Setup Complete RANAP: RAB Assignment Response
RAB ACTIVE phase
(User Plane Data Transfer)

RANAP: RAB Assignment Request with IE: RAB reconfiguration RAB Reconfiguration Actions
RAB ACTIVE fails when an interface related (Iu, Iur, Iub, or Radio) or RNC internal failure occurs, and the failure causes the release of the RAB connection. If the UE has more than one RAB connection and the failure is not so critical that it would lease to an RRC Connection drop, only the failed RAB connection is released. The RNC sends a RANAP: RAB RELEASE REQUEST message to the CN and waits for a RANAP: RAB RELEASE COMMAND or RANAP: IU RELASE COMMAND from CN Otherwise, both the RRC connection and RAB connection (s) are released. The RNC send a RANAP: IU RELASE REQUEST message to the CN and waits for a RANAP: IU RELEASE COMMAND MESSAGE from the CN
(Reconfigure RAB resources in RNC, BTS, Transport) RRC: RB Reconfiguration

RRC: RB Reconfiguration Complete RANAP: RAB Assignment Response RANAP: RAB Assignment Request with IE: RAB Release RRC: Radio Bearer Release RRC: Radio Bearer Release Complete RANAP: RAB Assignment Response Release RAB resources in RNC, BTS, Transmission
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,
4. Prioritize analysis Filter using high number of failures or high number failure ratio (weighting) Identify top 50 worst cells 5. Analyze failure distribution in the network topology (rural, RNC border, expressway) 6. Propose Solution for cells having network KPIs below KPI targets
RNC) Identify main cause of underperforming KPIs
High level PM data analysis and assessment

Using Reporting Suite 3G RAN Reports or MS Access KPI Queries
System Program (PLMN) Weekly KPI ( PLMN) <X%
No
No action needed System Program (RNC)
Yes
Weekly KPI No (RNC) <X%?
Mapinfo Matching failure distribution into network topology
Solution Proposal
Yes
System Program (WCEL) Daily KPI (WCEL) < X%
Others 3G RAN Reports Identify Top50 Worst Cells based on highest number of root causes failures Others 3G RAN Reports Identify failures root-causes and failure distribution of bad KPIs
Yes
System Program (WCEL) Identify Call failure phases of bad performing KPIs, for example CSSR
Call Setup Failure Analysis

RRC/RAB Setup & Access Analysis Process Flow Chart
Top (N) RRC Setup and Access failures Cell and Neighbour Cells availability Alarms/Tickets Setup Failure Cause?
RNC BTS/TRANS/FROZBS
Top (N) RAB Setup/Access or PS Setup failures
Sites OK ? Yes Setup /Access setup
setup Troubleshooting
UL/DL Interference (DL codes)
Setup /Access
AC
Access
Capacity Optimisation Access Yes SRNS Relocation troubleshooting 3G cell at interRNC border ? NO
Interference RF Optimisation Coverage

Coverage/I nterference
Starting criteria for setup failure analysis

RRC or RAB setup failures could be due issues related to Coverage or interference Inter RNC problem Capacity Configuration & SW issues 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_ACC_FAIL_RNC RAB_ACC_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 Connection & Access Analysis

RRC_CONN_STP_FAIL_AC (dominant) 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 (PrxTarget-> 30 dB) M1002C1 CH_REQ_LINK_REJ_UL_SRNC ----> Evaluate Prx Resource Problem M1002C2 CH_REQ_LINK_REJ_DL_SRNC ----->Evaluate Ptx Resource Problem RRC_CONN_STP_FAIL_BTS (dominant when HSDPA active) Check BTS configuration in terms of WAM and CE allocation Use Channel Element (5001) Counters in order to evaluate lack of Channel Elements Evaluate NBAP counters (radio link reconfiguration failures) and KPIs for troubleshooting BTS resources 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 Multiplexing 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) DMPG problem in RNC 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
RRC Access Failure reasons
L1 Synchronisation
NBAP: Synchronisation Indication RRC: RRC ConnectionSetup Complete (DCH)
UE
BTS
X X
RNC
RRC Access Failures for L1 synchronization
Cell Reselections (no error)
RRC Access Failures due to MS L1 Synchronisation

NBAP: Synchronisation Indication RRC: RRC ConnectionSetup Complete (DCH)
UE
BTS
RNC
RRC Access Failure reasons

RRC_CONN_ACC_FAIL_RADIO (Dominant failure cause type) Perform drive test to detect if UL or DL coverage 1. UL Coverage Tune Cell Dominance if the cause is UL interference 2. 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)
This parameter defines the maximum number of "in sync" indications received
from L1 during the establishment of a physical channel (UE counter used in idle mode).
tune CPICHToRefRABOffset vs.Qqualmin (or Qrxlevmin)

RRC_CONN_ACC_FAIL_MS 1. UL Coverage Tune Cell Dominance (or CPICH) in order to balance UL and DL (if UL
interference if not the cause)

If RRC setup/access failure due to Radio/MS, it is also possible to check whether UEs are located at distance area or close to cell edge area RAS08 Propagation delay counters from RRC measurement M1006C128-C148 reports call setup distance during RRC connection request or cell update This give hints that either cells has large coverage area (tall sites with over-shooting) or non-optimum cell coverage from neighbouring cells
600000 120.00% 500000 100.00%
400000
80.00%
300000
60.00%
average CDF
200000
40.00%
100000
20.00%
0
PR AC PR H_D AC EL A PR H_D Y_ AC EL CL A A PR H_D Y_ SS AC EL CL _0 A A PR H_D Y_ SS AC EL CL _1 A A PR H_D Y_ SS AC EL CL _2 A A PR H_D Y_ SS AC EL CL _3 A A PR H_D Y_ SS AC EL CL _4 A A PR H_D Y_ SS AC EL CL _5 A A PR H_D Y_ SS AC EL CL _6 PR H_ AY AS AC DE _C S_7 L L PR H_D AY AS AC EL _C S_8 L A PR H_D Y_ AS AC EL CL S_9 A A PR H_D Y_ SS AC EL CL _10 A A PR H_D Y_ SS AC EL CL _11 A A PR H_D Y_ SS AC EL CL _12 A A PR H_D Y_ SS AC EL CL _13 A A PR H_D Y_ SS AC EL CL _14 A A PR H_D Y_ SS AC EL CL _15 A A PR H_D Y_ SS AC EL CL _16 A A PR H_D Y_ SS AC EL CL _17 H_ AY AS DE _C S_ LA LA 18 Y_ SS CL _1 AS 9 S_ 20
0.00%
RRC Setup Failures

Admission Control and BTS are the dominant failure reasons here
BT S
RRC Setup Failure Distribution Example - RAS51

10% % 2% 2%0%
Exampl e RAS51
50% 45%
HC AC BTS TRANS RNC FROBTS RNTI Allo IUB AAL2 TRANS
RRC Access Failures

Radio Interface Synchronisation is dominant failure reason here
Example RAS51
Setup and Access Complete ratio is ~99.5 %
Contents
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 A TRA NRT
C
NS
Example RAS51
RAB Setup Complete success ratio is close to ~100 Soc Classification level % 37 Nokia Siemens Networks Presentation / Author / Date
RAB setup & Access Fail 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
RAB setup & Access Fail Root Cause Analysis

RAB_STP_FAIL_XXX_TRANS
Evaluate Number of reconfiguration failure due the transmission Check M1005C128 CANC_ADD_SRNC_TRAN_STP_FAIL (The number of cancelled
synchronised radio link reconfigurations on SRNC side due to a transmission setup failure or RNC DMPG/DSP resource allocation failure) 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 , rec. 500ms)
RAB_ACC_FAIL_XXX_RNC
Typically RNC fault or Incoming SRNC Relocation Failure (inter-RNC border) Need of ICSU log tracing if no reason
Contents
RAS06 Packet Call Counters

Separate Packet call counters could be used in UL/DL to see the accessibility/retainability 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 RN SGSN C RANAP: RAB Assignment Request AC to check to accept or reject RAB Assignment Request [DCH] RRC: Radio Bearer Setup [DCH] RRC: Radio Bearer Setup Complete RANAP: RAB Assignment Response: Success [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 NBAP: RL Reconfiguration Prepare NBAP: RL Reconfiguration Failure
If RNC receives RRC: Measurement Report indicating event 4a when UE has been allocated DCH0/0 or in cell_PCH state RNC receives Cell Update indicating need for dedicated channel (i.e. cause UPLINK DATA TRANSMISSION), following counter is incremented: M1022C0 PS_SESSION_REQ_UL If the network wants to initiate any downlink activity and the UE is in Cell_PCH state, it needs to make a paging request. Counter M1022C1 PS_SESSION_REQ_DL is incremented when RNC receives RRC: CELL UPDATE message with the cause PAGING RESPONSE In case of inter RNC HHO or SRNC relocation counter M1022C2 PS_SESSION_REQ_OTHER is incremented when RANAP: RELOCATION REQUEST message request is received Note: PS ISHO do not use relocation signaling as it is a normal PS call setup where the resources are reserved by UL/DL capacity request NOTE: These counters are NOT incremented when resources (DMPG) are re-allocated due to: Direct switching from DCH xx/yy to HS-DSCH/E-DCH or HSDSCH/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 type
PS Call Counter failure -AC

Resource reservation happens during PS user plane allocation. If user plane allocation is rejected by the admission control. RAS06 new PS call counters M1022C9 Packet Call Setup Fail due
to AC for Interactive M1022C10 Packet Call Setup Fail due to AC for Background
UE Node B RNC SGSN
RANAP: RAB Assignment Request AC to check to accept or reject RAB Assignment Request [DCH] RRC: Radio Bearer Setup [DCH] RRC: Radio Bearer Setup Complete RANAP: RAB Assignment Response: Success [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
are updated
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.
RAS06 PS setup fail comparison with RAS5.1 PS RAB setup, RNC level
0.060
0.050
0.040
0.030
0.020
0.010
RNC_376a RAB setup failures for PS caused by the AC RNC_378a RAB setup failures for PS caused by transmission RNC_379a RAB setup failures for PS caused by RNC's internal reasons 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 PS_SETUP_FAIL_AC_p PS_SETUP_FAIL_BTS_p PS_SETUP_FAIL_BTS_p PS_SETUP_FAIL_DMCU_p PS_SETUP_FAIL_DMCU_p PS_SETUP_FAIL_TRANS_p PS_SETUP_FAIL_TRANS_p PS_SETUP_FAIL_UE_p PS_SETUP_FAIL_UE_p PS_SETUP_FAIL_OTHER_p PS_SETUP_FAIL_OTHER_p
0.000
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
3.
3.
3.
3.
4.
4.
4.
4.
.0
.0
.0
.0
.0
.0
.0
.0
08
15
22
29
05
12
19
26
03
.0
5.
20
08
RAS06 PS setup fail comparison with RAS5.1HSDPA setup, RNC level

0.180 RNC_661a HSDPA Access failures due to UL DCH RNC_663a HSDPA Access failures due to RNC RNC_665a HSDPA Access failures due to Iub 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 MultiRAB RNC_673a HSDPA Access failures due to BTS PS_SETUP_FAIL_AC_p PS_SETUP_FAIL_AC_p PS_SETUP_FAIL_BTS_p PS_SETUP_FAIL_BTS_p PS_SETUP_FAIL_DMCU_p PS_SETUP_FAIL_DMCU_p PS_SETUP_FAIL_TRANS_p PS_SETUP_FAIL_TRANS_p PS_SETUP_FAIL_UE_p PS_SETUP_FAIL_UE_p PS_SETUP_FAIL_OTHER_p PS_SETUP_FAIL_OTHER_p 0.160
0.140
0.100
0.080
0.060
0.040
0.020
0.000
08
08
08
08
08
08
08
08
3. 20
3. 20
3. 20
3. 20
4. 20
4. 20
4. 20
4. 20
.0
.0
.0
.0
.0
.0
.0
.0
08
15
22
29
05
12
19
26
03
.0
5. 20
08
PS attempts Not possible to allocate HSDPA, cell level hourly data

2500 120.00%
100.00% 2000
80.00% 1500
PS_ATT_all 60.00% PS_ATT_HSDSCH/All PS attempts HS_D_REQ_D_D_ALLO_BGR/PS_ATT_HSDS CH_DCH_BGR 40.00%
1000
500 20.00%
More DCH allocations due to lack of HSDPA capacity
0 1 23 45 67 89 111 133 155 177 199 221 243 265 287 309 331 353 375 397 419 441 463
0.00%
Contents
Introduction Call/Session Setup monitoring & analysis RRC setup RAB setup PS setup HSDPA/HSUPA setup Call/Session Drop monitoring & analysis RRC/RAB/SHO active HSDPA/SCC/HSUPA active ISHO
HSDPA Accessibility failure analysis

HSDPA enabling takes fixed 32 CE from WSPC in Node B, additional CE
usage is related to UL R99 return channel depending on the bitrate of it
HSDPA Accessibility User Point of View Ratio
RNC_605a< X % No No action needed
Top X cells
Yes No Setup Fail BTS Yes Check CE resource usage at BH Setup Fail UL No return Channel Yes No Setup Fail Iub Transport Yes Setup Fail UE Yes No Setup Fail RNC internal Yes No
Setup Fail Too Many Users Yes
Check UL power congestion BH
Check AAL2 Iub resource congestion at BH
Check RB reconfiguration Failure rate
Check RNC Unit load (DMPG) and faulty alarms
Check number of simultaneous HSDPA users
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 Rejected HS-DSCH return channel due to lack of radio (lack of power resource) Monitor UL load Increase PrxTarget Check RB reconfiguration failure rate ICSU log for UE types troubleshooting ?
3. If high HSDPA Access Failure_UL DCH (RNC_662a)
4. If high HSDPA Access Failure_UE

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

6. REJ_HS_DSCH_RET and PS_REL_OTH_FAIL_HS_D In RAS06 UL AC could be based on both throughput and power based PS call algorithm depending on the parameter settings. PrxLoadMarginMaxDCH parameter defines interference margin for the maximum UL DCH load. Using default value of 2dB (37% load) can cause HSDPA UL return channel rejections due AC to increase. It is recommended to remove impact of this parameter by setting it to value 0 dB (throughput based AC algorithm not in use). This parameter is valid for all R99 PS bearers, not only for HSDPA UL return channel.
HSUPA Accessibility Analysis

HSUPA Accessibility KPI is measured with RNC_913a
Low HSUPA accessibility Yes Too many HSUPA users reached No UL DCH selected due BTS HW No HSUPA fail due Not Acceptable Active Set No HSUPA Setup fail BTS No HSUPA Setup Fail UE No HSUPA Setup Fail TRANS No Yes Check RB reconfiguration failure rate (Terminal problem) Check AAL2 connections (CID) or signalling problems Go for troubleshooting (ICSU logs etc) E.g. RNC internal failures Yes Check BH Channel element resource usage UL/DL Yes HSUPA is not supported in SHO branch Yes Check BH Channel element resource usage UL/DL (BTS in state that no capacity available for EDCH) Yes Check Number of simultaneous HSUPA users (20/cell, 24/NodeB ) No No Action Needed
Yes
HSUPA Setup fail Other
Yes
HSUPA Accessibility
If HSDPA setup is failing also HSUPA setup will fail, but it could be also that
only HSUPA will fail. The reasons are similar to HSDPA
RNC_956a E-DCH Setup FR due to BTS RNC_1105a E-DCH Setup FR due to Transport RNC_1106a E-DCH Setup FR due to UE RNC_1104a E-DCH Setup FR due to Other Failures
Also there could be too many HSUPA users (20/cell, 24/NodeB)

RNC_968a UL DCH Selected due to too many HSUPA users RNC_969a DL DCH Selected due to the HSDPA power ?? RNC_957a E-DCH Not Selected due the BTS HW
For static resource allocation the power could limit

M1002C521 DL_DCH_SEL_HSDPA_POWER_INT M1002C522 DL_DCH_SEL_HSDPA_POWER_BGR
EDCH cannot be allocated in case HSUPA is not supported in SHO branch

M1002C519 EDCH_ALLO_CANC_NA_AS_INT M1002C520 EDCH_ALLO_CANC_NA_AS_BGR
Contents
Introduction Call/Session Setup monitoring & analysis RRC setup RAB setup PS setup HSDPA/HSUPA setup Call/Session Drop monitoring & analysis RRC/RAB/SHO active HSDPA active/SCC/HSUPA Active ISHO
Call Drop analysis

Top (N) drops Neighbours Performance (use SHO success per adjs counters to identify badly performing neighbours) & Map Site OK ? Traffic Cell and its Neighbour Cells availability Alarms/Tickets
YES
Audit adjacent sites for alarms, Availability, configuration and capacity

NO
Configuration & Parameter audit
Conf OK ?
YES 3G Cell at RNC border? YES Iur performance
Investigation Iur
SHO
SHO Success Rate < 90%?

NO
YES
New site ? NO
ISHO
ISHO Failures
Analyse last detailed radio measurements
RF and IFHO neighbour optimisation
YES Top issu es 3G cell at interRNC border ?
3G cell covers over a coverage hole ?
No cell found ratio >40 %

2G Cell Doctor NO
YES
RF and ISHO neighbour optimisation
2G Investigation : TCH blocking or TCH seizure failure (interference)

YES
ISHO Success Rate < 90%
No cell found ratio > 90 % and enough ADJG
Wrong reference clock (10MHz tuning)
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 Soc Classification level Nokia Check RRC Drop ISHO RT / NRT 57 Siemens Networks Presentation / Author / Date
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 (rec.10s) 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)
RAB Active Phase Failure

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 _ ACT _ COMP _ CS _ VOICE RAB _ ACT _ REL _ CS _ VOICE _ P _ EMP 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
RAB _ ACT _ FAIL_ CS _ VOICE

all _ failures
RAB Drop ratio can per RAB type or RAB drop rate containing all RABs
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_interface_c ms_c ms_c

radio_link_failure_c no_resp_from_rlc_c physical_ch_reconf_fail_c radio_conn_lost_c
radio_conn_lost_c default_c timer_expired_c timer_expired_c
Active_Fail_Radio Active_Fail_Radio Active_Fail_UE Active_Fail_UE
Packet call analysis

Release due to RL Failure counters:
Packet call Failures are divided into RL fail Pre_emption Other
M1022C57 PS_REL_RL_FAIL_HS_E_INT M1022C58 PS_REL_RL_FAIL_HS_E_BGR M1022C59 PS_REL_RL_FAIL_HS_D_INT M1022C60 PS_REL_RL_FAIL_HS_D_BGR 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:

M1022C51 PS_REL_PRE_EMP_HS_E_INT M1022C52 PS_REL_PRE_EMP_HS_E_BGR M1022C53 PS_REL_PRE_EMP_HS_D_INT M1022C54 PS_REL_PRE_EMP_HS_D_BGR M1022C55 PS_REL_PRE_EMP_D_D_INT 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
M1022C65 PS_REL_OTH_FAIL_HS_D_INT M1022C66 PS_REL_OTH_FAIL_HS_D_BGR M1022C67 PS_REL_OTH_FAIL_D_D_INT M1022C68 PS_REL_OTH_FAIL_D_D_BGR are incremented in case the PS allocation is released due to any other reason expect normal, pre-emption or RL failure
RAS06 Packet call failure example

6.00% 5.00%
failure % formula= fail type/normal release
4.00% PS_REL_OTH_FAIL_D_D_BGR % PS_REL_OTH_FAIL_HS_D_BGR % PS_REL_PRE_EMP_D_D_BGR % PS_REL_PRE_EMP_HS_D_BGR % PS_REL_RL_FAIL_D_D_BGR % PS_REL_RL_FAIL_HS_D_BGR %
3.00%
2.00%
1.00%
0.00% 4.4.2008 5.4.2008 6.4.2008 7.4.2008 8.4.2008 9.4.2008
CS RAB drop cause distribution (Ras05)

Top 4 failure causes have been noticed in the networks Radio Link Failure UL and DL Coverage -> UL Lost Active KPI No Response from RLC mainly DL Coverage -> Unsucc ASU KPI ISHO - Physical Channel Reconfiguration fail Delay in ISHO ->RRC Drop ISHO RT KPI Radio Connection lost Failure during Physical CH Reconfiguration procedure -> Phy ch Reconf Succ Rate KPI
All above causes are mapped in Radio Failure Counters table show mapping between failure source and service level counters
OUT FAIL SOURCEFailure counter radio_interface_c RADIO ms_c RADIO transmissio_c RNC rnc_internal_c RNC iur_c IUR bts_c BTS Iu_c IU
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 failure Compare Cell Level KPI to RNC Level KPI
UL _ LOST _ ACT DEL _ SHO _ SRNC _ ACT _ RL _ SYN _ FAIL RL _ BRANCH _ ADD _ SUCC _ SHO _ SRNC NUMBER OF ACTIVE RL _ SETUP _ SUCC _ FOR _ FIRST _ RL RADIO LINKS IN THE IUB RL _ SETUP _ SUCC _ FOR _ SHO _ RL
NUMBER OF RADIO LINK DELETION FOR ACTIVE SYN FAILURE
Downlink radio link failure results in an UL synchronization loss since the UE stops transmitting.
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 T313, rec. 3s->8s (The radio link failure timer (MS timer). N313, rec 20 (4)-> 50 (5) (The maximum number of successive out of sync'
indications received from L1 while T313 is being activated )
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
UL_LOST_ACTIVE
UL_LOST_ACTIVE
RNC-CITTA
CELL_ID
RNC_ID
RNC-CITTA
RNC_ID
RNC2 average: 10%
DAY
NE-RNC-2 NE-RNC-2 NE-RNC-2 NE-RNC-2 NE-RNC-2
62272 62272 62272 62272 62272
MILANO1 MILANO1 MILANO1 MILANO1 MILANO1
20050117 770 20050118 606 20050119 669 20050120 777 20050121 1215
401 363 493 460 672
206 241 161 166 265
295 267 308 357 464
21.4% 22.1% 23.3% 25.4% 21.6%
NE-RNC-2 NE-RNC-2 NE-RNC-2 NE-RNC-2
MILANO1 MILANO1 MILANO1 MILANO1
20050117 20050118 20050119 20050120
DAY
10.0% 10.3% 10.1% 9.8%
PS RAB drop cause distribution

Top 4 failure causes have been noticed in the networks Radio Link Failure UL and DL Coverage -> UL Lost Active KPI These two are No Response from RLC Common for RT mainly DL Coverage -> Unsucc ASU KPI also ISHO Iu Radio Link Failure Delay in ISHO ->RRC Drop ISHO NRT KPI Radio Connection lost Failure during RAB Reconf procedure -> RAB Reconf Success Rate KPI
OUT FAIL SOURCEFailure counter radio_interface_c RADIO ms_c RADIO transmissio_c RNC rnc_internal_c RNC iur_c IUR bts_c BTS Iu_c IU
All above causes are mapped in Radio Failure Counters table show mapping between failure source and service level counters
Radio Connection Lost- RAB Reconfiguration fail

RAB Reconfiguration Success Rate KPI is ~2% lower than at RNC level
RB_RECONF_SUCCESS_RATE
RB_RECONF
RNC-CITTA
100 *
CELL
DAY
62542 62542 62542 62542 62542
20050117 20050118 20050119 20050120 20050121
284 1619 2169 1857 1168
283 1570 2102 1787 1132
99.6% 97.0% 96.9% 96.2% 96.9%
20050117 20050118 20050119 20050120 20050121
128890 138597 142997 136753 118625
RB_RECONF
RB_RECONF_ COMPLETE % RB_RECONF
RB_RECONF_COMPLETE
127617 137227 141604 135481 117340
99.0% 99.0% 99.0% 99.1% 98.9%
The cell has other kind of radio failures Drop voice is 3%

dB
AVG_PRX_TOTAL
-80 -85 -90 -95 -100 -105 -110
2005011700 2005011707 2005011715 2005011722 2005011805 2005011812 2005011820 2005011903 2005011910 2005011917 2005012001 2005012008 2005012015 2005012022 2005012105 2005012112 2005012119
AVG_PRX_PWR
STOP WCELL ID 62542 62542 62542
OUT FAIL SOURCE radio_interface_c ms_c radio_interface_c
OUT REASON radio_link_failure_c radio_conn_lost_c no_resp_from_rlc_c
Percentage
2.5% 1.2% 0.1%
RB_RECONF_SUCCESS_RATE
RB_RECONF_COMPLETE
CELL level
RNC level
DAY
SHO Overhead
Check SHO Overhead to see how big is SHO area, if it is too small SHO may fails and if too big capacity is wasted
100 * ( sum((ONE _ CELL _ IN _ ACT _ SET _ FOR _ RT ONE _ CELL _ IN _ ACT _ SET _ FOR _ NRT ) *1 (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) 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 THREE _ CELLS _ IN _ ACT _ SET _ FOR _ RT THREE _ CELL _ IN _ ACT _ SET _ FOR _ NRT ) 1)
SHO success (RNC_195a)

SHO _ Success _ ratio 100 * sum( SUCC _ UPDATES_ ON _ SHO _ FOR _ RT SUCC _ UPDATES_ ON _ SHO _ FOR _ NRT ) 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
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)
SHO _ success _ per _ ADJS _ RNC _ 900 a 100 * sum( SHO _ ADJ _ INTRA _ FREQ _ SHO _ COMPL ) sum( SHO _ ADJ _ INTRA _ FREQ _ SHO _ ATT )
IFHO Success per Adjacency (M1014 AutoDef IFHO)

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

ISHO _ success _ per _ ADJG _ RNC _ 902 a 100 * sum( HO _ ADJ _ INTER _ SYS _ HHO _ COMPL ) sum( HO _ ADJ _ INTER _ SYS _ HHO _ ATT )
RAS06 new SHO counters

It is possible to see the ASU performance with RAS06 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
RAS06 Active Set Add/Del success- example, RNC

0.9999 0.04%
0.9998 0.04% 0.9997 0.03% 0.9996 0.03% 0.9995
Some failures due to no reply to ASU
0.9994
0.02%
AS_UPDATE_RL_ADD_SUCC % AS_UPDATE_RL_DEL_SUCC % AS_UPDATE_RL_ADD_FAIL_UE % AS_UPDATE_RL_ADD_NOREPLY %
0.9993 0.02% 0.9992 0.01% 0.9991 0.01% 0.999
0.9989
3. 2 6. 008 3. 2 7. 008 3. 2 8. 008 3. 2 9. 008 3. 2 10 00 .3 8 . 11 200 .3 8 . 12 200 .3 8 . 13 200 .3 8 . 14 200 .3 8 . 15 200 .3 8 . 16 200 .3 8 . 17 200 .3 8 . 18 200 .3 8 . 19 200 .3 8 . 20 200 .3 8 . 21 200 .3 8 . 22 200 .3 8 . 23 200 .3 8 . 24 200 .3 8 . 25 200 .3 8 .2 00 8
0.00%
5.
RAS06 Active Set Add FAIL_UE/NO REPPLYexample (wcel level, 13.03.2008)

25000 30
25 20000
20 15000 AS_UPDATE_RL_ADD_ATT AS_UPDATE_RL_DEL_ATT AS_UPDATE_RL_ADD_FAIL_UE AS_UPDATE_RL_ADD_NOREPLY
15
10000 10
5000 5
0 1 18 35 52 69 86 103 120 137 154 171 188 205 222 239 256 273 290 307 324 341 358 375 392 409
Contents
Introduction Call/Session Setup monitoring & analysis RRC setup RAB setup PS setup HSDPA/HSUPA setup Call/Session Drop monitoring & analysis RRC/RAB/SHO active HSDPA active/SCC/HSUPA active ISHO
HSDPA Retainability Failure Cause Analysis
HSDPA Retainability for NRT Traffic

RNC_609a < X % No No action needed
Top N cells
Yes No HS_DSCH_ PRE_EMP Yes HS_DSCH_ MOB_DCH Yes Normal Release (No action needed) No HS_DSCH_ OTH_DCH Yes No RL_FAIL_ HS_DSCH Yes
No
OTH_FAIL_ HS_DSCH Yes
Normal Release (No action needed)
Normal Release (No action needed)
Check SCC Failure Rate Radio, Iub, CE resource congestion No Check CQI distribution and Ecno distribution No for coverage issue
Check RB reconfiguration failure rate UE responsed with failure or no response at all
Check HSDPA mobility parameter Add/Drop window, SCC parameter
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, CPICH EcNo class 0-9) 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 ?
HSUPA Retainability analysis

The retainability of all successfully allocated E-DCH resources for NRT
traffic is measured with KPI RNC_919a There are several reasons for HSUPA release:
RNC_1108a E-DCH Rel due to RL Failures RNC_1109a E-DCH Rel due to Other Failures
RL fail is incremented If:

a radio link failure happens during HSDPA call uplink RLC unrecoverable error happens (Cell Update by UE) RLC-entity in RNC reports RLC protocol reset
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
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
HSDPA SCC Analysis
HSDPA SCC Success Rate

RNC_733a < X % No No action needed
Top N cells
Yes No SCC Fail BTS SCC Fail AC Yes No No SCC Fail Transmission Yes SCC Fail UE Yes No SCC Fail Others Yes No SCC Fail Prevention timer Ye s Check HSDPACellCha ngeMinInterval parameter
Yes Check CE resource usage at BH
DL power congestion BH ? No
Check AAL2 Iub resource congestion at BH
Check RB reconfiguration Failure rate
Check RNC internal transport resources (DMPG) ICSU troubleshooting
code tree No congestion BH
Check Maximum number of HSDPA users
HSDPA SCC analysis

1. Determine SCC success rate, SCC failure rate and failure cause distribution
2.
3.
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 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
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 HSDSCH 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 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 Check RNC internal transport resources usage (DMPG) Require ICSU troubleshooting
6. If high SCC_FAILED_due_to_TRANS
7. If high SCC_FAILED_due_to_Others
HSDPA Throughput Analysis

START OSS counters measurement data collection
Identify Low throughput areas if exist
NO
If throughput is low in network level, the reason can be also FTP/HTTP server settings (fire wall), Measurement tools etc.
YE S YE S Low throughput due to low Ec/No or CQI
No Optimisation Required
NO
Identify reason for low throughput if not RF If low throughput due to low Ec/No or Poor CQI, identify reason Bad Coverage Planning Quality issue due the neighbour planning Mobility (cell change too frequent) No HSDPA coverage Iub User Plane Capacity Other HSDPA users in same WBTS/Cell DCH traffic too High (DPA, HSDPA Priority) Optimise RF Add missing neighbours Change Antenna tilt etc. Start Parameter Optimisation by tuning HSPDA Mobility parameters PtxMaxHSDPA power & HSDPA Priority (when dynamic resource allocation not used) Iub Parameters (SHAA, SHFCA) when dynamic HSDPA transport scheduling not used Implement Changes
Optional Features like Proportional Fair HSDPA Mobility
16QAM Modulation
has impact for the throughput
HSDPA Throughput analysis

1. Check nodeB HSDPA Throughput (RNC_722a Active HS-DSCH MAC-d
throughput) 2. Check HSDPA user throughput by dividing RNC_722a with average number of simultaneous HSDPA users (RNC_645a or RNC_726a) 3. Check CQI distribution (M5000C8-M5000C39) or Ecno distribution for bad coverage issue (M1007C38-M1007C47) 4. High CQI / Ecno but low HSDPA user throughput Check problem at core network or application server Check any shortage on Iub user plane or DCH traffic too high Check any incorrect Iub parameter setting Check HSDPA power parameter setting Check HSDPA FMCS mobility parameters
HSUPA Throughput Analysis

Check Mininum, Maximum & Average HSUPA throughput from WBTS
counter measurement (M5000C153) Check CQI distribution (M5000C8-M5000C39) or Ecno distribution for bad coverage issue (M1007C38-M1007C47) Check If low throughput due to high number of retransmission & failed retransmission (RNC_917a HSUPA MAC-es BLER) Check AVG_NON_HSDPA_PWR (M1000C138) & AVG_ACTIVE_NON_HSDPA_PWR to investigate whether high DCH power (DCH traffic) causes low HSUPA throughput Others reasons with low HSUPA throughput Check problem at core network or application server Check HSPA FMCS / SCC mobility related parameters & performance Note: HSUPA throughput measurement is less accurate than HSDPA throughput due to counters updating across total measurement period
Contents
Introduction Call/Session Setup monitoring & analysis RRC setup RAB setup PS setup HSDPA/HSUPA setup Call/Session Drop monitoring & analysis RRC/RAB/SHO active HSDPA active/SCC/HSUPA active ISHO
Inter System Handover 3G -> 2G Tuning

CPICH RSCP (Event 1F) Thresholds: HHoRscpThreshold HHoRscpCancel L3 filter: HHoRscpFilterCoefficient Timers: HHoRscpTimeHysteresis HHoRscpCancelTime UE Tx Power (Event 6A) Threshold: GsmUETxPwrThrXX L3 filter: GsmUETxPwrFilterCoeff Hysteresis margin: GsmUETxPwrTimeHyst Data rate threshold HHOMAxAllowedBitrateUL (XX=AMR,CS,NrtPS,RtPS) 3. Decision Algorithm AdjgTxPwrMaxTCH AdjgRxLevMinHO (n) GsmMeasAveWindow DL DPCH power Threshold: GsmDLTxPwrThrXX Data rate threshold HHOMAxAllowedBitrateDL CPICH Ec/Io (Event 1F) Thresholds: HHoEcNoThreshold HHoEcNoCancel L3 filter: EcNofilterCoefficient Timers: HHoEcNoTimeHysteresis HHoEcNoCancelTime Timer: ULQualDetRepThreshold Data rate threshold HHOMAxAllowedBitrateUL UL Quality
2. GSM measurement reporting GsmMeasRepInterval GsmNcellSearchPeriod GsmMinMeasInterval GsmMaxMeasPeriod
1.
2. 3.
Triggering
GSM measuring Decision
Handover Execution 2G-to-3G back prevention GsmMinHoInterval
ISHO 3G -> 2G - AMR Signaling Flow

U E
RRC: Measurement Report
Node B
RNC
RRC: Measurement Control ISHO triggering (5 reasons are possible) Initial Compressed Mode Configuration
CN
NBAP: Radio Link Reconfiguration Prepare NBAP: Radio Link Reconfiguration

Ready NBAP: Radio Link Reconfiguration RRC: Physical Channel Reconfiguration Complete Commit RRC: Physical Channel Reconfiguration NBAP: Compressed Mode Command RRC: Measurement Control NBAP: Compressed Mode Command RRC: Measurement RRC: Measurement Report Control
GSM RSSI Measurem ent GSM BSIC Identification RANAP: Relocation Required
RRC: Handover from UTRAN Command
RANAP: Relocation Command RANAP: IU Release Command RANAP: IU Release Complete
BSIC verification always performed for AMR calls no interrupt in voice call
Compressed Mode
UE
RRC: Measurement Report (3,4,5)
BTS
RNC
RRC: Measurement Control
Admission Control check for CM

NBAP: Radio Link Reconfiguration Prepare NBAP: Radio Link Reconfiguration Failure
If compressed mode can NOT start (before sending Measurement Control) the following counter is incremented: M1010C2 (M1010C40)IS_COM_MOD_STA_NOT_POS_(N)RT The counters is update if: 1) Admission Control rejects compressed mode request: If Compressed Mode cannot be started due to AC rejecting the request counters: M1002C361 REQ_COM_UL_REJ_SYS_HHO_SRNC or M1002C362 REQ_COM_DL_REJ_SYS_HHO_SRNC 2) ISHO is a parallel procedure (expecially NRT) 3) Compressed mode can not start due to radio link (or physical channel) reconfiguration failure (BTS or UE reasons)
The counters are updated in the BEST cell of the active set
Inter-System measurement parameters

Inter-RAT Measurement control parameters
Periodical measurement reporting interval GsmMeasRepInterval (0.5s) GsmNcellSearchPeriod (0 meas rep) the time period after the starting
IS measurements, during which Ho is not allowed GsmMaxMeasPeriod (20 meas rep) defines the maximum allowed duration of the inter-system measurement GsmMinMeasInterval (2s)defines the minimum time before new measurement procedure/handover attempt will start in case an unsuccessful measurement procedure/previous HO related to same RRC connection GSMMinHoInterval (10s) defines the minimum interval between a succesfull inter-system handover from GSM and the following intersystem handover attempt to the GSM, related to the same RRC connection
GsmMeasAveWindow (6 meas rep)defines how many measurement

reports are taken to one average value done in RNC, sliding window is used
Maximum Measurement Interval

These parameters control the maximum compressed mode duration time for each GSM RSSI and BSIC decoding measurement process. The duration of this interval in seconds is given by:
(12 s) (20) (0.5 s)
max_meas_interval (s) = GsmMaxMeasPeriod x GsmMeasRepInterval + 4 x GsmMeasRepInterval In case of no suitable target cell found (for any reason), CM measurements - both RxLev and BSIC verification - are stopped by RNC if:
RNC does receive GsmMaxMeasPeriod ISHO Measurement Reports (meas id = 3) before the above max_meas_interval time window expires the above max_meas_interval time window expires before receiving GsmMaxMeasPeriod ISHO Measurement Reports (meas id = 3). The ISHO procedure is considered to be unsuccessful and a new one can be activated after GsmMinMeasInterval (2s) provided that meanwhile RNC has not receive a cancellation event. Note that in case the time window expires ISHO counters are not updated at all
ISHO analysis Flow Chart

ISHO Success Rate RT
RNC_300c < X%
Top N cells Yes
No
No action needed
CM Start Not Possible?
No
Low ISHO No Measureme nt success ?
No
Low ISHO Success ?
Yes
Yes Yes Missing ADJG or Bad Neighbour planning ? Missing or wrong 2G parameter in 2G MSC or SGSN (BCCH, LAC, CellID) Half Rate in 2G Ncell ????
Check admission control rejection -> PrxTotal & PtxTotal
Poor GSM Coverage

Wrong 2G Ncell Parameter (BSIC) Or BSIC collision Too low ISHO triggering threshold or Strict ADJG minimum threshold (ADJGRxLevMinHO)
2G Ncell Congestion
Missing neighbour list after reselection after cell change order occured
Non-optimum Compressed mode parameter set

ISHO analysis
1. 2.
Analysis should be performed for each service (i.e. AMR, PS etc.) Breakdown ISHO analysis into three phases: Compressed mode performance Inter-system measurement success Inter-system handover success 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
70
-75
3.
Average_PrxTotal_excl_0
Average_PrxTotal_class_0
AVG_PRX_PWR
60
-80
50
dBm
-85
40 30 20
IS_COM_MOD_STA_NOT_P OS_RT UE_PWR_RT
-90 -95 -100 -105
10 0
20040908 20040909 20040910 20040911 20040912 20040913 20040906 20040907
-110
2004090901 2004090902 2004090903 2004090904 2004090906 2004090907 2004090908 2004090909 2004090912 2004090913 2004090914 2004090915 2004090917 2004090918 2004090919 2004090920 2004090922 2004090923 2004090900 2004090905 2004090910 2004090911 2004090916 2004090921
hour
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 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 May require further troubleshooting with ICSU logging to determine root cause of failure
5.
6.
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 M1010C21 CON_DRPS_IS_HHO_UL_DCH_Q_RT M1010C25 CON_DRPS_IS_HHO_UE_PWR_RT M1010C29 CON_DRPS _IS _HHO_DL_DPCH_RT M1010C33 CON_DRPS _IS _HHO_RSCP_RT
If neither the target BSC has received the HO complete M1010Cxxx message nor the source RNC has received a failure from CON_DRPS_IS_HHO_LSHO_triggers_RT* the mobile, the source RNC sends the IU RELEASE REQUEST message to the CN. For RT: TRelocOverall (def. 8s, from Relocation
AC check for CM
NBAP: Radio Link Reconfiguration Prepare NBAP: Radio Link Reconfiguration Ready NBAP: Radio Link Reconfiguration Commit RRC: Physical Channel Reconfiguration RRC: Physical Channel Reconfiguration Complete RX Level measurement phase for NBAP: Compressed Mode all ISHO neighbours Command RRC: Measurement Control RRC: Measurement Report NBAP: Compressed Mode Command RRC: Measurement Control
M1010C37 CON_DRPS _IS _HHO_ECNO_RT
BSIC verification phase for target cell
Command to Iu Release Command) expires.

RANAP: Relocation Required
RRC: Handover from UTRAN Command

RANAP: Relocation Command RANAP: IU Release Request
RRC Drop during ISHO 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
AC check for CM
NBAP: Radio Link Reconfiguration Prepare NBAP: Radio Link Reconfiguration Ready NBAP: Radio Link Reconfiguration Commit RRC: Physical Channel Reconfiguration RRC: Physical Channel Reconfiguration Complete RX Level measurement phase for NBAP: Compressed Mode all ISHO neighbours Command RRC: Measurement Control RRC: Measurement Report NBAP: Compressed Mode Command RRC: Measurement Control
M1010C21 CON_DRPS_IS_HHO_UL_DCH_Q_NRT M1010C25 CON_DRPS_IS_HHO_UE_PWR_NRT M1010C29 CON_DRPS _IS _HHO_DL_DPCH_NRT M1010C33 CON_DRPS _IS _HHO_RSCP_NRT
M1010C37 If neither theCON_DRPS target BSC has received the HO complete _IS _HHO_ECNO_NRT message nor the source RNC has received a failure from M1010Cxxx the mobile, the source RNC sends the IU RELEASE CON_DRPS_IS_HHO_LSHO_triggers_NRT* REQUEST message to the CN. For NRT: IU release request is sent after 8s from
BSIC verification phase for target cell
sending Cell Change Order.
RRC: Cell Change Order from UTRAN
RANAP: SRNS Context Request RANAP: SRNS Context Response

RANAP: SRNS Data Forward Command RANAP: IU Release
Request
Radio Connection Lost Physical Channel reconf fail

The RAB voice failure due the radio_connection_lost timer_expires are related to physical channel reconfiguration complete not received at CM start The Cells affected by physical channel reconfiguration failure can be identified through the RRC Signalling level Counters
PhyChan _ Re conf _ Succ _ Rate 100 *
PHY_CH_RECONF_COMP
PHY_CH_RECONF
WCEL_ID
period
62951 17-21/01/05 258 230 89.1%

NE-RNC-2 NE-RNC-2 NE-RNC-2 NE-RNC-2 NE-RNC-2
20050117 20050118 20050119 20050120 20050121
9677 10083 11048 10521 11661
9538 9941 10885 10365 11460
98.6% 98.6% 98.5% 98.5% 98.3%
PHY_CH_RECONF_SUCCESS_RATE
PHY_CH_REC ONF_COMP % PHY_CH_REC ONF
PHY_CH_RECONF_COMP
PHY_CH_RECONF
RNC-CITTA
RNC_ID
DAY
Physical Channel Reconfiguration Fail

Physical Channel Reconfiguration fail vs. Establishment Cause Mapping to counter RRC/RAB_ACT_FAIL_UE
Looking at some logs the failure is due to difficult BSIC verification during ISHO procedure and since the failure happens after the Handover from UTRAN commands all relative ISHO counters are incremented In the same area there are some Handover from UTRAN failure messages sent back from the UE with the cause physical channel failure this means that UE had some problems to establish connection with the GSM cell (aggressive GSM frequency reuse) Optimisation of ADJG in the area and if possible 2G frequency plan

RANOP2 Module2 PM Monitoring Analysis RAS06 111008

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

RANOP2 Module2 PM Monitoring Analysis RAS06 111008

Enviado por

Direitos autorais:

Formatos disponíveis

3G RANOP2 RAS06 Module 2 Performance Monitoring & Data Analysis

Soc Classification level 1 Nokia Siemens Networks

Presentation / Author / Date

Module 2 Performance monitoring & data analysis

List possible reasons for failures & improvement activities

Soc Classification level 2 Nokia Siemens Networks

Presentation / Author / Date

Presentation / Author / Date

Performance data hierarchy

Signalling (RRC, Iub, Iu, Iur, Relocation)

Soc Classification level 4 Nokia Siemens Networks

What is cell-specific, what is not

Prioritizing cell with the highest number of failures

Coverage hole, missing neighbour or capacity problem

Larger time periods are preferable, together with a filter an minimum

Cells order by nb of drops

10 worst cells (1% of the area) cause 14% of the drops

Soc Classification level 7 Nokia Siemens Networks

Presentation / Author / Date

Soc Classification level 8 Nokia Siemens Networks

Presentation / Author / Date

Daily, Weekly or Busy Hour ?

Where xxx_DL= SUMi ( Bit_Ratei * Allocation_Durationi)

Soc Classification level 10 Nokia Siemens Networks

Hourly traffic example, RNC level

Presentation / Author / Date

Soc Classification level 11 Nokia Siemens Networks

Presentation / Author / Date

Nokia NetAct Tools

Soc Classification level 12 Nokia Siemens Networks

Presentation / Author / Date

RAS06 Reporting Suite

Soc Classification level 14 Nokia Siemens Networks

Presentation / Author / Date

RAS06 Reporting Suite- system program

Soc Classification level 15 Nokia Siemens Networks

Presentation / Author / Date

Traffica Real-Time Traffic Monitoring and Troubleshooting

RNC monitoring (clear codes) in RAS06 !

Number of events Number of failures Clear Codes etc.

Subscriber and Equipment Trace

Soc Classification level 19 Nokia Siemens Networks

Presentation / Author / Date

Subscriber and Equipment Trace

Presentation / Author / Date

Soc Classification level 21 Nokia Siemens Networks

Presentation / Author / Date

Call Setup Phases

Setup failures (blocking)

Presentation / Author / Date

RRC Connection Setup & Access and Active

RAB Setup & Access and Active

RAB Access failures are not so Common

RAB SETUP phase

RAB ACTIVE phase

(User Plane Data Transfer)

(Reconfigure RAB resources in RNC, BTS, Transport) RRC: RB Reconfiguration

Soc Classification level 24 Nokia Siemens Networks

Presentation / Author / Date

PM Data analysis process

Soc Classification level 25 Nokia Siemens Networks

Presentation / Author / Date

High level PM data analysis and assessment

No action needed System Program (RNC)