3G RANOP RU40 NSN Performance Monitoring

7/24/2019 3G RANOP RU40 NSN Performance Monitoring

http://slidepdf.com/reader/full/3g-ranop-ru40-nsn-performance-monitoring 1/54

Nokia Academy

RN31571EN40GLA1 © Nokia Solutions and Networks 2015

Nokia Networks

3G RANOP RU40Performance Monitoring



2 RN315701EN40GLA1 © Nokia Solutions and Networks 2015

Copyright and confidentiality

The contents of this document are proprietary

and confidential property of Nokia Solutions

and Networks. This document is provided

subject to confidentiality obligations of the

applicable agreement(s).

This document is intended for use of Nokia

Solutions and Networks customers and

collaborators only for the purpose for which

this document is submitted by Nokia

Solutions and Networks. No part of this

document may be reproduced or made

available to the public or to any third party in

any form or means without the prior written

permission of Nokia Solutions and Networks.This document is to be used by properly

trained professional personnel. Any use of the

contents in this document is limited strictly to

the use(s) specifically created in the

applicable agreement(s) under which the

document is submitted. The user of this

document may voluntarily provide

suggestions, comments or other feedback to

Nokia Solutions and Networks in respect of

the contents of this document ("Feedback").

Such Feedback may be used in NokiaSolutions and Networks products and related

specifications or other documentation.

Accordingly, if the user of this document

gives Nokia Solutions and Networks feedback

on the contents of this document, Nokia

Solutions and Networks may freely use,

disclose, reproduce, license, distribute and

otherwise commercialize the feedback in any

Nokia Solutions and Networks product,

technology, service, specification or other

documentation.

Nokia Solutions and Networks operates a

policy of ongoing development. Nokia

Solutions and Networks reserves the right to

make changes and improvements to any of

the products and/or services described in thisdocument or withdraw this document at any

time without prior notice.

The contents of this document are provided

"as is". Except as required by applicable law,

no warranties of any kind, either express or

implied, including, but not limited to, the

implied warranties of merchantability and

fitness for a particular purpose, are made in

relation to the accuracy, reliability or contents

of this document. NOKIA SOLUTIONS ANDNETWORKS SHALL NOT BE

RESPONSIBLE IN ANY EVENT FOR

ERRORS IN THIS DOCUMENT or for any

loss of data or income or any special,

incidental, consequential, indirect or direct

damages howsoever caused, that might arise

from the use of this document or any contents

of this document.

This document and the product(s) it describes

are protected by copyright according to the

applicable laws.

Nokia is a registered trademark of Nokia

Corporation. Other product and company

names mentioned herein may be trademarks

or trade names of theirrespective owners.

© Nokia Solutions and Networks 2015




Performance Monitoring

Call drop (RAB, DCH, radio link)Mobility (SHO, ISHO, relocation)

HSPA drop

HSPA mobility (SCC, HSUPA SHO)




Top (N) drops

Serving and neighbor

cells availability

Alarms/Tickets

Configuration and

parameter audit

SHO

Success

Rate < 90%?

Conf OK ?

Site OK ?

ISHO

Failures

Iur

performanceInvestigation Iur

Audit adjacent sites for

alarms, availability,configuration and capacity

Trafficneighbor performance

(use SHO success per adjacency

counters to identify badly

performing neighbors) and map

3G Cell at

RNC

border?

NO

YES

New site ?

Analyse last detailed

radio measurements

RF and IFHO neighbor

optimisation

No cell

found ratio

>40 %

ISHO

Success

Rate < 90%

RF and ISHO neighbor

optimisation

3G cell

covers over a

coverage hole

?

3G cell at

inter-RNC

border ?

Wrong reference clock

(10MHz tuning)

No cell found

ratio > 90 %

and enough

ADJG

2G Investigation

TCH blocking or

TCH seizure failure

(interference)

NO

YES

YES

YES

NO

YES

NO

YES

YES

SHO

ISHO

Call drop – analysis process 1/2Flow chart for RAB

No SHOSee next slide

No SHO triggered???

Fragmented Cell!

Forgotten Neigbours!

Temporary Solution

DSR;

Solution Fragmented

Cell find Reflection or

antenna side lobechange Antenna tilt or

azimuth;


http://slidepdf.com/reader/full/3g-ranop-ru40-nsn-performance-monitoring 5/546 RN315701EN40GLA1 © Nokia Solutions and Networks 2015

Call drop – analysis process 2/2

No SHOCheck adjacencies

Not OK

