RANOP2 Module2 PM Monitoring Analysis RAS06 111008

7/27/2019 RANOP2 Module2 PM Monitoring Analysis RAS06 111008

1/93

Soc Classification level

1 Nokia Siemens Networks Presentation / Author / Date

3G RANOP2 RAS06Module 2 Performance Monitoring & Data

Analysis


2/93



Module 2 Performance monitoring & dataanalysis

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


3/93



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

Contents


4/93



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

PIs and raw counters from RAN

measurement tables are marked blue

More

details

Moreunderstand

ing

More

complexity

More cost

& time inacquisition

KPIs (OCSR, CSSR, CCR)

Service LevelTraffic

SHO

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

PMI Tickets NSRP (internal)

Traffica data

ICSU logs (internal) Interface trace

Cell Resource

IFHO HHO

Subscriber trace

Probe statistics

ISHO


5/93



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 summarizedAlmost all data has to be analysed at WCELL or WBTS level for the worstcells -> Evaluation over time and Comparison between large areas (Cities,RNCs) is still required

Cell Availability

Failures due to Radio, to BTS, to transport Handover Performance

Traffic

Cell Resources

Iub SignallingSome data is better analysed at RNC level->Here only the time evolutionand RNC comparison is useful

Failures due the RNC, Iu, Iur

Iur, Iu, Relocation Signalling

Monitor Cell/Neighbour cells

Availability - missing cell has impactto neighbouring cells performance

also


6/93



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 uniformperformance, in addition with the top number of failures

Larger time periods are preferable, together with a filter an minimumnumber of attempts/failures per cell (depending on network traffic)

Cells order by nb of drops

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 56 111 166 221 276 331 386 441 496 551 606 661 716 771 826 881 936 991 1046 1101

Nb of cells

Cumulativepercentageofdrops

Cells order by nb of drops

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


7/93



Introduction



Tools

Call/Session Setup monitoring & analysisCall/Session Drop monitoring & analysis

Contents


8/93



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 hourand 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 Unloadednetworks the Weekly Busy Hour CSSR may not yield the hour

with highest blocking as NRT traffic is taken in the account as well as RTtraffic

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 toongoing operatios, system failures, sleeping cells, alarms etc.)

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)


9/93



Hourly traffic example, RNC level

0

1

2

3

4

5

6

16/11/20

0700

16/11/20

0701

16/11/20

0702

16/11/20

0703

16/11/20

0704

16/11/20

0705

16/11/20

0706

16/11/20

0707

16/11/20

0708

16/11/20

0709

16/11/20

0710

16/11/20

0711

16/11/20

0712

16/11/20

0713

16/11/20

0714

16/11/20

0715

16/11/20

0716

16/11/20

0717

16/11/20

0718

16/11/20

0719

16/11/20

0720

16/11/20

0721

16/11/20

0722

16/11/20

0723

Voice, GB (AF50%)

R99_DL, GB (25 % AF)

R99_UL, GB (25 % AF)

HSDPA DL, GB (100% AF)


10/93



Introduction



Tools

Call/Session Setup monitoring & analysisCall/Session Drop monitoring & analysis

Contents


11/93



Nokia NetAct Tools

Nokia NetAct contains variety of tools which can be used for Performancemonitoring 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


12/93



RAS06 Reporting Suite

Contains ready made reports for analysing network performance. Most of thereports are based on collected PM data and Nokia-defined KPIs. Some

reports also include radio network parameters and alarm informationUser can also create own customized report with own KPI definitions forReporting Suite.


13/93



RAS06 Reporting Suite- system program

13


14/93



Traffica Real-Time Traffic Monitoring andTroubleshooting

Real-time traffic monitoring and troubleshooting

tool for Multi-vendor networksAnalysis of subscriber behaviour, roaming,mobile types, used services. Receives andstores 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 andCGRs. They can also verify the effect of

changes in the configuration in real-time.

RNC monitoring (clear codes) in RAS06


15/93



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'sIMSI, MSISDN or equipments IMEI number

Subscriber trace can be used for:

In system testing and provisioning phase for trouble shooting and networkoptimisation. E.g. Ascertain cell coverage, network integrity & QoS

Limited multi-vendor support Trace data is collected only from Nokia elements and viewed by

TraceViewer


16/93



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.


17/93



Introduction


RRC setup

RAB setup

PS setup HSDPA setup/HSUPA setup


RRC/RAB/SHO active

HSDPA active/SCC/HSUPA active ISHO

Contents


18/93


19/93



RRC Connection Setup & Access and Active

BTSUE RNC CN

RRC: RRC connection Request

RRC: RRC connection Setup

RRC SETUP phase

(Resource Reservation in RNC, BTS,

Transport)

RRC ACCESS phase

(RNC waits for Reply from UE)

RRC: RRC connection Setup Complete

RRCSetuptim

e

RRC: Initial Direct Transfer

RANAP: Initial UE Message

RANAP: Iu Release Command

UE-CN Signalling

(E.g. RAB Establishment and Release)

RRC: RRC connection Release

RRC: RRC connection Release Complete

Release RRC resources in RNC, BTS,

Transport

RRC ACTIVE phase

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 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 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


20/93



RAB Reconfiguration Actions

(Reconfigure RAB resources in RNC, BTS,Transport)

BTSUE RNC CN

RRC: Radio Bearer Setup

RAB SETUP phase

(Resource Reservation in RNC, BTS,

Transport)

