event analysis tutorial

8/3/2019 Event Analysis Tutorial

1/34

Event Analysis Tutorial


2/34

INTRODUCTION

Event analysis is done in order to provide an explanation for relevant eventsthat happen during drives. This includes Access Failures, CS and PS Drops,Application Drops, IFHO & IRAT Events and other relevant scenarios.

We start our analysis for a particular UE by observing key attributes whichinclude RSCP, EcNo, UARFCN and Technology modes(UMTS or GSM).

Typically, low RSCP is due to coverage issues, event takes place far from thebase station(base stations have limited range) or due to terrain

issues(mountains , lakes, foliage etc). Low EcNo in areas with good coverage(RSCP) could be due to missing

neighbors. Neighbor List(NL) for the frequency band under test must becarefully reviewed and NL additions must be submitted.

Bad UCU cards might lead to degraded throughput on the aircards.

Layer3 messaging interface in Actix(Protocol Stack) enables us to observe themessages exchanged between the server and the UE and helps us to

determine the causes for events that happen during the drive. Note that the L3 messages can be expanded by clicking on the show all rows

button. This is used mainly to find out reasons for application drops.


3/34

THE INTERFACE

Layer3


4/34

Basic steps to follow for Analyzing Events.

1) Start with plotting the UE measurement( EcIo/RSCP depending on the event.

2) Plot the relevant event(access failure/drop and so on).3) Open the UMTS Radio Interface and Protocol Signaling from the Protocol Stack

4) Also open the custom form which can be used to observe the SC/RSCP/EcIo

values for the active, monitored and detected set. It also displays the event ids,

the layer3 message and the SCs involved in the same form.

5) Start with the L3 message where the event occurs, and observe all messages

before the drop to find out the reason for the specific event.6) Refer to the list of event abbreviations and what each event means, before

working on the analysis.

7) Note that a reason for an event might not be observed in the L3 at the point

where it occurs. We might have to go back and see what happens before the

event.


5/34

DL interface between Base Station ->UE

UL interface between UE -> Base Station

All L3 messages with a prefix of DL indicates that it is sent

from the UE to the server. Similarly all L3 messages with aprefix of UL are messages sent from the server to the UE.

UE sends the measurement report which contain event data

and RSCP, EcNo for SC in active, detected and monitored set.

Base station sends measurement control information, this

enables in updating active set.

Basic overview of L3 messages


6/34

Call initiation messaging

UE in idle mode, broad cast channel

UE initiating call

Acknowledgement from Base Station

UE completes connection setup


7/34

Drops and AF Analysis


8/34

CS and PS Drops


9/34

CallDrops observed during drives

1) Call drops can be of two types CS and PS.

2) Normally we observe CS and PS drops during drives.3) These may or may not be RF related.

4) Most of the times, the reason for a drop can be found out from observing the L3

messages.

5) Reasons for the drops are pretty much the same no matter which market the

data is from.

6) However note that there are times when a reason for a drop cannot be foundout from the L3.


10/34

The most common reason for a call drop is poor coverage. RSCP values are

an indication of the coverage in a region. As shown below, poor coverage

causes the drop

10


11/34

Call Drop due to Pilot Pollution When there are too many servers in

the region, the UE is unable to latch on to a single server. Note that all

SCs in the active set have comparable EcNo.

11


12/34

PS Call Drops are sometimes a result of huge traffic volumes

caused by Buffer payloads.


13/34

13

Radio Link Failures Note that Radio Link failures are pegged with the

drops and they are not causes for the drops. The reason for the radio link

failure(i.e drop) can be found out by looking deeper in the L3

.


14/34

MISSING NEIGHBOURS ANALYSIS


15/34

Indication ofMissing Neighbors

1) Possibility of a Missing neighbor is indicated when

we observe poor EcIo in regions with good RSCP.

2) We look in the measurement reports for e1a

events( adding SC to the active set) and see if the

UE is able to add the SCs present in the

measurement report.

