dcr voice --analysis

5/22/2018 Dcr Voice --Analysis.

1/23

1 Nokia Siemens Networks DNO Optimization Processes / JC Ejarque

DROP CS VOICE AnalysisFailure counters


2/23

2 Nokia Siemens Networks RANOP2 - M2/January 2011

RAB Reconfiguration Actions

(Reconfigure RAB resources in RNC, BTS, Transport)

BTS

UE 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 SETUPfails 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 ACCESSfails 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 ACTIVEfails 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 failedRAB 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 CommonRAB Setup & Access and Active


3/23

3 Nokia Siemens Networks

RETAINABILITY CONCEPT

DNO Optimization Processes / JC Ejarque

Retainability is the ability of a service to be keptonce it was accessedunder given

conditions for a requested period

of time. In other words, it is the probability that a service, once obtained, will continue to be

provided under given conditions for a given time duration.

Target is to get a 100% Retainability, i.e., all connections maintained until their normal release.

Poor Retainability is typically due to

Handover performance (soft/softer/Iur/IFHO/IRAT) and missing neighbor cell

UL/DL imbalance

Incorrect parameter settings (power, admission, release)

Congestion

Radio environment impact (corner effect, fast Ec/No drop, Pilot pollution, etc)

Node Hardware/Software failure

Iub (E1s) Congestion

Retainability is to be monitored independently for the different RAB types (e.g. Speech, CS

Video, PS Interactive R99, PS Interactive HSDPA, etc.) as in certain situations only one of the

RAB types will be affected.


4/23


Retainability Rate - RR (%)


Based in statistical counters, it is possible to count every time a RAB is normally

released, e.g.:

Call ended by UE or user control

(user generates a disconnect towards the CN or UE Signaling Connection Release)

Call ended because of any problem or action on the other part

(the monitored user receives a disconnect from the CN)

Connection ends because of user inactivity (PS calls only)

Connection ends because the call is successfully transferred to another system

(IRAT handover)

and abnormally released (= DROP):


5/23


RETAINABILITY -II


Normal Releases (of NSN Packet Call) counters are updated, for example,

due to inactivity or RAB release. Thecounters are also updated in case of outgoing SRNC relocations, outgoing

Inter-RNC hard handovers, Inter-System hard

handovers, and state transitions to DCH (0/0)/FACH/PCH.

Abnormal (=Failure) Releases (of NSN Packet Call) counters are updated incase of Radio Link failures, preemption

and RT over NRT. In case of RL failure, all radio links go out of sync state during

a packet call, and as a consequence,

the dedicated user plane allocation is released and the call is dropped into the

Cell_FACH or Cell_PCH state. The counter for

other failures is updated when a packet call is released due to some other

failure cause than a radio link failure, pre-emption, or

RT over NRT


6/23


PERFORMANCE ANALYSIS


RADIO: Radio coverage issues:

Uplink problems

Downlink problems

BTS: Mobility issues:

Handover failures

Missing neighbor relationsIRAT/IF handover issues

PRE-EMPTION: Capacity issues

Other faults (Iu, Iur, UE, Unspecified Errors, RNC).


7/237 Nokia Siemens Networks

PERFORMANCE ANALYSIS--II


Radio Coverage Issues

Any condition related to the radio links propagation that can lead to lose the radio

synchronization either from the UE

side (DOWNLINK) or from the Node B side (UPLINK).

Typically the problem is due to high path loss and/or interference.

Typical reasons for uplink problems:

High pathloss: UE is too far from the site or the propagation is blocked by

obstacles. This condition could be checked by

evaluating some environment indicators

High UL interference: the RBS cannot receive the UE because of high UL

interference. This condition can be checked by UL RSSI monitoring counters

:

.



Downlink problem




COVERAGE INDICATORS


Primary Straight Indicators