RAB ACCESS phase

(RNC waits for Reply from UE)

RRC: RB Setup Complete

RABSetuptime

RRC: RB Reconfiguration

RANAP: RAB Assignment Response


Release RAB resources in RNC, BTS,

Transmission

RRC Connection Active Phase, UE-CN Signalling

RANAP: RAB Assignment Request


RAB ACTIVE phase

(User Plane Data Transfer)

RANAP: RAB Assignment Request with IE: RAB reconfiguration

RRC: Radio Bearer Release

RRC: RB Reconfiguration Complete

RANAP: RAB Assignment Request with IE: RAB Release

RRC: Radio Bearer Release Complete

RABHolding

Time

RAB Setup & Access and Active

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 tothe 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: IURELEASE COMMAND message

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

RAB Access failures are not so

Common


21/93



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 performanceassessment as daily performance varies a lot especially in unloaded network

2. Assess network performance at RNC/Area level to check if bad performancehappens 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. Analyze failure distribution in the network topology (rural, RNC border,expressway)

6. Propose Solution for cells having network KPIs below KPI targets


22/93



High level PM data analysis and assessment

Using Reporting Suite 3G RAN Reports or MS Access KPI Queries

Weekly KPI

( PLMN)

< X %

No action

needed

No

Yes

Yes

No

System Program (PLMN)

Weekly KPI

(RNC)

< X % ?

System Program (RNC)

Daily KPI

(WCEL)< X%

Identify Call failure

phases of bad

performing KPIs,

for example

CSSR

Identify failures

root-causes and

failure distribution

of bad KPIs

Identify Top50

Worst Cells based

on highest number

of root causes

failures

System Program (WCEL) Others 3G RAN Reports

Others 3G RAN ReportsYes

Matching failure

distribution into

network topology

System Program (WCEL)

Solution

Proposal

Mapinfo


23/93



Call Setup Failure Analysis

RRC/RAB Setup & Access Analysis Process Flow Chart

Sites OK?

Cell and NeighbourCells availabilityAlarms/Tickets

Setup/Access

Yes

Setup/Access

SetupFailureCause?

CapacityOptimisation

BTS/TRANS/FROZBS

UL/DLInterference(DL codes)

AC

TroubleshootingRNC

RF Optimisation

Top (N) RRC Setupand Access failures

Top (N) RAB Setup/Accessor PS Setup failures

Coverage/Interference

setup

setup

Interference

Coverage

3G cell

at inter-RNC

border ?

SRNS Relocationtroubleshooting

Yes

NO

Access

Access


24/93



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 Iubcapacity issues or AC for radio capacity issues (UL Load, DL Load andDL 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


25/93



RRC Connection & Access Analysis

RRC_CONN_STP_FAIL_AC (dominant)

Check UL Interference, DL Power & Code occupancy if there is need to upgraderadio capacity

UL Power Spikes -> Disable UL Admission Control to if the number of failures iscritical (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 ChannelElement (5001) Counters in order to evaluate lack of Channel Elements

Evaluate NBAP counters (radio link reconfiguration failures) and KPIs fortroubleshooting BTS resources

Expand the Capacity or decrease the traffic offered to the site

In case BTS is not responding delete and re-create COCO


26/93



RRC Connection & Access Analysis

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 siteRRC_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 failurecaused 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


27/93



NBAP: Synchronisation Indication

L1 Synchronisation

RRC: RRC ConnectionSetup Complete (DCH)


L1 Synchronisation

RRC: RRC ConnectionSetup Complete (DCH)X

UE BTS RNC

X

RRC Access Failures for L1 synchronizatio


L1 Synchronisation



L1 Synchronisation


XUE BTS RNC

RRC Access Failures due toMSCell Reselections(no error)

RRC Access Failure reasons


28/93



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 idlemode).

tune CPICHToRefRABOffset vs.Qqualmin (or Qrxlevmin)

RRC_CONN_ACC_FAIL_MS1. UL Coverage

Tune Cell Dominance (or CPICH) in order to balance UL and DL (if ULinterference if not the cause)


29/93

BT


30/93



RRC Setup Failures

RRC Setup Failure Distribution Example - RAS51

0%

50%

45%

2%2%0%0%1%

HC

AC

BTS

TRANS

RNC

FROBTS

RNTI Allo

IUB AAL2 TRANS

S

Admission Control and

BTS are the dominantfailure reasons here

Example

RAS51


31/93



RRC Access Failures

Radio Interface Synchronisation is

dominant failure reason here

Setup and Access Complete ratio is ~99.5 %

Example

RAS51


32/93



Introduction


RRC setup

RAB setup



RRC/RAB/SHO active


Contents


33/93



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 forNRT

RAB Setup Complete success ratio is close to ~100

%

Example

RAS51

A

C

TRA

NS


34/93

RAB & A F il R C A l i


35/93



RAB setup & Access Fail Root Cause AnalysisRAB_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 setupfailure or RNC DMPG/DSP resource allocation failure)

Check RAB_STP_FAIL_XXX_IUB_AAL2, M1001C531-C533

Check COCO Configuration

RAB_ACC_FAIL_XXX_MSEvaluate 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


36/93



Introduction


RRC setup

RAB setup



RRC/RAB/SHO active


Contents

RAS06 P k t C ll C t


37/93



RAS06 Packet Call Counters