3) We take the SCs in the measurement report, find

the sectors mapped to it, and find out if the sectors

serving the UE is added as neighbors to it.

4) However, it does not necessarily mean that e1a

events which are not completed are as a result of

missing neighbors.


16/34

Missing neighbor from overshooting sector MIU40063(SC=310) to MIU32172(SC=278)

F3 Site


17/34

Access Failures


18/34

Access Failures Observed

1) One of the most common causes of Access failures

are location updates performed by the UE at the

same time that Agilent tries to initiate a call from it.

2) Many times we observe access failures in

pairs(outgoing and incoming)

3) Incoming setup fails are caused by GPRS PDP

context rejects

4) Access Failures are also observed due to poor RF

conditions.

5) Absence of radio bearer reconfigurations after e1d

events lead to access failures.

6) A sharp drop in the EcIo values is observed just

before the e1d event.


19/34

Outgoing Setup Fails happen when the Call is trying to be setup during a

location update. i.e Agilent tries to initiate a call from a UE while it is

communicating with the server to perform a location update. Agilent

interprets it as busy and pegs an access failure to it.

19


20/34

HSDPA Outgoing Setup Fail No radio bearer reconfiguration after e1d event. The Reference cell

does not change.( The UE fails to recognize the SC that it has latched on to)


21/34

Alternatively, before the e1d event, we see a sharp drop in the EcIo value when the call is setup.

This results in an access failure as shown


22/34

Outgoing Setup Fail Call Setup during GPRS Service Request


23/34

Incoming Setup Fail GPRS PDP Context rejected


24/34

Application Drops and 120s get/put


25/34

Application Drops and Timeouts

1) 120s get/put happens when the UE takes more than 120s

for a single ftp download/upload session2) Sometimes, application drops are pegged to the 120s

timeout.

3) Application drops are caused by other reasons too which

include winsock errors, socket exceptions and the tests

being aborted by the user.

4) Note that using the IPv4/6 test in Agilent prevents the user

from stopping the log file while the ftp session is in

progress.

5) An easy way to find out a reason for an application drop isto plot Data Testing->Task Summary->Task failure cause.

When we mouse over the plot, Actix displays the reason.

We can also click on the dot displayed which will show the

corresponding message in L3


26/34

26

Task Failure Cause

Mouse over the dot to display the cause for the application

drop. Clicking on it will take you to the L3 message accordingly.

Plot Task Failure Cause


27/34

Application drop pegged to 120s get. Note that when app drops are caused by 120s

get/put, we normally plot the RSCP of the UE and overlay it with the 120s get, the app

drop and the ftp sessions. We show how the session starts in poor coverage thereby

resulting in the download time to exceed 120s.

Reselection

to F3

Plot the event task start

for the ftp session


28/34

Application Drop Net Socket Exception

Reselection

to F3


29/34

ApplicationDrop Test aborted by user

Reselection

to F3


30/34

30

ApplicationDrop Winsock Error

Application drops due to Winsock error occur due to problem in network. The

new update has fixed this in Phoenix market.


31/34

IFHO/IRAT in L3

d d b h h ld f


32/34

Long MO IFHO Event e2d event triggered by RSCP thresholds for

MIU32083(SC=238) to change to MIU32089(SC=238) . We search for the

e2d(event trigger) which triggers the IFHO event. There will also be

measurement control messages which will specify the EcIo or RSCP levels

which triggered the UE to perform a handoff. A radio bearer reconfiguration

message indicates an inter frequency handoff


33/34

Long MO IRAT event 1 e2d event when RSCP thresholds are reached for

MIU32173(SC=286) to IRAT to GSM. We search for the e2d(event trigger) which

triggers the IRAT event. There will also be measurement control messages which will

specify the EcIo or RSCP levels which triggered the UE to perform a handoff. A

Handover to GSM message indicates the technology change


34/34

34

Low throughputs are observed on the aircards when the UE

latches on to servers from either side of the IUR Boundary

event analysis tutorial

Documents