Corrrect the adjacencies list

(Include forgotten neighbors)

OK

Check of cell fragmentation

change Antenna tilt or azimuth

Temporary solution: activate DSR

YES

Check SHO parametersNo

No SHO triggered??? Fragmented Cell! Forgotten Neigbours! Temporary

Solution DSR;

Solution Fragmented Cell find Reflection or antenna side lobe change

Antenna tilt or azimuth;



Call drop analysisFailure cause example for voice

Many CS RAB

drop causesdue to radio

and

transmission



Call drop analysisFailure cause example for PS

Many PS RAB drop causes

due to UE and radio



Call drop analysis1. Check high call drop cells and its neighboring cells for any fault alarms

2. Generate call drop root cause distribution and check for main contributors (radio, BTS,

Iub, Iur, RNC, Iu, MS)

3. Check SHO if success rate < 90% (leads to radio link failure)

Check if cells are at RNC border (check Iur capacity and SRNC relocation problem)

Detect badly performing neighbors using SHO success rate per adjacency counters (M1013)

High incoming HO failure rate from all adjacencies – check sync alarms

Assess neighbor list plan and do visualization check with map

Evaluate HO control parameters and trigger thresholds

4. Check ISHO KPI if RT ISHO < 90% or NRT < 80% (leads to radio failure)

Check missing neighbors (M1015)

Check GSM frequency plan, RNC and MSC database consistency

Check alarm of reference clock in 3G or in 2G

Check 2G TCH congestion

Check RRC drop during ISHO RT / NRT



Call drop analysis5. Look for DL or UL path loss problem if RAB drop due to radio dominates

Check UE lost counters (active L1 synchronization failure) to check UL/DL path loss problem

Check active set update failure rate (with cause no response from UE)

Map radio failures with RL power and CPICH related parameters (CPICHToRefRABOffset, PTxDPCHMax)

Check call reestablishment timer (T315)

Check Ec/Io distribution for bad coverage issue (M1007)

6. Check core network parameter setting if RAB drop due to Iu

Check SCCP signaling (MSC / SGSN, RNC, IuCS / IuPS)

7. If high RAB drop due to BTS

Check for any BTS faulty alarm (e.g. 7653 cell faulty alarm)

If no alarms, COCO detach/attach

8. If high RAB drop due to MS

Check physical channel reconfiguration failure rate (IFHO, ISHO, code optimization)



Call drop analysisExample for trace of individual dropped call (possible with MEGAMON)

UE does not find SHO neighbor

Event 1F due to RSCP

UE enters compressed mode

But does not find GSM neighbor

either



• RT

• If communication between UE and network interrupted, this will triggerRAB drop

• NRT

• Interrupted communication between UE and network will not trigger

immediately RAB drop

• Network tries to shift UE to Cell_FACH state, i.e. tries to keep RAB running

RT and NRT

Soft drop - DCH



Failure cause example

Soft drop - DCH

Two drop cause counters only

Radio

Other

Majority ofDCH drops

still due to

radio




RLSHO FORSUCC SETUP RL

RL FIRST FORSUCC SETUP RL

SRNC SHOSUCC ADD BRANCH RL

FAILSYN RL ACT SRNC SHO DEL ACT LOST UL

_ _ _ _ _

_ _ _ _ _

_ _ _ _ _

_ _ _ _ _ _ _ _

RL setup due to softer HO

RL deletion due to

synchronization failure

Downlink radio link failure results

in UL synchronization loss since

the UE stops transmitting

Soft drop – radio link failure

• BTS looses synchronization with UE and cannot re establish it

within specified time• Compare number of radio links deletions due to synchronization

failure with total number radio link setup processes

• In SHO radio link failure downgrades coverage only, but does not

trigger immediately DCH or even RAB drop

Definition

RL setup due to initial request

RL setup due to soft HO

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. If a BTS loses

synchronisation on an active RL and is not able to re-establish synchronisation during

the allowed time.




Soft drop - radio link failureFailure example – RL deletion by SRNC and DRNC (with OSS data)

> 50 % abnormal deletions

< 20 % abnormal deletions

Each point represents one cell

Black = RL deletion by SRNC

Red = RL deletion by DRNC

High number of abnormal radio link

deletions by DRNC





Call drop (RAB, DCH, radio link)Mobility (SHO, ISHO, relocation)

HSPA drop





SHO – successful softer HOSignaling and trigger

UE BS RNC

Measurement report 1A or 1C

RL addition request

RL addition response

AC

BTS resources needed

