03 Performance Monitoring

8/16/2019 03 Performance Monitoring

1/106

Soc Classification level

1 © NSN Siemens Networks RN31573EN30GLA0

Performance Monitoring

3G RANOP RU30


2/106



Course Content

KPI definition

Performance monitoring

Air interface optimization

Traffic monitoring

Capacity enhancement


3/106



Module Objectives

At the end of the module you will be able to:

• Describe 3G RAN performance monitoring hierarchy

• Describe the mechanisms for call analysis related to• Busy hour

• Paging, RRC and RAB setup and access failure

• Session setup failure for NRT and HSPA

• SHO, ISHO, relocation and SCC failure

• RAB, DCH, radio link and HSPA drop• List possible reasons for failures and improvement activities


4/106



KPI analysis hierarchies

Call setup (busy hour, paging, RRC, RAB, PS session)

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

HSPA setup

HSPA drop

HSPA mobility (SCC, HSUPA SHO)



5/106



Available data can be classified as in the figure below

There is no point to look at detailed data if the “bigger picture” is not clear

More details

More

understandingMore

complexity

More cost and

time in

acquisition

KPIs (e.g. CSSR, CDR by Traffica)

Service level

(RRC / RAB / PS session)

SHO SCC IFHO ISHO

Signalling (RRC, NBAP, RNSAP, RANAP)

Subscriber trace, ICSU logs (NSN internal use only)

Cell resource (TCP, RTWP, codes)

BTS / Iub / RNC resources

Interface trace and probe statistics

KPI analysis hierarchyPerformance data hierarchy


6/106



Availability of neighbour cell

Missing adjacency has impact both

on serving and neighbouring cell

Iub

WBTS

KPIs and counters

detect faults at different layers

- Handover performance

- Traffic

- Cell resources

- Iub signalling

- Cell availability

- Failures due to Radio, BTS, transport

KPI analysis hierarchyCell and cluster specific performance


7/106



Complexity of performance data increases with number of cells in the network

Almost all data have to be analysed at cell or WBTS level

But evaluation over time and comparison between large areas (cities, RNCs)still required

• Cell Availability

• Failures due to Radio, to BTS, to transport

• Handover Performance• Traffic

• Cell Resources

• Iub Signalling

Some data better analysed at RNC level

Here only time evolution and RNC comparison are useful

• Failures due the RNC, Iu, Iur

• NAS and relocation signalling

KPI analysis hierarchyCell and cluster specific performance


8/106



• Too big lists of results will irritate consultants

• Main impacts must be visible and manageable for hands on task• Different tables of different data warehouse must be verifiable

• Data / KPI benchmark should be easy

List top 10-20 worst cells

E.g. those of highest CDR

KPI analysis hierarchyAnalysis priority

Cell ID CDR/%


9/106



Few bad cells (here 3 of 90)

cause already about ¼ of all

drops

Quick fault diagnostics due to priority of worst cells

KPI analysis hierarchyHighest analysis priority for cells of highest failure rate


10/106



Either total number of failures or failure rate (%) can be used

• Total number of failures directly proportional to loss ofincome for operator

• Cell with high failure rate might not have high priority, iftotal traffic is low

To reach more uniform performance

• Consider statistics with some periodicity large enough (e.g.per month)

• Consider filter requesting minimum number of attempts /failures per cell depending on network traffic (reducestatistical fluctuations)

KPI analysis hierarchyHighest analysis priority for cells of highest failure rate


11/106





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

HSPA setup

HSPA drop




12/106



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)

Busy hour on the basis of traffic sum

RT and NRT summed every hour

Each counter represents product bit rate * allocation duration

Hour with maximum value taken as BH

0 24 h12 h

Traffic sum RT / NRT

e.g. by NetAct

1 h

1 h

1 h

1 h

BH

CSSR

CDR

Call setup – busy hour


13/106



Busy hour on the basis of data volume (example on RNC level)


Time / h

Data volume / GByte


14/106



Voice, R99 NRT and HSPA peak traffic can happen at different times

Blocking of specific service not necessarily happening during BH based ontraffic sum

• In loaded networks CSSR taken at weekly BH is relevant

• Failures originate mostly from congestion (Iub, BTS HW (CEs), radio)

• Target call blocking probability designed for BH

• In unloaded networks CSSR taken at weekly BH may not yield the hour with

highest blocking (NRT traffic is taken into account as well as RT one)

On cell level 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(ongoing operation, system failures, sleeping cells, alarms etc.)