CPICH RSCP (the signal strength of the pilot channel) Samples at low level (



CPICH_ECNO_CLASS




Mobility Issues


Mobility IssuesThis Intrafrequency HO, Interfrequency HO (IFHO) and IRAT HO, in those aspects with

impact in Retainability:

Soft/Softer Handover failures

Missing neighbor relations

IRAT Handover failures

IF Handover Failures

When UE in connected mode moves within a WCDMA carrier it should always stayconnected with the best cells,

otherwise:

The downlink connection quality will deeply decrease because of the interference of the

strongest (non-used) cell. (Each

cell acts as interferer for the others)

The UE shall generate high UL interference in the closest (non-used) cell.

NODEB



Soft/Softer Handover Failures


Most common reason to have handover failure is because the target cell cannot

accept incoming call due to admission block or failure in other resources allocationfailure (e.g. transport or DL channelization code).

Also the RL Setup or RL Addition procedures may fail (NBAP Radio link Setup

Failure / NBAP Radio link Addition Failure received) or the Active Set

Update procedure fails (RRC Active Set Update Failure received) or Active Set

Update procedure times out in the UE.



IF Handover Failures


Inter-Frequency HOs are also hard handovers. Also here the

possibilities are: the UE succeeds in handover to the target carrier

(Successful IF HO)

the UE fails in getting the target carrier and comes back to the original

carrier (IF HO Failure)

A correct definition of neighbors is critical for both IRAT and IF HO.

For IF HO the Neighbors definition could be even more difficult:

Isolated or border second layer cells could have a very large and

unpredicted coverage extension because they are not

limited by the surrounding

On the other hand the target WCDMA cells will be only available in thearea where they are the best, in other positions they will be really

interfered and cannot be used

the UE fails in getting the target carrier and also fails to get back to the

original carrier (lost call = IF drop)



RAB SETUP PHASE



15/2315 Nokia Siemens Networks RANOP2_M1/January 2011

RAB Success Ratio (Drop call rate)

Call is dropped if one (or more) of the following RAB, RB or RL, drops.

PS call drop is different than the other call type drops, RAB service canstill exits even if the RB and/or RL drops

Poor RAB success ratio could be reason of coverage or interferenceissues, SHO problems, missing neighbour, inter RNC problems, just tomention some

Call Drop rate (CDR) is calculated based on RAB activation failures, it canbe defined separately for different services

Normal RAB releases are taken into account

Drops during the signalling are not included

RNC_231d RAB success ratio, AMR


16/2316 Nokia Siemens Networks RANOP2 - M2/January 2011

Call Drop Analysis OverviewTop (N) drops

Cell and its Neighbour

Cells availabilityAlarms/Tickets

Configuration &

Parameter audit

SHO

Success

Rate 40 %

ISHO

Success

Rate < 90%

RF and ISHO neighbour

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

2G Investigation : TCH

blocking or TCH seizure

failure (interference)

NO

YES

YES

YES

NO

YES

NO

YES

YES

SHO

ISHO

Top

issues


17/2317 Nokia Siemens Networks RANOP2 - M2/January 2011

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 failurecontributor (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 adjacencycounters (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 andMSC database consistency audit, check alarm of reference clock in 3G or in2G, check 2G TCH congestion

Check RRC Drop ISHO RT / NRT


18/23

18 Nokia Siemens Networks RANOP2 - M2/January 2011

Call Drop analysis

5. Detecting DL or UL path loss problem if RAB drop due to radio (dominant call

drop cause > 50%) Check ASU failure rate (UNSUC_ASU) which link to NO RESPONSE FROM

RLC

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)


19/23


RAB & RRC Active Failures

RAB and RRC active failure reasons:

RNC Internal BTS

UE

Radio Interface

Iur

Iu

Ciphering

Integrity check

RAB and RRC normal release:

RAB active complete

Pre-emption

SRNC Relocation HHO, ISHO, GANHO

Unspecific error in CN

UE RNC

RAB Assignment Request (setup)

CORE

Radio Bearer Setup

RAB Assignment Response

Radio Bearer Setup Complete

RAB Assignment Request (release)

Iu Release Command

RAB Assignment Response

Iu Release Request

RANOP2 - M2/January 2011


20/23


R5 : RAB active failures - Voice



21/23


FINAL IMP COUNTER



22/23

22 Nokia Siemens Networks /

DROP CS VOICE :MAJOR COUNTER

For the RAB Active phase, the majority of failure causes are:

RAB Active Fail due to Radio

Basically refers to coverage issues. L1 Synchronization needs to be verified.

Check Ec/No distribution for bad coverage. SHO and ISHO KPI to be verified

Assessing neighbor list plan and visualization check with map.

Check for missing neighbours, GSM frequency plan, neighbour RNC and MSCdatabase consistency audit,

check alarm of reference clock in 3G or in 2G, check 2G TCH congestion.

Measures to improve coverage such as RF tuning or parameters fine-tuning can becarried out.

RAB Active Fail due to UEMeasure Physical Channel Reconfiguration Failure Rate


23/23


Thank you


dcr voice --analysis

Documents