call failure analysis v3 0301

8/4/2019 Call Failure Analysis v3 0301

1/23

17/04/2012

AIRCOM International

toOrange

Drive test Call Failure Analysis


2/23

17/04/2012

Presentation Outline and Status

Pilot

Methodology

Net. IssuesServices

Key

Counters Alarms Drive DataNeighbours

Performance

RRC Access

SHO

ISHO

RRC Stp Access

CommonAlarms

CommonFailures

Analysis

CM Service

Test Nos

Script bugs

CC Disc

Power Spikes

HC Failures

6650 ISHO

RRC Active

New

Draft

Complete

Inter RNC HO

TCH/BCH


3/23

17/04/2012

Shows how to find network problems from failures observed during adrive test from the collected log files

Failures:

Call Setup failure Different phases being analysed

Dropped calls Main Reasons analysed

This Presentation


4/23

AIRCOM International 2004

Successful Call Attempt Layer 3 Messages


5/23


Before Call Attempt - 1

Most important factor when a mobile is making an attempt is to ensurethat the signal received is adequate to make that attempt

There should be sufficient 3G coverage (Ec/Io RSCP) in order to make a

successful attempt (not a great Path Loss)

Mobile sends RRC Connection Request message while the reception ofRRC Connection Setup does not take place.

Two possibilities

Node B (cell) doesnt receive RRC Connection Request message

UE does not receive RRC Connection Setup message due toexcessive path loss

The problem here is genuine coverage so it is important to make sureclosest site is transmitting properly or alternatively propose a new one

A cell can only covera certain area


6/23


Before Call Attempt - 2

Ensure that when the call attempt is initiated, it is made to the correctcell

Correct cell reselection in idle mode is crucial when the UE is moving

through the 3G network

Neighbours are important in idle mode as well so it is essential to verify thatthe correct relations have been made

Check previous cell on which UE has camped on and verify with the scannerdata which one the new selected cell should be

Camping to overshooting cells can cause problem

Cell availability must also be checked (with scanner measurements) toensure that closest site is up and running

If the closer cell is up and running thenneighbour relations must be checked (ADJSTable for Nokia RAN)


7/23


Call Attempt Starts Mobile is sending RRC Connection Request message

If the cell/RNC doesnt respond with an RRC Connection Setupmessage then the mobile will wait for a specific amount of time, andmake the request again. The total number of requests and the wait timeis specified by the network.

This usually happens because:

RNC is not able to receive the message due to a possible faultysynchronisation on the Iub (DAC Word/10 Mhz)

Sleeping cell problem Service level counters can provide reasons for such failures (RRC ACC

Fail)

Cell can also respond with RRC Connection Reject Message whereusually the cause is congestion due to loading or high UL noise (AC)

Commissioning file check (MHA setting)

External interference Possible increase in Prx target Autotuning deactivated (hanging resource)


8/23


Call Attempt Starts (examples)

RRC Connection Reject

No Response to RRCConnection Request


9/23


RRC Active State

We are in this state when RRC Connection is Active

After that we are in the RAB setup phase

After MM CM Service request message it is possible to receive a MM CMService reject message this would be a Core Network problem

This is an example for a video call


10/23


RRC Active State (2)

After security procedures RAB Setup should take place

When the hardware processing capacity of the BS is reached at a particular timethen NW will send a CC Disconnectwith reason no circuit/channel available.

This is the most common reason for CC Disconnect

Other reason can be failure to allocate channel on the called number (171,150)


11/23


RRC Active State (2)

Following this and the security procedures is that Radio Bearer Setup:

Radio Bearer Setup message sent from the network takes mobile to RAB accessphase at which

UE might fail to receive or even fail to respond this can be either UE problemor coverage problem (usually this never takes place)

UE responds with Radio Bearer Setup complete which takes the call to RABActive phase


12/23


RAB Active State

When RAB Setup is complete then the messages recorded can be thesame as the ones in the middle of a call until the point when CCAlerting message is received on the DL (sometimes immediately

Connect) this message makes the call setup attempt successful From the moment of the RRC Connection Request message until CC

Alerting message usual mobility management activities and messagessuch as Measurement Report and Active Set update can beexchanged between UE and network.

During this time there can be a drop in the radio link the same way as

it can happen in the middle of the call (dropped call) due to lowcoverage, missing neighbours, failed SHO etc


13/23


Failures due to system/other reasons - 1

Call Setup Failures can also occur due to other reasons:

User not responding

In this case there is a DL CC Release message, happens whencalled mobile fails to return a page (user not responding)

Called mobile in 2G (video calls only)

In this case there is also a DL CC Release message with causeservice option not supported this happens when the called mobilehas made reselection to a 2G site

Resource problem

There can be also a CC Release message in the DL with thefollowing reasons:

Temporary failure/resource unavailable

These are usually Node B/RNC/MSC system problems


14/23


Failures due to system/other reasons (examples)

No user responding

User busy

Called UE in 2G (video)


15/23


Failures due to system/other reasons - 2