Busy hour daily or weekly



15/106



IuB

Air Interface WBTS HW Resources Transport

UL interference

DL transmisson power

DL Codes

FSP/ WSP capacity (N*) E1 capacity / AAL2 or IP

RLC/MAC

DSP processing

RNC

During call setup (RRC, RAB, PS session)

several resource areas are checked and

physical / logical resources allocated

Resource checks

Call setup – bottlenecks


16/106



UE BS RNC CN

PagingPaging type 1

RRC connection request

Paging types

Call setup – paging

UE in RRC idleE.g. incoming RT or NRT call

Paging

Paging type 1

RRC cell update

Paging

Paging type 2

RRC cell update

UE in Cell_PCH or URA_PCH

E.g. inactive NRT RAB andincoming voice call

UE in Cell_FACH or Cell_DCH

E.g. active NRT RAB andincoming voice call

Incoming dataPaging type 1

RRC cell update

UE in Cell_PCH or URA_PCH

NRT RAB inactive, but still dataarriving from core network

RNC pages UE to take the data

C

N i

n i t i a t e d

R N C i

n i t i a t e d


17/106



Paging channels


• PCH with 8 Kbit/s

• Standard implementation

• With 80 bit per page message up to 100 pages / s supported per cell

• Has SF256

• Default power setting 5 dB below CPICH (28 dBm = 0.63 W, 3% of

maximum power of 20 W cell)

• PCH with 24 Kbit/s

• Optionally available since RU20

• With 80 bit per page message up to 300 pages / s supported per cell

• Has SF128 → Maximum of 14 codes for HSDPA, if additionally HSUPA

with 2ms TTI in use

• Default power setting 2 dB below CPICH (31 dBm = 1.26 W, 6% of

maximum power of 20 W cell)


18/106



Code tree with 24K PCH


Cch,256,0

Cch,256,1

Cch,256,2

Cch,256,3

Cch,128,4

Cch,128,5

CPICH

P-CCPCH

AICH

PICHCch,64,1

Cch,256,14

S-CCPCH 1 FACH

E-AGCH 10 ms

HS-SCCH

E-HICH & E-RGCH

S-CCPCH 2 PCH with 24 K

Cch,128,6

Cch,16,0

Cch,256,15

E-AGCH 2 ms

HSUPA with 2ms TTI requiresadditionally fractional DPCH

For F-DPCH no place on firstsub-tree any more

But loss of 1 HSDPA code notcritical

Probability, that air interfaceallowes 15 codes, usually lessthan 1:1000

Loss of 3% of maximum cellpower by 24K PCH much moresignificant


19/106



Paging monitoring


Check number of pagemessages forwarded to PCH

(M1006)

Paging Type 1 Att CN Orig

Messages originating fromcore network

Paging Type 1 Att RNC Orig

Messages originating fromRNC

Check number of pagestransmitted by PCH

(M1000)

Ave PCH Throughput /

PCH Throughput Denom 0 =

Throughput on PCH

Throughput / 80 Bit =

Number of pages per second

Difference

Pages lost by PCH blocking

Check number of responsesto paging

(M1006)

Difference

Low air interface performance


20/106


21/106



RRC connection setupRAN resources reserved forsignaling connection between UEand RNC

RRC accessConnection between UE and RRC

RRC active UE has RRC connection

If dropped, also active RAB dropped

RAB setup Attempts to start call

RAB setup access

Connection between UE and core

RAB active phaseUE has RAB connection

CSSR affected if any of the following

events takes place

• RRC Connection Setup Fail

• RRC Connection Access Fail• RAB Setup Fail

• RAB Setup Access Fail

Setup

Complete

Access

Complete

Active

Complete

Setup Access Active

A t t e m p t s

Setup failures(blocking)

Access failures

A c c

e s s Active

Release

Active

FailuresRRCDrop

S u c c e s s

Phase:

RRC and RAB

Call setup - phases


22/106



[RACH] RRC Connection Request

UE Node B RNC

ALCAP ERQ

NBAP RL Setup Request

[DCH] RRC Connection Setup Complete

L1 Synchronisation

Start TX/RX

Start TX/RX

[FACH] RRC: RRC Connection Setup

NBAP RL Setup Response

AC to check to acceptor reject RRC

Connection Request

ALCAP ECF

NBAP Synchronization Indication

RRC Connection Setup

phase

RRC Connection

Access phase

RRC Connection Active phase

Allocation of UTRAN

resources

Waiting for UE reply

M1001C0