Separate Packet call counters could be used in UL/DL to see theaccessibility/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 fromFACH/PCH, DCH 0/0) and ends with dedicated resource release (transferback 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 andabnormal releases

PS RAB U d HSDPA/HSUPA A ti ti


38/93

Soc Classification level42 Nokia Siemens Networks Presentation / Author / Date

PS RAB Upgrade or HSDPA/HSUPA Activation

If RNC receives RRC: Measurement Report indicatingevent 4a when UE has been allocated DCH0/0 or incell_PCH state RNC receives Cell Update indicating needfor dedicated channel (i.e. cause UPLINK DATATRANSMISSION), following counter is incremented:M1022C0 PS_SESSION_REQ_UL

If the network wants to initiate any downlink activity andthe UE is in Cell_PCH state, it needs to make a pagingrequest. Counter M1022C1 PS_SESSION_REQ_DL isincremented when RNC receives RRC: CELL UPDATEmessage with the cause PAGING RESPONSE

NOTE: These counters are NOT incremented whenresources (DMPG) are re-allocated due to: Direct

switching from DCH xx/yy to HS-DSCH/E-DCH or HS-DSCH/DCH

In case of inter RNC HHO or SRNC relocation counterM1022C2 PS_SESSION_REQ_OTHER is incrementedwhen RANAP: RELOCATION REQUEST messagerequest is receivedNote: PS ISHO do not use relocation signaling as it is anormal PS call setup where the resources are reserved byUL/DL capacity request


UE Node B RNC

AC to check to acceptor reject RABAssignment Request

SGSN

[DCH] RRC: Radio Bearer Setup

[DCH] RRC: Radio Bearer Setup Complete

RANAP: RAB Assignment Response:

Success

[DCH] RRC: Measurement Control

Direct Transfer : Activate PDP Context Accept

[DCH] RRC: Measurement Report


NBAP: RL Reconfiguration Prepare

NBAP: RL Reconfiguration Failure

AC to check to acceptor reject Capacity

request

RAS06 P k t C ll f il


39/93


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 mainfailure type

Reguests vs. allocations

It is possible to see whether HSPA was not allocated DL/UL, but DCHinstead (capacity issue)

Separate PS release fail for R99 NRT, HSDPA and HSUPA to see the mainfailure type

PS C ll C t f il AC


40/93



UE Node B RNC

AC to check to acceptor reject RAB

Assignment Request

SGSN

[DCH] RRC: Radio Bearer Setup

[DCH] RRC: Radio Bearer Setup Complete

RANAP: RAB Assignment

Response:Success


Direct Transfer : Activate PDP Context Accept

[DCH] RRC: Measurement Report


AC to check to acceptor reject Capacity

request

Note: These counters are only incremented in case of initial allocation forterminal has been Cell_FACH (Cell_PCH) or DCH0/0.Successful Packet Call setup allocations and allocation attempts due toIncoming relocation or Inter-RNC HHOs are not counted separately.

PS Call Counter failure -AC

In case the starting state of the terminal is Cell_FACH (Cell_PCH) or DCH0/0 and AC rejects the bit rate allocation and terminal stays atCell_FACH or DCH0/0, following counters are incremented:M1022C9 PS_SETUP_FAIL_AC_INTM1022C10 PS_SETUP_FAIL_AC_BGR

Resource reservation happens during PS

user plane allocation. If user plane allocation is rejected by theadmission control. RAS06 new PS callcounters

M1022C9 Packet Call Setup Fail dueto AC for Interactive

M1022C10 Packet Call Setup Fail dueto AC for Background

are updated

RAS06 PS t f il i ith RAS5 1 PS


41/93


RAS06 PS setup fail comparison with RAS5.1 PSRAB setup, RNC level

0.000

0.010

0.020

0.030

0.040

0.050

0.060

08.03.20

08

15.03.20

08

22.03.20

08

29.03.20

08

05.04.20

08

12.04.20

08

19.04.20

08

26.04.20

08

03.05.20

08

RNC_376a RAB setup failures for PS caused bythe AC

RNC_378a RAB setup failures for PS caused bytransmission

RNC_379a RAB setup failures for PS caused byRNC's internal reasons

RNC_380a RAB setup failures for PS caused byanchoring RNC reject.

RNC_381a RAB setup failures for PS due to a

frozen BTS

PS_SETUP_FAIL_AC_pPS_SETUP_FAIL_AC_p

PS_SETUP_FAIL_BTS_pPS_SETUP_FAIL_BTS_p

PS_SETUP_FAIL_DMCU_pPS_SETUP_FAIL_DMCU_p

PS_SETUP_FAIL_TRANS_pPS_SETUP_FAIL_TRANS_p

PS_SETUP_FAIL_UE_pPS_SETUP_FAIL_UE_p

PS_SETUP_FAIL_OTHER_pPS_SETUP_FAIL_OTHER_p

RAS06 PS t f il i ith RAS5 1


42/93


RAS06 PS setup fail comparison with RAS5.1-HSDPA setup, RNC level

0.000

0.020

0.040

0.060

0.080

0.100

0.120

0.140

0.160

0.180

08.03.20

08

15.03.20

08

22.03.20

08

29.03.20

08

05.04.20

08

12.04.20

08

19.04.20

08

26.04.20

08

03.05.20

08

RNC_661a HSDPA Access failures due to UL

DCHRNC_663a HSDPA Access failures due to RNC

RNC_665a HSDPA Access failures due to Iub

RNC_667a HSDPA Access failures due to UE

RNC_669a HSDPA Access failures due to toomany HSDPA users

RNC_671a HSDPA Access failures due to Multi-RAB

RNC_673a HSDPA Access failures due to BTS

PS_SETUP_FAIL_AC_pPS_SETUP_FAIL_AC_p

PS_SETUP_FAIL_BTS_pPS_SETUP_FAIL_BTS_p

PS_SETUP_FAIL_DMCU_pPS_SETUP_FAIL_DMCU_p

PS_SETUP_FAIL_TRANS_pPS_SETUP_FAIL_TRANS_p

PS_SETUP_FAIL_UE_pPS_SETUP_FAIL_UE_p

PS_SETUP_FAIL_OTHER_pPS_SETUP_FAIL_OTHER_p


43/93


44/93


Introduction


RRC setup

RAB setup

PS setup HSDPA/HSUPA setup


RRC/RAB/SHO active

HSDPA/SCC/HSUPA active ISHO

Contents

HSDPA Accessibility failure analysis


45/93


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

Top X cells

Setup Fail

BTS

RNC_605a< X %

Setup Fail UL

return

Channel

Setup Fail Iub

TransportSetup Fail UE

Setup Fail

RNC internal

Setup FailToo Many

Users

No action

needed

Check CE

resource usage

at 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

No

Yes

YesYesYesYes YesYes

No No No NoNo

Check

UL power

congestion BH

HSDPA Accessibility analysis


46/93



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 ?



47/93



5. If high HSDPA Access Failure_BTS

Lack of UL channel resources (check CE resource utilisation using M5001 counters atBH)

Too high SHO overhead all branches must have enough CE capacity if UE is in SHOwhen HS-DSCH allocation is started

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

0

200

400

600

800

1000

1200

1 1 4 2 7 4 0 5 3 6 6 7 9 9 2 1 05 1 18 1 31 1 44 1 57 1 70 1 83 1 96 2 09 2 22 2 35 2 48 2 61 2 74 2 87

0

5

10

15

20

25

30

SETUP_FAIL_BTS_HS_DSCH_BGR (Traffic)

AVE_AVAIL_PERC_POOL_CAPA_UL (Cellres)



48/93



6. REJ_HS_DSCH_RET and PS_REL_OTH_FAIL_HS_D

In RAS06 UL AC could be based on both throughput andpower based PS call algorithm depending on the parametersettings.

PrxLoadMarginMaxDCHparameter defines interference

margin for the maximum UL DCH load. Using default valueof 2dB (37% load) can cause HSDPA UL return channelrejections due AC to increase.

It is recommended to remove impact of this parameter bysetting it to value 0 dB (throughput based AC algorithm not

in use).

This parameter is valid for all R99 PS bearers, not only forHSDPA UL return channel.

HSUPA Accessibility Analysis


49/93


HSUPA Accessibility Analysis

HSUPA Accessibility KPI is measured with RNC_913a

Low HSUPAaccessibility

Check Number of simultaneous HSUPA users

(20/cell, 24/NodeB )

Check BH Channel element resource usage UL/DL

(BTS in state that no capacity available for EDCH)

HSUPA is not supported in SHO branch

Check BH Channel element resource usage UL/DL

Check RB reconfiguration failure rate

(Terminal problem)

Check AAL2 connections (CID) or signallingproblems

No ActionNeeded

Too many HSUPAusers reached

UL DCH selecteddue BTS HW

HSUPA fail dueNot Acceptable

Active Set

HSUPA Setup failBTS

HSUPA Setup FailUE

HSUPA Setup FailTRANS

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

No

No

No

No

No

Go for troubleshooting (ICSU logs etc)

E.g. RNC internal failures

HSUPA Setup failOther

Yes

HSUPA Accessibility


50/93


HSUPA Accessibility

If HSDPA setup is failing also HSUPA setup will fail, but it could be also thatonly HSUPA will fail. The reasons are similar to HSDPA

RNC_956a E-DCH Setup FR due to BTSRNC_1105a E-DCH Setup FR due to TransportRNC_1106a E-DCH Setup FR due to UERNC_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 usersRNC_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 branchM1002C519 EDCH_ALLO_CANC_NA_AS_INT

M1002C520 EDCH_ALLO_CANC_NA_AS_BGR
http://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_956ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1105ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1106ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1104ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_968ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_969ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_957ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_957ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_969ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_968ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1104ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1106ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1105ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_956a


51/93


Introduction


RRC setup

RAB setup

PS setup HSDPA/HSUPA setup


RRC/RAB/SHO active

HSDPA active/SCC/HSUPA Active ISHO

Contents

Call Drop analysis


52/93


Call Drop analysisTop (N) drops

Cell and its NeighbourCells availability

Alarms/Tickets

Configuration &Parameter audit

SHOSuccessRate 40 %

ISHOSuccess

Rate < 90%

RF and ISHO neighbouroptimisation

3G cell coversover a

coverage hole?

3G cell at inter-RNC border ?

Wrong reference clock(10MHz tuning)

No cell foundratio > 90 %and enough

ADJG

2G Cell Doctor

2G Investigation :TCH blocking or

TCH seizurefailure

(interference)

NO

YES

YES

YES

NO

YES

NO

YES

YES

SHO

ISHO

Top

issu

es

Call Drop analysis


53/93


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 MSCdatabase consistency audit, check alarm of reference clock in 3G or in 2G, check 2GTCH congestion

Check RRC Drop ISHO RT / NRT

Call Drop analysis


54/93


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) tocheck 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