But no Iub resources

(no CAC)

Active set update

Active set update complete

SETUP PHASE

ACCESS PHASE

If problem, check radio link

addition failure causes (M1005)

If problem, check air interfaceperformance




SHO – successful soft HOSignaling and trigger

UE BS RNC

Measurement report 1A or 1C

RL setup request

RL setup response

AC

Active set update

Active set update complete

SETUP PHASE

ACCESS PHASE

AAL2 sig. ERQ

AAL2 sig. ECF

BTS resources needed

And Iub resources

needed (CAC)

If problem, check radio link

setup failure causes (M1005)

If problem, check air interfaceperformance




SHO – OverheadConcept and counters

• Indicates size of SHO area

• If too small, SHO might fail

• If too big, capacity is wasted

• Counter for calculation of overhead

• Consider the time, a call stays in an active set of 1 / 2 / 3 cells, both for RT and

NRT services

• ONE_CELL_IN_ACT_SET_FOR_(N)RT

• TWO_CELL_IN_ACT_SET_FOR_(N)RT

• THREE_CELL_IN_ACT_SET_FOR_(N)RT




Call setup in cell A.

Cell A Cell B

Cell A Cell BCell A Cell B


After 40sec Event 1A (addition): Active Set has changed.

(CellA) ONE_CELL_IN_ACTIVE_SET incremented + 40sec

After 60sec Event 1B (deletion): Active Set has changed.

(Cell A) TWO_CELL_IN_ACTIVE_SET incremented +60sec

(Cell B) TWO_CELL_IN_ACTIVE_SET incremented +60sec


After 20sec Call release.

(Cell B) ONE_CELL_IN_ACTIVE_SET incremented + 20sec

SHO – OverheadConcept and counters




cell A

cell B

NRT RT SET ACT IN CELLTHREE

NRT RT SET ACT IN CELLTWO

NRT RT SET ACT IN CELLONE



NRT RT FORSET ACT IN CELLONE

/ _ _ _ _ _

/ _ _ _ _ _

/ _ _ _ _ _

3/ _ _ _ _ _

2/ _ _ _ _ _

/ _ _ _ _ _ _

Factors 1/2/3

= number of

radio links

Total time during which all calls are

running with different AS size

E1A CPICH E1B CPICH

Offset 4dB Offset 6dB

SHO

area

KPI shall give averagenumber of radio links

during a call

Total time ofall calls

SHO – OverheadCell level




Example: RNC area with 3 cells A, B and C

Cell A: 20 s active alone, 10 s with B, 10 s with C, 5 s with B + C

(20 s alone, 20 s with 2 cells, 5 s with 3 cells)

Cell B: 30 s active alone, 10 s with A, 5 s with C, 5 s with A + C


Cell C: 25 s active alone. 10 s with A, 5 s with B, 5 s with A + B


Cell level results

Cell A: Average AS size = (20x1 + 20x2 + 5x3) / (20 + 20 + 5) = 1.67 (67% overhead)

Cell B: Average AS size = (30x1 + 15x2 + 5x3) / (30 + 15 + 5) = 1.50 (50% overhead)

Cell C: Average AS size = (25x1 + 15x2 + 5x3) / (25 + 15 + 5) = 1.56 (56% overhead)


Too big SHO overhead indicated




Cell level formula gives too high KPI value

Reason:

If e.g. A and B are active, during this time a call is counted both in A and

B, i.e. two times

If e.g. A. B and C are active, during this time a call is counted in A, B and

C, i.e. three times

cell A

cell B

Counted in

cell A onlyCounted in cell A and

cell B

If cell A active together

with B

than cell B also active

together with cell A





cell A

cell B

3// _ _ _ _ _

2// _ _ _ _ _

/ _ _ _ _ _

/ _ _ _ _ _ / _ _ _ _ _

/ _ _ _ _ _ _



NRT RT SET ACT IN CELLONE



NRT RT FORSET ACT IN CELLONE

KPI compares effective

number of calls with

number of radio links

Call belongs

to cell A only

Call belongs half to

cell A and half to cell B

Denominators 1/2/3:Call with 1 radio link

Belongs completely to its single

active cell

Cell with 2 radio links

Half the call belongs to each

active cell

Cell with 3 radio links

One third of the call belongs to

each active cell

SHO – OverheadRNC level

RT/NRT means sum of

counters for RT and NRT e.g.

M1007C0+M1007C19 for ASS=1




Example: RNC area with 3 cells A, B and C