Counter

M1001C1

M1001C8

Three phase for RRC

Call setup – successful RRC establishmentSignalling and trigger

M1001C8

M1001C0

= successful RRC

establishment


23/106



BTSUE RNC CN

RRC connection Request

RRC connection Setup

RRC SETUP phase

(Resource Reservation in RNC)

RRC ACCESS phase

(RNC waits for Reply from UE)

RRC connection Setup Complete

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

UE does not reply to RRC CONNECTION SETUP message with RRC

CONNECTION SETUP COMPLETE message within given time

BTS reports radio link synchronisation failureRNC internal failure occurs

RRC SETUP fails if some of needed resources (RNC, BTS, air,

transport) are not available

When RRC setup failure occurs the RNC sends 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 RNC send RANAP IU

RELEASE REQUEST to all involved CNs and waits for RANAP IU

RELEASE COMMAND message(s)

RRC ACTIVE release cause NOT indicating a drop can be either

Normal release

IFHO / ISHO

Relocation

Pre-emption

Call setup – failure of RRC establishmentFailure causes


24/106

C ll t f il


25/106



RRC or RAB setup failure can be due to

• Coverage or interference• Capacity

– AC for radio capacity issues (UL load, DL load, DL spreading codes)

– BTS for channel element (FSM or WSP) capacity issues

– TRANS for Iub capacity issues

• RNC problem – RNC fault – Failure of incoming relocation

Call setup failureFailure overview

C ll t RRC t f il


26/106



Call setup – RRC setup failureFailure cause example

Dominating failure causeduring RRC setup due to

BTS

Check e.g. channel cards

RRC t f il l i


27/106



RRC_CONN_STP_FAIL_AC

• Check UL interference, DL power and code occupancy (M1000)

• UL power spikes → Disable UL admission control if number of failures is critical

RRC_CONN_STP_FAIL_BTS

• Evaluate NBAP counters (radio link setup failures) for troubleshooting BTS resources (M1005)

• Check BTS configuration in terms of WAM and CE allocation – use channel element counters in

order to evaluate lack of channel elements (M5001)

• Expand the capacity or decrease the traffic offered to the site

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

RRC setup failure analysis

RRC set p fail re anal sis


28/106



RRC_CONN_STP_FAIL_TRANS

• Evaluate number of reconfiguration failures due the transmission

• Check COCO configuration

• Use AAL2 Mux in case of two WAM

• Expand the capacity or decrease the traffic offered to the site

RRC_CONN_STP_FAIL_RNTI ALLO FAIL

• RNC decides to reject RRC connection request due to RNTI allocation

failure caused by RRMU overload

RRC_CONN_STP_FAIL_RNC

• Typically RNC fault or incoming SRNC relocation failure• Requires ICSU log tracing if no RNC fault or SRNC relocation problem

RRC setup failure analysis

Call setup RRC setup optimization


29/106



• Network access of UE via Cell_FACH

• RACH and FACH transport channels used for call setup

• Call setup on CCH is faster than on DCH

• All time consuming procedures move to Cell_DCH

• Depending on Ec/Io and CCH load/power status, UE moves to Cell_DCH

RRC Idle RRC Idle

• no UE Location

Information

in UTRAN

• only LAI / RAI

in CN

• no data transfer

possible

• RRC Connectionestablishment via

RACH/FACH

signaling

New

Establish

/ Release

RRC

Connection

Cell_PCH

• UE’s cell known• UE to be paged (DRX functionality PICH)

Cell_FACH• common channel

allocated (FACH,RACH, CPCH, DSCH)

• UE’s cell known

Cell_DCH• DCH allocated

• UE’s cell known

URA_PCH• similar to Cell_PCH

• no Cell Update, but URA Update

Connect ion mode Connect ion mode

With I-phone

not possible

Quicker access

via RACH/FACH

for UE

Common channel setup

Call setup – RRC setup optimization



30/106



UE BS RNC CN

CM service request

RAB ass. req.

Radio Bearer Setup

Radio Bearer Setup Complete

RAB ass. resp.

RAB SETUP PHASE

RAB ACCESS PHASE



RRC Connection RequestRRC Connection Setup

RRC Connection Setup Compete

Security procedures

RRC SETUP PHASERRC ACCESS PHASE

No RL setup

No CAC

No AAL setup

No RL setup

No CAC

No AAL setup

• Cell_FACH state used for subsequent signaling

• UE enters Cell_FACH e.g. for pure signaling procedure like LA update