55/93


RAB Active Phase Failure

Cells having high RAB drop ratio due the Radio or UE can be identified byservice level counters

Formula below count CS voice RAB drop ratio due the radio from networkperspective.

The counters RAB_Active_Fail_XXX_Radio/UE can be used to measure airinterface . Following failures are related to counters

%

____

__________

____________

__________

_____*100

_

failuresall VOICECSFAILACTRAB

CELLREFOUTVOICECSRABCELLREFINVOICECSRAB

CNERUNSPEVCSRELACTIVERABSRNCVOICECSRELACTRAB

EMPPVOICECSRELACTRABVOICECSCOMPACTRAB

RADIOVOICECSFAILACTRAB

Active_Fail_UEtimer_expired_cradio_conn_lost_cms_c

Active_Fail_UEtimer_expired_cphysical_ch_reconf_fail_cms_c

Active_Fail_Radiodefault_cno_resp_from_rlc_cradio_interface_c

Active_Fail_Radioradio_conn_lost_cradio_link_failure_cradio_interface_c

Count er Service LevelOUT DETAILED REASONOUT REASONOUT FAIL SOURCE

Active_Fail_UEtimer_expired_cradio_conn_lost_cms_c

Active_Fail_UEtimer_expired_cphysical_ch_reconf_fail_cms_c