Cell A: 20 s active alone, 10 s with B, 10 s with C, 5 s with B + C

Cell B: 30 s active alone, 10 s with A, 5 s with C, 5 s with A + C

Cell C: 25 s active alone. 10 s with A, 5 s with B, 5 s with A + B

RNC level results

Cell A, B and C altogether

75 s active alone

50 s with second cell15 s with third cell

Average AS size = (75 + 50 + 15) / (75/1 + 50/2 + 15/3) = 1.33 (33% overhead)

RNC level KPI gives about half the overhead only than the cell level KPI!!

SHO – OverheadRNC level

Realistic SHO overhead indicated




SHO – OverheadRNC level example

Typical target

for SHO

overhead 40%




SHO per adjacencyConcept and counters

• SHO attempts per adjacency

• No attempts to distant cell → might be removed from neighbor list

• No attempts to nearby cell → check whether SC of ADJS is declared correctly in RNC data

base

• No attempts to inter-RNC cell → check whether RNC data bases are consistent with each

other (e.g. SC declarations)

• Very few attempts to nearby cell → check user distribution and propagation conditions

• Very few attempts in general → check addition window setting

• Too many attempts to specific neighbor → check user distribution and pilot pollution

• Too many attempts in general → check addition window setting

SHO dj




HO_ATTTRA_FREQ_SSHO_ADJ_IN

HO_COMPLTRA_FREQ_SSHO_ADJ_IN _RNCs_per_ADJSSHO_succes

SHO per adjacencyConcept and counters

• SHO success per adjacency

• High failure rate (several 10%) → besides RL setup / addition failures and airinterface performance check for SC clash

• 100% failure rate to intra-RNC cell → check for HW faults

• 100% failure rate to inter-RNC cell → check for inconsistency between RNC and

core network data base (e.g. CI, LAC and RAC declarations)

• Attempt and success per adjacency monitored by AutoDef SHO

counters (M1013)

ISHO f l d




ISHO – successful procedureSignaling and trigger

UE

RRC: Measurement Report (Event 1F)

RRC: Physical Channel Reconfiguration

RRC: Physical Channel Reconfiguration Complete

BTS RNC

UE put into

compressed mode

RRC: Measurement Control

RRC: Measurement Report

RxLev

measurements

RRC: Measurement Control

RRC: Measurement Report

BSIC verification

MSC

RANAP Relocation required

RANAP Relocation command

RRC: HO from UTRAN Command

ISHO

execution

NBAP: RL reconfig. prepare

NBAP: RL reconfig. ready

NBAP: RL reconfig. commit

NBAP: CM command

NBAP: CM command

RANAP Iu release request

ISHO l i




Top N cells

Too low success

rateNo action

needed

No

Missing ADJG or

Bad Neighbor

planning ?

Wrong 2G Ncell

Parameter (BSIC)

Or BSIC collision

No

Yes Yes

No

Too low ISHO triggering

threshold or

Too strict ADJG

minimum threshold

Non-optimum

Compressed mode

parameter set

Low ISHO

Success ?

Low ISHO

Measurement

success ?

Missing or wrong 2G

parameter in 2G MSC

or SGSN (BCCH, LAC,

CellID)

2G Ncell

Congestion

Half Rate in 2G

Ncell ?

Poor GSM

Coverage

CM Start

Not

Possible?

Yes

Check admission

control rejection

TCP and RTWP

Yes

No

ISHO – analysisFlow chart

ISHO l i




ISHO – analysisISHO cause example (with OSS data)

Blue = RSCP triggered

Red = Ec/Io triggered

Black = DL RL power triggered

UE power triggered = 0

UL SIR target triggered = 0

HHO mostly triggered by event 1F

Event 1F again mostly due to low coverage, but not quality

ISHO analysis




ISHO – analysisISHO cause example – RSCP under 1F conditions (possible with MEGAMON)

Usually very low coverage

under event 1F conditions

Consistent with counter

statistics

ISHO analysis




ISHO – analysisISHO cause example – Ec/Io under 1F conditions

Usually acceptable Ec/Io even

under event 1F conditions

Consistent with counter

statistics

ISHO analysis




ISHO - analysisISHO failure example – no target cell found (with OSS data)

100% target cell found

Each point represents one cell

80% target cell found

ISHO analysis




ISHO - analysisISHO failure example – no target cell found

In several source cells often

failure to find target cell

ISHO - analysis




ISHO - analysisISHO failure example – target cell not accessed

Much less critical to access

target cell

ISHO per adjacency