• Traffic Volume Measurements performed in Cell_FACH state

• Cell_DCH used once channel type switching selected DCH or HSPA transport channel



31/106



• Allocation of RACH / FACH or DCH based on establishment cause

received from UE (22 causes)

• Available SRB bit rate on DCH 3.4 kbps or 13.6 kbps configurable

by parameter

• RACH and FACH load continuously monitored in RNC (too highload prevents common channel setup – default = 75% load)

• Air interface quality (CPICH Ec/Io) criteria has impact on common

channel allocation (default Ec/Io ≥ -8 dB required)



Call setup RRC access failure


32/106



L1 Synchronisation

NBAP: Synchronisation Indication

RRC Connection Setup Complete X

UE BTS RNC

XNo L1 synchronization

Failure due to radio

L1 Synchronisation

XUE BTS RNC

No response from UE

Failure due to UE

Cell reselection or directed RRC

setup (no error)

Call setup – RRC access failureFailure definitions

NBAP: Synchronisation Indication

RRC Connection Setup Complete

Call setup – RRC access failure


33/106



Call setup – RRC access failureFailure cause example

Dominating failure cause for RRC access due to radio

But for a few days dominating failure due to RNC

Check e.g. ICSU and DSPs

RRC access failure analysis


34/106



RRC_CONN_ACC_FAIL_RADIO

• Dominant failure cause

• Perform drive test to detect if lack of UL or DL coverage

• UL coverage → tune cell dominance if cause is UL interference

• DL coverage → tune S-CCPCH power if UE does not receive RRC connection setup message

RRC_CONN_ACC_FAIL_MS