Active_Fail_Radiodefault_cno_resp_from_rlc_cradio_interface_c

Active_Fail_Radioradio_conn_lost_cradio_link_failure_cradio_interface_c

Count er Service LevelOUT DETAILED REASONOUT REASONOUT FAIL SOURCE

RAB Drop ratio can

per RAB type or

RAB drop rate

containing all RABs


56/93


57/93

CS RAB drop cause distribution (Ras05)


58/93


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 ASUKPI

ISHO - Physical Channel Reconfiguration fail

Delay in ISHO ->RRC Drop ISHO RTKPI

Radio Connection lost

Failure during Physical CH Reconfiguration procedure -> Phy ch ReconfSucc Rate KPI

OUT FAIL SOURCEFailure counter

radio_interface_c RADIOms_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 servicelevel counters

Radio Link Failure


59/93


Radio Link Failure

Iub Counter table measurements can be used to detect Radio Link Deletionrate due the active L1 synchronisation failure

The KPI measures the percentage of radio link deletions to the total numberof radio links that were successfully established i.e. initial, soft and softerhandover.

Use raw counters for following KPI to detect cells with high synchronisationfailure

Compare Cell Level KPI to RNC Level KPI

RLSHOFORSUCCSETUPRL

RLFIRSTFORSUCCSETUPRL

SRNCSHOSUCCADDBRANCHRL

FAILSYNRLACTSRNCSHODELACTLOSTUL

_____

_____

_____

________

NUMBER OF ACTIVERADIO LINKS IN THE IUB

NUMBER OF RADIO LINKDELETION FOR ACTIVE

SYN FAILURE

Downlink radio link failureresults in an UL synchronizationloss since the UE stopstransmitting.

R di i k F il


60/93


RNC_ID

CELL_ID

RNC-CITTA

DAY

RL_SETUP_ATT_

FOR_FIRST_RL

RL_SETUP_ATT_

FOR_SHO_ON_SRNC

RL_BRANCH_ADD_SUCC_SHO_SRNC

DEL_SHO_SRNC_ACT_RL_SYN_FAIL

UL_LOST_ACTIVE

NE-RNC-2 62272 MILANO1 20050117 770 401 206 295 21.4%

NE-RNC-2 62272 MILANO1 20050118 606 363 241 267 22.1%

NE-RNC-2 62272 MILANO1 20050119 669 493 161 308 23.3%

NE-RNC-2 62272 MILANO1 20050120 777 460 166 357 25.4%

NE-RNC-2 62272 MILANO1 20050121 1215 672 265 464 21.6%

RNC_

ID

RNC-CITTA

DAY

UL_

LOST_A

CTIVE

NE-RNC-2 MILANO1 20050117 10.0%

NE-RNC-2 MILANO1 20050118 10.3%

NE-RNC-2 MILANO1 20050119 10.1%

NE-RNC-2 MILANO1 20050120 9.8%

RNC2

average:10%

Radio Link Failure

The counterDEL_SHO_SRNC_ACT_RL_SYNC_ FAIL measure the number

of Radio link deletions on SRNC side due to an active radio linksynchronisation failure.

Counter is updated when a BTS loses synchronisation on an active RL andis 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 )


61/93


62/93


AVG_PRX_TOTAL

-110

-105

-100

-95

-90

-85

-80

2005011700

2005011707

2005011715

2005011722

2005011805

2005011812

2005011820

2005011903

2005011910

2005011917

2005012001

2005012008

2005012015

2005012022

2005012105

2005012112

2005012119

dB AVG_PRX_PWR

Radio Connection Lost- RAB Reconfiguration fail

RAB Reconfiguration Success Rate KPI is ~2% lower than at RNC level

The cell has other kind of radio failuresDrop voice is 3%

%RB_RECONF

COMPLETERB_RECONF_*100

CELL

DAY

RB_RE

CONF

RB_RE

CONF_COMPLETE

RB_RE

CONF_SUCCESS_RAT

62542 20050117 284 283 99.6%

62542 20050118 1619 1570 97.0%

62542 20050119 2169 2102 96.9%