_ATTER_SYS_HHOHO_ADJ_INT

_COMPLER_SYS_HHOHO_ADJ_INT

G_RNCss_per_ADJISHO_succe

ISHO per adjacencyConcept and counters

• ISHO attempts per adjacency

• No attempts to distant cell → might be removed from neighbor list

• No attempts to nearby cell → check whether BCCH frequency and BSIC is

declared correctly in RNC data base

• ISHO success per adjacency

• High failure rate (several 10%) → besides air interface performance check for

BCCH-BSIC clash

• 100% failure rate → check for inconsistency between RNC, BSC and core

network data bases (e.g. CI, LAC and RAC declarations)

• Attempt and success per adjacency monitored by AutoDef SHO

counters (M1015)

Inter-RNC mobility




CN

RNCRNC

Iu Iu

Iur

CN

RNCRNC

Iu Iu

Iur

CN

D-RNCS-RNC

Iu Iu

Iur

CN

RNCRNC

Iu Iu

Iur

SRNS relocation SRNC anchoring

SRNC Anchoring not as such

standardised mobility methodCan lead to limited mobility at the border

between RNCs of different vendors

But can be implemented by applying

undefined set of standardised features

SRNS Relocation standardised

mobility method

3GPP options to

use MM

Anchoring supported in

Nokia SRNC only for CS RT

and PS NRT services within

Cell_DCH

Keep Iur resources

until release of the

call

Inter-RNC mobilityRelocation and anchoring

Release Iur resources

after drop of last

source RNC cell

Inter-RNC mobility




Inter RNC mobility

Relocation procedure and failure detected differently between source

and target RNC

Target RNC

– Target RNC sees relocation as incoming RRC connection setup with causeSRNC relocation

– Setup, access and active counters incremented both for RRC and RAB

– In case of failures, corresponding setup and access failure counters are

incremented both for RRC and RAB (failure due to RNC)

Source RNC

– Source RNC starts relocation procedure and releases finally RRC connectionwith cause SRNC relocation

– Active release counters incremented both for RRC and RAB

– In case of failures, corresponding active failure counters are incremented both for

RRC and RAB (drop due to RNC)

Incoming and outgoing relocation

Inter-RNC mobility – successful relocation




RNC

Source

RANAP Relocation required

Core RNC

Target

RRC UTRAN mobility info

UE

Signaling and trigger

RNSAP Relocation commit

Inter RNC mobility successful relocation

RANAP Relocation request

RANAP Relocation request ACK

SETUP PHASERRC setup attempt

RRC setup failure due to RNC

ACCESS PHASE

RRC setup completeRRC access failure due to

radio or RNC

RANAP Relocation command

RANAP Relocation detect

RRC UTRAN mobility info confirm

RANAP Relocation complete

RANAP Iu release

RANAP Iu release complete

ACTIVE PHASERRC release due to relocation

Inter-RNC mobility – possible failures




Inter RNC mobility possible failures

Target RNC does not respond to RANAP relocation request or RNSAP relocation

commit (internal RNC or Iu problem)

Target RNC responds with RANAP relocation request NACK (no resource available

in target RAN)

Synchronization failure on Iur (transmission problem)

UE does not respond to RRC UTRAN mobility info (air interface or UE problem)

Synchronization failure on radio link (air interface problem)





Call drop (RAB, DCH, radio link)

Mobility (SHO, ISHO, relocation)

HSPA drop


HSDPA drop – analysis process




Top N cells

Pre-emption

High drop

ratio

Transition to

DCH due to

mobility

Transition to DCH

due to other

reason (e.g. type

of RAB)

Drop due to

radio

No action

needed

Normal Release

(No action

needed)

Normal Release

(No action

needed)

Normal Release

(No action

needed)

High SCC Failure

Rate

No

Yes

Yes Yes Yes Yes

No NoNo

Check CQI distributionand Ec/Io distribution for

coverage issue

Check HSDPA mobilitysettings (SHO and SCC

parameter)

No

Drop due to

other reason

No

Check RB reconfiguration failure

rate (UE response with failure or

no response at all)

Check ICSU log (UE type)

Yes

p y pFlow chart

Yes

HSDPA drop = soft drop

RNC tries to shift UE to Cell_FACHRNC tries to keep RAB running

HSDPA drop – analysis process





p y p

Majority

of DCH

drops dueto radio





Call drop (RAB, DCH, radio link)

Mobility (SHO, ISHO, relocation)

HSPA drop


Serving Cell Change SCC – successful procedure