• UL coverage → tune cell dominance (CPICH) in order to balance UL and DL (if UL interference not the cause

RRC access failure analysis

Call setup – RRC access optimization


35/106



• Quicker access due to post verification of QoS

• If CPHY-Sync-IND primitive quality sufficiently

good, UE starts 70 ms quicker

• Faults due to radio will decrease, faults due to

UE (post verification) will increase

Node B starts transmitting

Post verificationcheck

40 ms window

UE starts transmittingwith Post Veri f icat ion

UE starts receiving,

mobile is listing on FACH

UE stops transmitting ifverification check fails

10 ms radioframes

UE L1 col lects 40 ms

of qual i ty

measurements

The total delay before UE starts UL

transmiss ion is reduced by 70 ms .

40 ms window

50 ms window

UE starts transmitting

with out Post Veri f icat ion

40 ms window

40 ms window

40 ms window

RRC Connection Access phase

[RRC Connection Setup (FACH)

Fast Layer 1 synchronization

Call setup RRC access optimization

Call setup – successful RAB establishment


36/106



Call setup successful RAB establishmentSignalling and trigger

UE BS RNC CN

CM service request

RAB ass. req.

RL rec. prepare

RL rec. ready

AC

RNC Iub internalresources

AAL2

CACAAL2 sig. ERQ

RAB_STP_ATTEMPTS

Radio Bearer Setup

Radio Bearer Setup Complete

AAL2 sig. ERQ

AAL2 sig. ECF

RAB ass. resp. (success)

RAB_STP_COMPLETE

RAB SETUP PHASE

RAB_ACC_COMPLETE

RAB ACCESS PHASE

Iu CS

RNC internalresources

AAL2

CAC

AAL2 sig. ECF

RAB ass. resp. (failure cause,if resources missing)

Exception: release of the RAB duringSETUP or ACCESSE phase

M1001C66 RAB STP ATT

M1001C115 RAB ACC CPL

RL rec. commit M1001C73 RAB STP CPL


37/106

RAB setup failure analysis


38/106



RAB_STP_FAIL_XXX_AC (not done in case of NRT RAB)

• Check UL interference, DL power and code occupancy

• Evaluate AMR voice and PS 64K code congestion

RAB_STP_FAIL_XXX_BTS

• Evaluate NBAP counters (radio link reconfiguration failures) for troubleshooting BTS resources(M1005)

• Check BTS configuration in terms of WAM and CE allocation – use channel element counters inorder to evaluate lack of channel elements (M5001)

• Expand capacity or decrease traffic offered to the site

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

RAB setup failure analysis


39/106


40/106

RAB access failure analysis


41/106



RAB_ACC_FAIL_XXX_MS

• Evaluate cell resources TCP and RTWP (for example high uplink interference)

• Check radio bearer reconfiguration failure ratio

RAB_ACC_FAIL_XXX_RNC

• Typically RNC fault or incoming SRNC relocation failure

• Requires ICSU log tracing if no RNC fault or SRNC relocation problem

y


42/106

Call setup – PS session setup failure


43/106



Failure cause example

Fault analysis completely analog to RRC and RAB

Many PS RAB setup failure causes

due to UE and AC



44/106





Call drop (RAB, DCH, radio link)

Mobility (SHO, ISHO, relocation)

HSPA setup

HSPA drop


Call drop – analysis process


45/106



Top (N) drops

Serving and neighbourcells availabilityAlarms/Tickets

Configuration andparameter audit

SHOSuccess

Rate < 90%?

Conf OK ?

Site OK ?

ISHOFailures

Iurperformance Investigation Iur

Audit adjacent sites for

alarms, availability,configuration and capacity

TrafficNeighbour performance(use SHO success per adjacency

counters to identify badlyperforming neighbours) and map

3G Cell atRNC

border?

NO

YES

New site ?

Analyse last detailedradio measurements

RF and IFHO neighbouroptimisation

No cellfound ratio

>40 %

ISHOSuccess

Rate < 90%

RF and ISHO neighbouroptimisation

3G cellcovers over acoverage hole

?

3G cell atinter-RNCborder ?

Wrong reference clock(10MHz tuning)

No cell foundratio > 90 %and enough

ADJG

2G Cell Doctor

2G InvestigationTCH blocking or

TCH seizure failure(interference)

NO

YES

YES

YES

NO

YES

NO

YES

YES

SHO

ISHO

Flow chart for RAB

Call drop analysis


46/106



Failure cause example for voice

Many CS RAB drop causes due

to radio and transmission

Call drop analysis


47/106



Failure cause example for PS

Many PS RAB drop causes

due to UE and radio

Call drop analysis


48/106



1. Check high call drop cells and its neighbouring 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 neighbours 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 neighbours (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 analysis


49/106



5. 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 analysisE l f t f i di id l d d ll


50/106



Example for trace of individual dropped call

UE does not find SHO neighbor

Event 1F due to RSCP

UE enters compressed mode

But does not find GSM neighboreither

RT and NRT

Soft drop - DCH


51/106



• RT

• If communication between UE and network interrupted, this will

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


52/106




Two drop cause counters only

Radio

Other

Majority of DCH drops still

due to radio


53/106

Soft drop - radio link failureFailure example – RL deletion by SRNC and DRNC


54/106



Failure example – RL deletion by SRNC and DRNC

> 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




55/106







HSPA setup

HSPA drop


SHO – successful softer HOSignalling and trigger


56/106



Signalling 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 linkaddition failure causes (M1005)

If problem, check air interface

performance

SHO – successful soft HOSignalling and trigger


57/106




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 resourcesneeded (CAC)

If problem, check radio linksetup failure causes (M1005)

If problem, check air interface

performance


58/106

SHO – OverheadConcept and counters


59/106



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

p

SHO – OverheadCell level


60/106


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 average

number of radio linksduring a call

Total time of

all calls

SHO – OverheadCell level


61/106



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


62/106

SHO – OverheadRNC level


63/106


cell A

cell B

3// _ _ _ _ _

2// _ _ _ _ _

/ _ _ _ _ _

/ _ _ _ _ _

/ _ _ _ _ _

/ _ _ _ _ _ _



NRT RT SET ACT IN CELLONE



NRT RT FORSET ACT IN CELLONE

KPI compares effectivenumber of calls with

number of radio links

Call belongs

to cell A only

Call belongs half tocell A and half to cell B

Denominators 1/2/3:

Call with 1 radio linkBelongs 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 toeach active cell

SHO – OverheadRNC level


64/106



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 cell

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

Realistic SHO overhead indicated

SHO – OverheadRNC level example


65/106



Typical target for SHO overhead 40%

SHO per adjacencyConcept and counters


66/106



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

• 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 per adjacencyConcept and counters


67/106



HO_ATTTRA_FREQ_SSHO_ADJ_IN

HO_COMPLTRA_FREQ_SSHO_ADJ_IN _RNCs_per_ADJSSHO_succes

• SHO success per adjacency

• High failure rate (several 10%) → besides RL setup / addition failures and air

interface 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 – successful procedureSignalling and trigger


68/106



UE

RRC: Measurement Report (Event 1F)

RRC: Physical Channel Reconfiguration

RRC: Physical Channel Reconfiguration Complete

BTS RNC

UE put intocompressed mode

RRC: Measurement Control

RRC: Measurement Report

RxLevmeasurements


RRC: Measurement Report

BSIC verification

MSC

RANAP Relocation required

RANAP Relocation command

RRC: HO from UTRAN Command

ISHOexecution

NBAP: RL reconfig. prepare

NBAP: RL reconfig. ready

NBAP: RL reconfig. commit

NBAP: CM command

NBAP: CM command

RANAP Iu release request

ISHO – analysisFlow chart


69/106



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

CongestionHalf Rate in 2G

Ncell ?

Poor GSM

Coverage

CM Start

Not

Possible?

Yes

Check admission

control rejection

TCP and RTWP

Yes

No

ISHO – analysisISHO cause example


70/106



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 – analysisISHO cause example – RSCP under 1F conditions


71/106



Usually very low coverageunder event 1F conditions

Consistent with counterstatistics

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


72/106



Usually acceptable Ec/Io evenunder event 1F conditions

Consistent with counterstatistics

ISHO - analysisISHO failure example – no target cell found


73/106



100% target cell found

Each point represents one cell

80% target cell found

ISHO - analysisISHO failure example – no target cell found


74/106



In several source cells oftenfailure to find target cell

ISHO - analysisISHO failure example – target cell not accessed


75/106



Much less critical to accesstarget cell

ISHO per adjacencyConcept and counters


76/106



_ATTER_SYS_HHOHO_ADJ_INT

_COMPLER_SYS_HHOHO_ADJ_INTG_RNCss_per_ADJISHO_succe

• 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 corenetwork data bases (e.g. CI, LAC and RAC declarations)

• Attempt and success per adjacency monitored by AutoDef SHO

counters (M1015)

3GPP options to

Inter-RNC mobilityRelocation and anchoring


77/106



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 suchstandardised mobility method

Can lead to limited mobility at the borderbetween RNCs of different vendors

But can be implemented by applyingundefined set of standardised features

SRNS Relocation standardisedmobility method

3GPP options touse MM

Anchoring supported inNokia SRNC only for CS RTand PS NRT services within

Cell_DCH

Keep Iur resourcesuntil release of the

call

Release Iur resourcesafter drop of lastsource RNC cell

R l ti d d f il d t t d diff tl b t

Inter-RNC mobilityIncoming and outgoing relocation


78/106



• Relocation procedure and failure detected differently betweensource and target RNC

• Target RNC – Target RNC sees relocation as incoming RRC connection setup with cause SRNC

relocation

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

– In case of failures, corresponding setup and access failure counters are incrementedboth for RRC and RAB (failure due to RNC)

• Source RNC

– Source RNC starts relocation procedure and releases finally RRC connection withcause SRNC relocation

– Active release counters incremented both for RRC and RAB

– In case of failures, corresponding active failure counters are incremented both forRRC and RAB (drop due to RNC)


Inter-RNC mobility – successful relocation


79/106



RNCSource

RANAP Relocation required

Core RNCTarget

RRC UTRAN mobility info

UE

RNSAP Relocation commit

RANAP Relocation request

RANAP Relocation request ACK

SETUP PHASE

RRC setup attempt

RRC setup failure due to RNC

ACCESS PHASE

RRC setup complete

RRC access failure due toradio 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

• Target RNC does not respond to RANAP relocation request orRNSAP relocation commit (internal RNC or Iu problem)

Inter-RNC mobility – possible failures


80/106



RNSAP relocation commit (internal RNC or Iu problem)

• Target RNC responds with RANAP relocation request NACK (noresource available in target RAN)

• Synchronization failure on Iur (transmission problem)

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

• Synchronization failure on radio link (air interface problem)


Call setup (busy hour paging RRC RAB PS session)



81/106






HSPA setup

HSPA drop


HSDPA setup – successful session establishmentSignalling and trigger

UE BS RNC


82/106



Capacity request

RL rec. prepare

RL rec. ready

AAL2 sig. ERQ

Radio Bearer Reconfig.

Radio Bearer Reconfig. Complete

AAL2 sig. ECF

RL rec. commit

session SETUP PHASE

session ACCESS PHASE

AAL2 sig. ERQ

AAL2 sig. ECF

HS-DSCH capacity request

HS-DSCH capacity allocation

After RRC establishment two furtherAAL links are needed for HSDPA

HSDPA setup – analysis processFlow chart


83/106



Top N cellsSetup Fail

BTS

High setup

failure rate

Setup Fail UL

return

Channel

Setup Fail Iub

TransportSetup Fail UE

Setup Fail

RNC internal

Setup Fail Too

Many Users

No action

needed

Check CE

resource usage

at BH

UL powercongestion

?

Check AAL2

Iub resource

congestion

Check RB

reconfiguration

Failure rate

Check RNC

Unit load(DMPG) and

faulty alarms

Check number of

simultaneousHSDPA users

No

Yes

Yes Yes Yes Yes Yes Yes

No No NoNo

No

Lack of CE mainly problem for UL return DCH

For HSDPA CE reserved per scheduler

For associated DCH on DL just 1 CE per user

No


HSDPA setup – analysis process


84/106



Many HSDPA setup failure causes

due to UE, Iub and UE

1. Identify main failure contributor

2 If too many HSDPA users



85/106



2. If too many HSDPA users

• Use licence for more users

• Use dedicated instead of shared scheduler

3. If due to UL DCH

• Monitor UL load

• Check PrxTarget and PrxNoise settings

• Check for intermodulation

4. If due to UE• Check RB reconfiguration failure rate

• Check air interface performance

• Check ICSU log for UE type troubleshooting

5. If due to BTS

Lack of UL channel resources



86/106



Lack of UL channel resources

Check for SHO overhead (all branches must have enough CE capacity if UE is in SHO when HS-DSCH shallbe allocated)

6. If due to Iub transport

Evaluate number of reconfiguration failure due the transmission

Check for SHO overhead (all inter-BTS branches must have enough capacity for associated DCH)

Check for number of individual AAL connections

Check for frame delay or even frame loss due to congestion

With RU20 HSPA transport channels can be allocated directly to users in

Direct resource allocation

HSDPA setup – optimization


87/106



Cell_FACH or Cell_DCH, without waiting for capacity request

• UE must support HSDPA and HSUPA transport channels

• HSDPA and HSUPA must be enabled in cell

• Direct resource allocation always used when F-DPCH allocated to UE

Prior to RU20 for NRT user allocation of DCH 0/0 by AC

• After receiving capacity request, RNC selects channel type

• If no capacity request received by RNC, UE moved to Cell FACH





88/106




Mobility (SHO, ISHO, relocation)HSPA setup

HSPA drop


HSDPA drop – analysis processFlow chart


89/106



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)


needed)


needed)