62542 20050120 1857 1787 96.2%

62542 20050121 1168 1132 96.9%

RNC-CITTA

DAY

RB_R

ECONF

RB_R

ECONF_COMPLETE

RB_R

ECONF_SUCCESS_RA

MILANO1 20050117 128890 127617 99.0%

MILANO1 20050118 138597 137227 99.0%

MILANO1 20050119 142997 141604 99.0%

MILANO1 20050120 136753 135481 99.1%

MILANO1 20050121 118625 117340 98.9%

CELLlevel

STOP WCELL ID OUT FAIL SOURCE OUT REASON Percentage

62542 radio_interface_c radio_link_failure_c 2.5%

62542 ms_c radio_conn_lost_c 1.2%

62542 radio_interface_c no_resp_from_rlc_c 0.1%

RNClevel

SHO O h d


63/93


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

)1)____________

____________

____________(

)3*)____________(

2*)____________(

1*)____________(((*100

_

NRTFORSETACTINCELLTHREERTFORSETACTINCELLSTHREE

NRTFORSETACTINCELLTWORTFORSETACTINCELLSTWO

NRTFORSETACTINCELLONERTFORSETACTINCELLONEsum

NRTFORSETACTINCELLTHREERTFORSETACTINCELLSTHREE

NRTFORSETACTINCELLTWORTFORSETACTINCELLSTWO

NRTFORSETACTINCELLONERTFORSETACTINCELLONEsum

OverheadSHO

)____________

____________

____________(

)__________(*100__

NRTFORSHOONREQDELCELLNRTFORSHOONREQREPLCELL

NRTFORSHOONREQADDCELLRTFORSHOONREQDELCELL

RTFORSHOONREQREPLCELLRTFORSHOONREQADDCELLsum

NRTFORSHOONUPDATESSUCCRTFORSHOONUPDATESSUCCsumratioSuccessSHO

SHO success (RNC_195a)

SHO success and SHO OH can

be calculated separately for RT

& NRT

these examples contains both

SHO S Adj


64/93


SHO Success per Adjacency

The HO success rate per adjacency can be used to detect badly performingneighbours

can be calculated by using formulas below

SHO Success per Adjacency (M1013 AutoDef SHO)

IFHO Success per Adjacency (M1014 AutoDef IFHO)

ISHO Success per Adjacency (M1015 AutoDef ISHO)

)_____(

)_____(*100900_____

ATTSHOFREQINTRAADJSHOsum

COMPLSHOFREQINTRAADJSHOsumaRNCADJSpersuccessSHO

)_____(

)_____(*100901_____

ATTHHOFREQINTERADJHHOsum

COMPHHOFREQINTERADJHHOsumaRNCADJIpersuccessIFHO

)_____()_____(*100902_____

ATTHHOSYSINTERADJHOsumCOMPLHHOSYSINTERADJHOsumaRNCADJGpersuccessISHO

RAS06 new SHO counters


65/93


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
http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C121http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C122http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C123http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C124http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C125http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C126http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C126http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C125http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C124http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C123http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C122http://nop-i.nokia.com/counter.php?ne=RNC&text=as*&counter_id=M1006C121


66/93

RAS06 Active Set Add FAIL UE/NO REPPLY-


67/93


_example (wcel level, 13.03.2008)

0

5000

10000

15000

20000

25000

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

0

5

10

15

20

25

30

AS_UPDATE_RL_ADD_ATTAS_UPDATE_RL_DEL_ATT

AS_UPDATE_RL_ADD_FAIL_UE

AS_UPDATE_RL_ADD_NOREPLY

Contents


68/93


Introduction


RRC setup

RAB setup

PS setup

HSDPA/HSUPA setup


RRC/RAB/SHO active


Contents


69/93


70/93

HSDPA Retainability analysis


71/93


y y

3. If high HSDPA Non- Radio Link Failures (NRT)

UE responding with some failure message or not responding to somemessage but no RL failure (timer expiry)

Check RB reconfiguration, physical channel reconfiguration, NBAP RLreconfiguration failure rate

Required ICSU log for further troubleshooting ?

HSUPA Retainability analysis


72/93


y y

The retainability of all successfully allocated E-DCH resources for NRTtraffic is measured with KPI RNC_919a

There are several reasons for HSUPA release:

RNC_1108a E-DCH Rel due to RL FailuresRNC_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
http://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1108ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1109ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1109ahttp://nop-i.nokiasiemensnetworks.com/formula.php?ne=RNC&formula_id=RNC_1108a


73/93


gchange

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


74/93

HSDPA SCC Analysis


75/93


Top N cells

SCC Fail BTS

RNC_733a < X

%

SCC Fail ACSCC Fail

TransmissionSCC Fail UE

SCC Fail

Others

No action

needed

Check CE

resource usage

at BH

code tree

congestion BH

DL power

congestion

BH ?

Check AAL2

Iub resource

congestion at

BH

Check RB

reconfiguration

Failure rate

Check RNC

internal

transport

resources

(DMPG)ICSU

troubleshooting

No

Yes

YesYes Yes YesYes

No No NoNo

No

HSDPA SCC Success Rate

SCC FailPrevention

timer

Check

HSDPACellCha

ngeMinInterval

parameter

Check

Maximum

number of

HSDPA users

No

No

Ye

s

HSDPA SCC analysis


76/93


1. Determine SCC success rate, SCC failure rate and failure cause distribution

2. Check target cells HSDPA Setup performance (M1002C401 M1002C428) ifsource 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 M1000C20AVE_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


77/93


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 Throughput Analysis


78/93


OSS counters measurement data

collection

Identify Low

throughput areas if

exist

Low throughput

due to low

Ec/No or CQI

Identify reason for low throughput if not RF

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)

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

If low throughput due to low Ec/No

or Poor CQI, identify reason

Bad Coverage Planning

Quality issue due the neighbour

planning

No Optimisation Required

Implement Changes

NOYE

S

Optimise RF

Add missing neighbours

Change Antenna tilt etc.

START

NO

YE

S

If throughput is low in network level, thereason can be also FTP/HTTP server

settings (fire wall), Measurement tools etc.

Optional Features like

Proportional Fair

HSDPA Mobility

16QAM Modulation

has impact for the throughput

HSDPA Throughput analysis


79/93



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 badcoverage 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


80/93



Check Mininum, Maximum & Average HSUPA throughput from WBTScounter measurement (M5000C153)

Check CQI distribution (M5000C8-M5000C39) or Ecno distribution for badcoverage issue (M1007C38-M1007C47)

Check If low throughput due to high number of retransmission & failedretransmission (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 HSDPAthroughput due to counters updating across total measurement period

Contents


81/93



Introduction


RRC setup

RAB setup

PS setup

HSDPA/HSUPA setup


RRC/RAB/SHO active


Contents

Inter System Handover 3G -> 2G Tuning


82/93



3. Decision Algorithm

UE Tx Power (Event 6A)Threshold:GsmUETxPwrThrXXL3 filter:

GsmUETxPwrFilterCoeffHysteresis margin:GsmUETxPwrTimeHystData rate threshold

HHOMAxAllowedBitrateUL

UL QualityTimer:ULQualDetRepThresholdData rate threshold

HHOMAxAllowedBitrateUL

DL DPCH powerThreshold:

GsmDLTxPwrThrXXData rate threshold

HHOMAxAllowedBitrateDL

(XX=AMR,CS,NrtPS,RtPS)

CPICH RSCP (Event 1F)Thresholds:HHoRscpThresholdHHoRscpCancel

L3 filter:HHoRscpFilterCoefficientTimers:HHoRscpTimeHysteresisHHoRscpCancelTime

CPICH Ec/Io (Event 1F)Thresholds:HHoEcNoThresholdHHoEcNoCancel

L3 filter:EcNofilterCoefficientTimers:HHoEcNoTimeHysteresisHHoEcNoCancelTime

AdjgTxPwrMaxTCHAdjgRxLevMinHO (n)

GsmMeasAveWindow

GsmMeasRepIntervalGsmNcellSearchPeriod

GsmMinMeasIntervalGsmMaxMeasPeriod

Handover Execution

2G-to-3G back prevention

GsmMinHoInterval

2. GSM measurement reporting

1. Triggering2. GSM measuring

3. Decision

ISHO 3G -> 2G - AMR Signaling Flow


83/93



BSIC verification always performed for AMR calls no interrupt in voice call

CNUE

NodeB

RNC

RRC: Measurement Report

RRC: MeasurementControl

NBAP: Radio Link ReconfigurationPrepare

NBAP: Radio Link ReconfigurationReady

NBAP: Radio Link ReconfigurationCommitRRC: Physical Channel

ReconfigurationRRC: Physical Channel ReconfigurationComplete

NBAP: Compressed ModeCommand

RRC: Measurement ReportRRC: MeasurementControl




RRC: Handover from UTRANCommand

GSM BSICIdentification

GSM RSSIMeasurement

ISHO triggering

(5 reasons arepossible)

InitialCompressedModeConfiguration

RANAP: RelocationRequired

RANAP: Relocation

CommandRANAP: IU Release

Command

RANAP: IU ReleaseComplete

Compressed Mode


84/93



RNCUE

RRC: Measurement Report(3,4,5)


BTS

AdmissionControl

check forCM


NBAP: Radio Link ReconfigurationFailure

M1010C2 (M1010C40)IS_COM_MOD_STA_NOT_POS_(N)RTThe counters is update if:1) Admission Control rejects compressed mode request: If

Compressed Mode cannot be started due to AC rejecting therequest counters: M1002C361REQ_COM_UL_REJ_SYS_HHO_SRNC or M1002C362

REQ_COM_DL_REJ_SYS_HHO_SRNC2) 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)