While being in the call setup phase there can also be an RRCConnection Release message but usually and if there isnt a higherlayer release here, the cause is unspecified

For these Call Setup Failures it is important to have the traces from theRNC (Iub?) as well because it is not an easy task to identify the reasonof this problem from the DT files

Site issues

It is important that there is a record of the sites that seem to have repeatedproblems. These sites usually have failures on every drive that takes placearound their area. In the drive test trace these can be random drops whilecall is during the setup procedure. It is required most of the times that sitevisit takes place in order to ensure that everything is in place. This happenswhen all other sources of information (please read next slide) do not indicatea problem


16/23


Addition of Neighbour

AdequateRSCP?

AdequateEc/Io?

Stronger

cell fromScanner?

CSF

Physical antenna

reconfiguration, Addition ofnew site

RRC CxSetup

received?

RB Setup

received ?

Admission

Control?

Check failurecause (Not radio

related)

Call dropduring setup?

Dropped callprocess

Yes

Yes

No

No

No

Yes

No

Yes

No

No

Yes

Yes

Yes

No

CSF Analysis Summary

Check Node B (Configuration,Iub/10 MHz, DAC Word, CellResource counters, Alarms)

Issue TT, Furtherinvestigation

Check noiselevels,

Autotuning,

ChannelAvailability

RRC CxReject

received?

AdmissionControl?

No

Yes Yes

No

Check noiselevels, Autotuning


17/23


Coverage Related Dropped Calls

Pilot RSCP

Node Bs cannot cover indefinitely

Excessive path loss results in poor Radio coverage levels

UE will lose synchronisation and will not be able to sustain the call

These issues are resolved by:

Antenna tilt/relocation (higher mast or closer to rooftop edge)

New Site

On the call trace these appear usually as either sharp transitions to idlemode or after a high number of measurement reports (requesting weakcells)


18/23


Coverage Related Dropped Calls

Pilot Ec/Io

In order for an adequate connection to take place at least one radio linkneeds to have good Signal to Noise Ratio this is expressed by the Pilot

Ec/Io There are cases where a certain Pilot quality is not achieved due to the

nature of WCDMA technology

Overshooting sites (Pilot Pollution)

Uneven Node B deployment (Pilot dominance)

No clear dominant cell in the areadue to inter-site distance resulting

in poor Ec/Io

Below -16.0 (0)

>= -16.0 to < -14.0

>= -14.0 to < -12.0

>= -12.0 to < -10.0

>= -10.0 to < -8.0 (

>= -8.0 to < -6.0 (5

Above -6.0 (17651


19/23


Handover related drop calls

Missing neighbours can result in a failed connection

This is the dominant cause of dropped calls in a well covered region

Missing neighbours are easy to identify from DT log files but scannermeasurements need to be collected.

In Ec/Io measurements from UE level appears to be decreasing verylow until dropped call takes place.

Immediately after dropped call Ec/Io becomes much stronger due to cellreselection

Dropped call occurshere for 3G mode UE

Missing neighbours


20/23


Handover related drop calls (system)

It is possible for SHO to fail even when neighbour relations are present

This can happen due to:

Site issues (Channel elements, AC, Alarms, transmission) Iur problems (can be quite common)

UE measured Ec/Io is appearing the same as in the case of a missingneighbour

Dropped call occurshere


21/23


Handover related drop calls (Dual mode)

When mobile is in dual mode it is possible to handover to 2G system

First mobile will enter compressed mode (Physical ChannelReconfiguration) so that it can measure the 2G cells

In order to find missing 2G neighbours then the Measurement Controlmessage, after entering compressed mode has to be examined for thecorrect BCCH ARFCNs


22/23


Check inter-system issues,BCCH/TCH clash

Compressedmode?

Adequate2G

Coverage?

DC

Physical antennareconfiguration, Addition of

new site (2G)

No

YesNo

Yes

Dropped Call Analysis Summary

2G NeighbourList Correct?

Yes

No

Add missing neighbours

Add missing neighbours

Strongercell fromScanner?

Physical antennareconfiguration, Addition of

new site

Yes

No

Yes

Active SetAdequate

RSCP-Ec/Io?

Yes

No

Strongercell in

MonitoredSet?

No

Measurement Report

Sent?

No

Check UE

Site ondifferent

RNC?

Yes

Check Iur

No

Check Node B (Configuration,Iub/10 MHz, DAC Word, Cell

counters, Alarms)

Yes


23/23


Information needed during Analysis

When performing call setup - or any kind of Drive test log fileanalysis the following information should be at the disposal of theengineer. It is apparent that this information must be updated as often

as possible to ensure analysis accuracy:1. Site Availability Status

2. RNC dump/RNC Browser Access

3. Counter information

4. Site configuration (MHA, WSP, ATM, DAC, etc)

5. Reference database (ex. sites and neighbours)6. Trouble ticket and maintenance Status

7. Integration plan

8. Drive test team report, comments and observations

call failure analysis v3 0301

Documents