High SCC Failure

Rate

No

Yes

Yes Yes Yes Yes

No NoNo

Check CQI distribution

and Ec/Io distribution for

coverage issue

Check HSDPA mobility

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

Yes

HSDPA drop = soft drop

RNC tries to shift UE to Cell_FACH

RNC tries to keep RAB running


HSDPA drop – analysis process

Majority of DCH drops due


90/106



to radio





91/106




Mobility (SHO, ISHO, relocation)HSPA setup

HSPA drop


UE BTSS

BTST t

RNC

Serving Cell Change SCC – successful procedureSignalling and trigger for inter BTS SCC


92/106



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

NBAP: Radio Link Reconfiguration Prepare

Source Target

RRC: Radio Bearer Reconfiguration

RRC: Radio Bearer Reconfiguration Complete

NBAP: Radio Link Reconfiguration Ready



ALCAP: Establish Request

ALCAP: Establish Confirm

NBAP: Radio Link Reconfiguration Commit


UE BTSS

RNC

SCC – successful procedureSignalling and trigger for intra-BTS SCC


93/106



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


Source




ALCAP: Establish Request

ALCAP: Establish Confirm


Setup of transport resourcesonly needed in case of inter-

WAM mobility

SCC – window settingsSCC with associated DCH


94/106


Addition