If compressed mode can NOT start (before sending Measurement Control)

the following counter is incremented:

The counters are updated in the BEST cell of the active se

Inter-System measurement parameters


85/93



Inter-RAT Measurement control parameters

Periodical measurement reporting intervalGsmMeasRepInterval(0.5s)

GsmNcel lSearchPer iod(0 meas rep) the time period after the startingIS measurements, during which Ho is not allowed

GsmMaxMeasPeriod(20 meas rep) defines the maximum allowedduration of the inter-system measurement

GsmMinMeasInterval(2s)defines the minimum time before newmeasurement procedure/handover attempt will start in case an

unsuccessful measurement procedure/previous HO related to sameRRC connection

GSMMinHoInterval(10s) defines the minimum interval between asuccesfull inter-system handover from GSM and the following inter-system handover attempt to the GSM, related to the same RRCconnection

GsmMeasAveWindow(6 meas rep)defines how many measurementreports are taken to one average value done in RNC, sliding window isused

Maximum Measurement Interval


86/93



These parameters control the maximum compressed mode duration time for eachGSM RSSI and BSIC decoding measurement process. The duration of thisinterval in seconds is given by:

max_meas_interv al (s) =GsmMaxMeasPer iodxGsmMeasRepInterval+ 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 receivingGsmMaxMeasPeriod ISHO Measurement Reports (meas id = 3).