UE

RRC: Measurement Report (e.g. Ec/Io)

NBAP: Radio Link Reconfiguration Prepare

BTS

Source

BTS

Target

RRC: Radio Bearer Reconfiguration

RNC

RRC: Radio Bearer Reconfiguration Complete

g g pSignaling and trigger for inter BTS SCC

NBAP: Radio Link Reconfiguration Ready



ALCAP: Establish Request

ALCAP: Establish Confirm

NBAP: Radio Link Reconfiguration Commit


SCC – successful procedure




UE

RRC: Measurement Report (e.g. Ec/Io)


BTS

Source

RRC: Radio Bearer Reconfiguration

RNC

RRC: Radio Bearer Reconfiguration Complete

Signaling and trigger for intra-BTS SCC


ALCAP: Establish Request

ALCAP: Establish Confirm


Setup of transport resources

only needed in case of inter-

WAM mobility

SCC – window settings




Addition

window

4dB

CPICH 1 R99

CPICH 2 R5/6

EC /I0

timeSHO for A-

DCH initiatedPeriodic

reports

Serving cell change

initiated

periodic reports as

long UE in SHO area

HSDPAServCell WindowRNC, 0..6, 0.5, 2 dB

Addition Time

Drop

window

6dB

SCC with associated DCH

CPICH 2 activ eCPICH 1 no t

act ive anymore

SCC – window settings




Addition

window

CPICH 1

CPICH 2

EC /I0

timeJust periodic

reports

Serving cell change AND

active set update initiated

periodic reports as

long UE in SHO areaAddition Time

HSDPASRBWindow

RNC, 0..6, 0.5, 1 dB

HSDPAServCell Window

RNC, 0..6, 0.5, 2 dB

SCC with F-DPCH

CPICH 2 NOT

act ive yet

CPICH 2 acti ve

together with SCC

Modified (smaller) SCCwindow used, as no SHO

with event 1A yet

SCC – analysis process




Top N cells

SCC Fail BTS

High SCC failurerate

SCC Fail ACSCC Fail

TransmissionSCC Fail UE

SCC Fail

Others

No actionneeded

Check BTS HW

Channelization

code

congestion ?

DL power congestion

?

Check AAL2

Iub resource

congestion

Check RB

reconfiguration

Failure rate

Check RNC

internal transport

resources (DMPG)

ICSU

troubleshooting

No

Yes

Yes Yes Yes Yes Yes

No No NoNo

No

SCC Fail

Prevention

timer

Check

HSDPACellChang

MinInterval

parameter

Check

Maximum

number of

HSDPA users

No

No

Yes

Flow chart

SCC – analysis processF il l




HSPA started


Many serving cell change failure

causes due to AC





1. Determine main failure cause contributor

2. Check HSDPA setup performance of target cells if SCC failure rate of source

cell is high

3. If high SCC failure rate due to admission control

• In case of power congestion check HSDPA power settings (in case of dynamic power R99

should not throw out HSDPA completely)

• Otherwise check number of HSDPA users

4. If high SCC failure rate due to BTS

• Usually NOT lack of baseband resources (associated DCH already in SHO before SCC, for

HSDPA baseband is reserved per scheduler)

• Check radio link reconfiguration failure causes of target cells

• Check BTS hardware





5. If high SCC failure rate due to UE

• Check RB reconfiguration failure rate

• Check air interface performance

• Check ICSU log for UE type monitoring

6. If high SCC failure rate due to transport

• Evaluate number of reconfiguration failure due the transmission

• Check for number of individual AAL connections

• Check for frame delay or even frame loss due to congestion

7. If high SCC failure due to other reason

• Check RNC internal transport resources usage (DMPG)

• Requires ICSU troubleshooting

SCC – User data over Iur




RNC

RNC

AB

C

AS={A,B,C}

Normal SHO for

A-DCH

AS={A,B,C}

C= best cell,

HS-DSCH data

over Iur

AS={C}Trigger

relocation

Previous releases up to RU10

• Inter-RNC HS-DSCH serving cell change and relocation at the same time

• No flow of user data over Iur

• Switch back to DCH not required, but nevertheless interruption of HSDPA service by themobility procedures

Since RU20

• First inter-RNC serving cell change, then relocation

• Flow of user data over Iur, when inter-RNC neighbor becomes new serving cell

• HSDPA service not interrupted by the mobility procedures

3G RANOP RU40 NSN Performance Monitoring

Documents

Transcript of 3G RANOP RU40 NSN Performance Monitoring