window

4dB

CPICH 1 R99

CPICH 2 R5/6

EC /I0

timeSHO for A-

DCH initiated

Periodic

reports

Serving cell change

initiated

periodic reports as

long UE in SHO area

HSDPAServCell Window

RNC, 0..6, 0.5, 2 dB

Addition Time

Drop

window

6dB

CPICH 2 activeCPICH 1 no t

act ive anym ore

HSDPAS C llWi d

SCC – window settingsSCC with F-DPCH


95/106


Addition

window

CPICH 1

CPICH 2

EC /I0

timeJust periodic

reports

Serving cell change AND

active set update initiated

periodic reports aslong UE in SHO areaAddition Time

HSDPASRBWindow

RNC, 0..6, 0.5, 1 dB

HSDPAServCell Window RNC, 0..6, 0.5, 2 dB

CPICH 2 NOT

act ive yet

CPICH 2 active

together with SCC

Modified (smaller) SCC

window used, as no SHOwith event 1A yet


96/106

SCC – analysis processFailure cause example


97/106



HSPA started

Many serving cell change failure

causes due to AC


98/106

5. If high SCC failure rate due to UE

• Check RB reconfiguration failure rate

Ch k i i t f f

SCC – analysis process


99/106



• Check air interface performance

• Check ICSU log for UE type monitoring6. 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