The ISHO procedure is considered to be unsuccessful and a new one can beactivated afterGsmMinMeasInterval(2s) provided that meanwhile RNC has notreceive a cancellation event.

Note that in case the t ime window expires ISHO coun ters are not up dated at

al l

(12s)

(20) (0.5 s)

ISHO analysis Flow Chart


87/93



ISHO Success Rate RT

Top N cells

RNC_300c

PrxTotal & PtxTotal

Yes

No

ISHO analysis


88/93



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

3. If high ISHO compressed mode start not possible

Check busy hour data of PrxTotal , PtxTotal and M1000C22 AVE_PTXTOT_CLASS_4and M1000C20 AVE_PTXTOT_CLASS_3 for AC rejection

0

10

20

30

40

50

60

70

20040906

20040907

20040908

20040909

20040910

20040911

20040912

20040913

IS_COM_MOD_STA_NOT_P

OS_RT

UE_PWR_RT

-110

-105

-100

-95

-90

-85

-80

-75

2004090900

2004090901

2004090902

2004090903

2004090904

2004090905

2004090906

2004090907

2004090908

2004090909

2004090910

2004090911

2004090912

2004090913

2004090914

2004090915

2004090916

2004090917

2004090918

2004090919

2004090920

2004090921

2004090922

2004090923

hour

dBm

Average _PrxTotal_excl_0 Average_PrxTotal_clas s_0 AVG_PRX_PWR

ISHO Analysis


89/93



4. If Low ISHO Measurement Success Rate

Check ADJG neighbour list for missing neighbours

Check parameter discrepancy (BSIC) or BSIC collision due to too tightreuse

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


90/93



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 counteris triggered:

RNCUE



BTS

AC check for CM



NBAP: Radio Link ReconfigurationCommit

RRC: Physical ChannelReconfiguration

RRC: Physical Channel ReconfigurationComplete





RRC: MeasurementControlRRC: Measurement Report

BSIC verification phase for target cell

RX Level measurement phase for

all ISHO neighbours

CN

RANAP: RelocationRequired

RRC: Handover from UTRANCommand

RANAP: RelocationCommand

RANAP: IU Release

Request

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

M1010C37 CON_DRPS _IS _HHO_ECNO_RT

M1010Cxxx

CON_DRPS_IS_HHO_LSHO_triggers_RT*

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.

For RT: TRelocOverall (def. 8s, from RelocationCommand to Iu Release Command) expires.

RRC Drop during ISHO NRT- Iu Radio Link Failure


91/93



p g

RNCUE



BTS

AC check for CM



NBAP: Radio Link ReconfigurationCommit

RRC: Physical ChannelReconfiguration

RRC: Physical Channel ReconfigurationComplete


RRC: MeasurementControlRRC: Measurement Report

NBAP: Compressed Mode

CommandRRC: Measurement

ControlRRC: Measurement Report

BSIC verification phase for target cell

RX Level measurement phase for

all ISHO neighbours

CN

RRC: Cell Change Order from UTRAN

RANAP: SRNS ContextRequest

RANAP: IU Release

Request

RANAP: SRNS Data ForwardCommand

RANAP: SRNS Context Response

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 counteris triggered:

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 CON_DRPS _IS _HHO_ECNO_NRT

M1010Cxxx

CON_DRPS_IS_HHO_LSHO_triggers_NRT*

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.

For NRT: IU release request is sent after 8s fromsending Cell Change Order.

Radio Connection Lost Physical Channel reconf fail


92/93



The RAB voice failure due the radio_connection_lost timer_expires arerelated to physical channel reconfiguration complete not received at CM start

The Cells affected by physical channel reconfiguration failure can beidentified through the RRC Signalling level Counters

WCEL_ID

period

PHY_CH_RECON

F

PHY_CH_RECON

F_COMP

%62951 17-21/01/05 258 230 89.1%

RNC_ID

RNC-CITTA

DAY

PHY_CH_RECONF

PHY_CH_RECONF_COMP

PHY_CH_RECONF_SUCCESS_RATE

NE-RNC-2 MILANO1 20050117 9677 9538 98.6%

NE-RNC-2 MILANO1 20050118 10083 9941 98.6%

NE-RNC-2 MILANO1 20050119 11048 10885 98.5%

NE-RNC-2 MILANO1 20050120 10521 10365 98.5%

NE-RNC-2 MILANO1 20050121 11661 11460 98.3%

%ONFPHY_CH_RECONF_COMPPHY_CH_REC

*100__Re_ RateSuccconfPhyChan

Physical Channel Reconfiguration Fail


93/93

y g

Physical Channel Reconfiguration fail vs. Establishment Cause

Mapping to counterRRC/RAB_ACT_FAIL_UE

Looking at some logs the failure is due to difficult BSIC verification duringISHO procedure and since the failure happens afterthe Handover fromUTRAN commands all relative ISHO counters are incremented

In the same area there are some Handover from UTRAN failure messagessent back from the UE with the cause physical channel failure this meansthat 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

Documents

Transcript of RANOP2 Module2 PM Monitoring Analysis RAS06 111008