RU20 (standard feature)

• In SHO area HS UE sends periodic measurement reports to RNC

• RNC evaluates reports to decide about serving cell change

SCC – RU30 Enhancements


100/106



• Problems

• High signaling traffic due to periodic reporting• If F-DPCH used, serving cell change command of RNC might not be decoded by UE, as SRB on

HS-PDSCH less robust than on DPDCH

RU30 (enhanced feature)

• No periodic reporting in SHO area any more, but serving cell change triggered by event1D

• Better robustness for SRB on HS-PDSCH

• RNC sends pre-information about potential target cells during active set update already

• Serving cell change commands transmitted both in source and target cell

Pre-configuration

• Serving cell change command transmitted both in source and target cell

• In source cell via HS-PDSCH



101/106



• In target cell via HS-SCCH

• UE informed during active set update about• Codes used for HS-SCCH in target cell

• Activation time offset (time to monitor target cell after sending event 1D report)

UE Source Node B Target Node B SRNC

RRC: Measurement Report (event 1a or 1c)

RRC: Active Set Update Complete

RRC: Active Set Update (Pre-configuration Info)

NBAP: Radio Link Setup (Pre-configuration Info)


Execution

• Serving cell change initiated by UE with event 1D report (then UE starts to monitor targetcell)

Aft b th d t t ll d f i ll h t th UE t



102/106



• After both source and target cell are prepared for serving cell change, to the UE are sent

• RRC radio bearer configuration from RNC as usual (via HS-PDSCH in source cell)

• HS-SCCH order from target Node B (via HS-SCCH in target cell)

• If UE detects HS-SCCH order only, it still goes to target cell

• The UE informs the RNC about the completion of the process with RRC radio bearerreconfiguration complete

UE Source Node B Target Node B SRNC

SCC Evaluation

RRC: Measurement Report (event 1d CFN)



103/106



RRC: Measurement Report (event 1d, CFN)

SCC Decision

NBAP: Radio Link Reconfiguration Preparation

NBAP: Radio Link Reconfiguration Preparation



L1: HS-SCCH Order


UE moves to Target Cell


RNC re-directs application data

Event 1D

• UE uses event 1D to inform RNC that there has been a change of the best cell in the activeset

• Event 1D triggered if following equation satisfied during time interval defined by time to



104/106



• Event 1D triggered if following equation satisfied during time interval defined by time-to-trigger

MeasNotBest + CIONotBest ≥ MeasBest + CIOBest + Hyst / 2

• If equation simultaneously fulfilled for more than one primary CPICH, UE reports only oneevent 1D, triggered by best primary CPICH

CPICH 1

CPICH 2

Measured EC /I0

timeEvent 1Dreport

Hyst / 2

Serving cellchange executed

Time to tr igger Cell indiv idualoffset CIO

Event 2D and 2F

• Usually events 1F and 1E to initiate and cancel HHO process due to lack of RSCP or EC /I0

• With SHO events and events 1F and 1E already maximum number of intra-frequency eventsallowed by 3GPP achieved, so that event 1D cannot be offered any more



105/106



allowed by 3GPP achieved, so that event 1D cannot be offered any more

• Events 1F and 1E therefore replaced by events 2D and 2F

• Events 2D and 2F triggered by intra-frequency measurements, but nevertheless classifiedas inter-frequency events

• Event 2d: Estimated Quality of the current RF carrier is below a Threshold

• Event 2f: Estimated Quality of the current RF carrier is above a Threshold

Measured EC /I0

time

Event 2D

ALL active cells bad

Enter compressed mode

2F thresho ld

2D threshold

Event 2F

One active cell acceptable again

Leave compressed mode

SCC – User data over IurPrevious 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 the


106/106



RNC

RNC

A

B

C

AS={A,B,C}

Normal SHOfor A-DCH

AS={A,B,C}

C= best cell,HS-DSCH dataover Iur

AS={C}

Triggerrelocation

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 neighbour becomes new serving cell

• HSDPA service not interrupted by the mobility procedures

Documents

03 Performance Monitoring