NDS 3G Drivetest Analyze

[email protected]@gmail.com

[email protected]

3G Drive Test Analysis

Page 2Nexwave Design and Strategic

3G DRIVE TEST

CASE ANALYSIS

44


CLASSIFICATION CRITERIA

Poor CoverageThe Drop occurs in regions where conditions CPICH RSCP and/or CPICH Ec/No are measured in critical values not suitable for a proper connection.

Bad Radio Environment

Every drop that occurs when Best Server is Missing (Mostly in good CPICH RSCP conditions). The UE active set update cannot follow the quick coverage changes. In this case Pilot Pollution situations are included as well (3 cells in AS and more than 1 strong SCs is interfering the connection within a range of 5 dB - Ec/No basis evaluation).

CongestionEvery drop that occurs when there are no more available radio resources for the connection. The network sends an RRC Connection Release when the RBS reaches the maximum available Power in DL.

Not Radio

Every drop that occurs when the radio conditions are good, the logging equipment is working properly and the RRC connection release cause (marked usually as "Unspecified") could be attributed to a RBS/Network fault, (including UL UE power going to maximum even if the CPICH RSCP is measured at good values, crossed feeders causing false missing neighbours, crossed UL-DL feeders, wrong parameter settings that can affect accessibility/SHOs in the cell).

Equipment FaultEvery drop that occurs when TEMS Investigation/UE are Blocking or Freezing and/or SW is crashing, so that it's not possible to maintain the connection.

Missing NeighboursEvery drop that occurs when there are poor RSCP and/or Ec/No levels/quality on the Best Server/AS, with the contemporary possibility for the UE to perform a SHO on a better cell that is not declared as a Neighbour for the AS cells themselves.

CLASSIFICATION CRITERIA


Coverage

EIRP(dBm)

L(dB)

RxLev(dBm)

Unexpected coverage(overshooting)Good coverage

Network Coverage is evaluated by: RxLev/RSCP = EIRP(dBm) – L(dB)

Where:EIRP = Effective Isotropic Radiated PowerL = Propagation Losses

In urban area, Lower Antenna Height (<=25m), Greater downtilt (>=6 degree), and Lower EIRP (<=41 dBm) are used to control overshooting & interference.


Call Setup Analysis


Call Setup Failure Analysis


Call Setup Failure Analysis (RF issue)

RF issue? Coverage / Interference / Dominance


Call Setup Failure Analysis (Missing Neighbor)

• Missing neighbor analysis over the whole route (3G-3G, 3G-2G)• Search for failures due to missing 3G-3G neighbors• Search for failures due to missing 3G –2G neighbors– It is suggested to place 2G scanner to the test vehicle

• Check Serving and Neighbor Cells (DN, MN, AS)• Check from scanner• Check From Database parameters (M2000 or NetAct)


Call Setup Failure Analysis- Blok B

• The purpose of this activity is to check the Random Access Process is working adequately by investigating whether AI (Acquisition Indicator) has been received through DL AICH

• If AICH was not received by UE, the cause of the problem can be classified into:

Inadequate RAN parameter related to Random Access: RAN parameter settings for pre-amble transmission or open loop power control information is not correct.

UL Coverage limit: UL coverage of UE is smaller compared to serving cells DL coverage so UE ‘s TX Power can not reach serving cell.






Call Setup Failure Analysis- System Issue BTS

a. No Response to “RRC Connection Request”– Good RF conditions– Wrong MHA settings or cable loss settings can cause the site not to “hear” the UE– PrxNoise statistics, receive link parameters and HW units to be checked (faulty MHA, wrong MHA parameters, wrong cable / feeder loss parameters, faulty units)


Call Setup Failure Analysis- System Issue BTS

b.“RRC Connection Reject” after “RRC Congestion Request”– Good RF conditions– Admission Control can reject too many (or admit too many) connection requests due to wrong PrxNoise measurements.– PrxNoise statistics, receive link parameters


Call Setup Analysis – BTS Issue• UE has the appropriate DL/UL coverage but if RNC does not allow to set up the RRC connection of the

requested RAB (Radio Access Bearer), Call setup will fail.• Admission Control (AC) is involved in RRC connection setup. AC can reject RRC reject RRC connection

Setup due the DL Load, UL load or DL Spreading codes

– Marginal Load Area:• If measured UL (PrxTotal) or DL (PtxTotal) load exceeds target thresholds (PrxTarget and

PtxTarget) AC can still admit new RAB to the cell if a new non-controllable load keeps below target thresholds (in practice this means that AC can admit only new controllable load RABs i.e. NRT RABs)

– Overload Area:• If measured UL (PrxTotal) or DL (PtxTotal) load exceeds overload thresholds (PrxTarget +

PrxOffset and PtxTarget + PtxOffset) then AC can't admit more RABs to the cell.• During the pre-optimization phase it is unlikely that AC will stop an RRC connection setup during the

drive testing because there are normally very few UEs in the network. (Traffic loading is trivial)• However, it should be checked that measured PtxTotal and PrxTotal are less than PtxTarget (e.g.

40dBm) and PrxTarget (e.g. 4dB, 60% loading) respectively. If DL AC does not allow RRC setup check the Tx power of WBTS, # of channels

transmitted, Signaling messages. If UL AC does not allow RRC setup: Check out if there is an interfering source nearby

the serving cell.


Call Setup Failure Analysis- L1 Sync

• To check if Layer 1 Synchronization (slot/frame sync) has failed:

• If “RRC Connection Setup” has received by UE but UE does not send “RRC Connection Setup Completed, UE will report Synchronization failure and have to check L1


Call Setup Failure Analysis- System issue RNC

• CC Disconnected after Call Proceeding

• Good RF Condition• Failures in RAB setup

occur between the ”RAB Assignment Request” being received from Core Network and the RAN sending out Radio Bearer Setup. Therefore the failure is between BTS and Core Network.


Call Setup Failure Analysis- System issue RNC

• “CC Disconnected” after “Call Proceeding” (Cont.)

• An example (site shows high values on counter “RAB_STP_FAIL_CS_VOICE_BTS“ during the drive test In the recent check the

• counter showed no failures.


Call Setup Failure Analysis- Core Network

• “CM Service Abort” after “CM Service request” • Good RF conditions• “Security Mode Command” -message not received by UE,

thus the failure is believed to be at Core Network.




Call Setup Failure Analysis- System Issue (Test Number)

• “CC Disconnected: after “CC Progress” • Cause: recovery on timer expiry• The call goes via IN SCP to a recording.• A static test was done by Nokia Customer Care

and in few instances the call dropped after 30

seconds of Recording passed. Hence the

problem is associated with the test number not

the RAN

Cause: recovery ontimer expiry




Dropped Call Analysis


Call Drop Failure Analysis Process

Start

Best server’sRSCP > -102dBm

Best server’sEc/No > -12dB

Coverage Optimization

Yes

MissingNeighbour

Yes

InvestigatePossible BTS or RNCproblem

B

Yes

Yes

SHO FailureAnalysis

ISHO FailureAnalysis

A

SHO Failed

No

ISHO Failed

No

No

No

Dominance Optimization

Neighbors list Optimization


Call Drop Failure Analysis Process-SHO Analysis


Drop call failures – RF issue

Poor dominancecauses Active Setupdate failures






Drop Call failures – System issue BTS

• Sudden drop to idle, no disconnect messaging

– Site malfunctions to be checked– In the example below site had faulty unit (WTR)

Drop to IDLE


Drop Call failures – System issue RNC

“CC Disconnected due to “DL RRC Connection Release

No response to UL Measurement Reports

In the example site had no alarms, good RF & BER

Not able to add SC265 to Active Set, next call on the same cell => no failure.

Difficult to troubleshoot if the failure does not happen systematically => follow up in the next weeks drive / do a separate drive test in the area


Sudden drop to idle mode (no disconnect messaging)

Cause of the failure: overshooting site and SC reuse

Short term solution to add overshooting neighbor in ADJS definitions

Drop Call failures – SC Conflict


Sudden drop to idle mode (no disconnect messaging)

Cause of the failure: overshooting site and SC reuse

Short term solution to add overshooting neighbor in ADJS definitions

Drop Call failures – Uplink Interference


Drop Call failures – Uplink Interference


Drop Call failures – System issue RNC or BTS

“CC Disconnected” due to “DL RRC Connection Release” is just a consequence of failure which can be due to different reasons

– From UE point of view L3-messaging does not identify the point of failure distinctly

– BTS or RNC failure? => Suspect BTS first, then RNC

Rule out BTS failures – Check the site performance from Counters (Iub, Service level, cell resources SHO, etc) and that site is carrying

traffic – PrxNoise, receive link parameters, alarms – SC–reuse – UE performance ?

Identified causes for Active Set Update failure – “Deaf” sites PrxNoise – Faulty HW – SC-reuse


Poor CoverageProblem Description: In this case the RF environment as reported by the UE is very poor before the call is dropped. The best server RSCP=-127dBm and Ec/No=-32dB. The scanner also reports poor radio conditions for the same SC at the same instant i.e. RSCP = -119.7dBm and Ec/Io = -10.69dB. The last message sent is the UL Active Set Complete message sent by the UE. The UE then goes into idle mode.


Bad Radio EnvironmentProblem Description: The Active Set best servers are cells with SCs 49 and 303, and all MN (SCs 304, 179 and 180) are close to them on a RSCP basis (from –70dBm to –79 dBm). During the call UE is performing a continuous number of SHOs, affecting both the service continuity and the quality of the connection (low values of Ec/No on each cell). So, the Radio Environment is not suitable for a good connection and therefore the dropped call occurs. Sometimes the TEMS Inv. doesn’t show the event on the chart, like in this case, so it’s advisable to check the Events and Layer 3 messages: In the L3 table the RRC Connection Release DL corresponds (into the Event table) to an RRC Connection Abnormal Release with the specification “Unspecified”.


CongestionProblem Description: In this case the radio environment doesn’t show any critical issue: the AS is full, and there is a Best Server cell (SC 352) with two more cells that are carrying the service. Also the MN set is good, and the Layer 3 messages sequence is regular.The radio resource unavailability pops up suddenly after a certain number of fast SHOs, and an “RRC Connection Release” message from the network comes to interrupt the call. In the TEMS L3 messages window details the release cause is clearly marked as “Congestion”.


Not RadioProblem Description: The radio environment as reported by the UE is very poor just before the call dropped i.e. Best server RSCP=-127dBm and Ec/No=-27dB. The scanner reports much better radio conditions for the same SC at the same instant i.e. RSCP =-93.57dBm and Ec/Io = -8.66dB. Although the drop is as a result of low RSCP as measured by the UE it should not be classified, as a poor coverage drop since the scanner indicates the radio conditions should be ok to maintain the call.


Equipment FaultProblem description: In the example the network sends a DL Measurement Control message and then the UE freezes. There are no further massages sent between the network and the UE. The RF environment was good at the time of the drop as can be seen from the scanner information i.e. RSCP =-82.72dBm and Ec/Io = -5.44dB.


Blocked Calls Classification


Missing NeighbourProblem Description: An example of a blocked call caused by a missing neighbour is shown in figure above. The call is being set up on cell 49046 (SC = 387). During the set up sector 48007 (SC = 451) becomes the strongest sector but is not added to the active set as the two cells are not defined neighbours. This can be seen in the Serving/Active Set window in TEMS. The cell 48007 act as an increasing interferer until eventually the call itself is released. The release cause is classified as unspecified.


Poor RF (Bad Coverage and Radio Environment)

Problem Description: In this case the RF environment as reported by the UE is very poor when the UE attempts to initiate a call. The attempt is indicated by the event “Call Initialization” in TEMS Investigation, which is triggered at the start of a command sequence. The best server RSCP=-121dBm and Ec/No=-21dB. The scanner also reports poor radio conditions for the same SC at the same instant i.e. RSCP =-114.17dBm and Ec/Io = -11.29dB.


Poor RF (Bad Coverage and Radio Environment)

Problem Description: In this case the RF environment as reported by the UE is very poor when the UE attempts to initiate a call. The attempt is indicated by the event “Call Initialization” in TEMS Investigation, which is triggered at the start of a command sequence. The best server RSCP=-121dBm and Ec/No=-21dB. The scanner also reports poor radio conditions for the same SC at the same instant i.e. RSCP =-114.17dBm and Ec/Io = -11.29dB.


Equipment Fault (UE)Security and Authentication Mode Failure

Problem Description: In this case there is a problem with the security and Authentication procedure, which causes the connection to be dropped and result in a blocked call. As can be seen in figure above the radio environment at the time of the blocked call is good i.e. Best server RSCP=-71dBm and Ec/No=-2dB.The call is released normally during call set up and 6 seconds after the network sends the security command. There is a timer for the correct response to this security command, which is set to 6 seconds. This indicates a problem in the security and authentication response by the UE


Equipment Fault (UE)UE Freeze

Problem description: This type of dropped call classification is caused by the UE “freezing” which can be seen in figure below. In the example the UE sends a UL Active Set Update Complete message and then the UE freezes. There are no further massages sent between the network and the UE before the next call attempt, which is indicated by the Call initialisation event in TEMS Investigation. The RF environment was good at the time of the drop as can be seen from the scanner information i.e. RSCP =-94.17dBm and Ec/Io = -5.13dB.


Not RadioDisconnect on RAB Setup

Problem description: In this case the radio environment is good as shown in figure above (i.e. Best server RSCP= -94dBm and Ec/No= -3dB). During call set up, after the “DL Call Proceeding” message the network sends a Disconnect message. This can be seen in the Layer 3 messages window below. The cause value is (127) Interworking, unspecified as shown in L3 message details window. The call is then released.This case can include both DC Config Failure and RAB setup failure.


Not RadioResources Unavailable (Congestion)

Problem description: In this example the network sends a Disconnect message with the following message: cause value (47) Resources Unavailable, Unspecified. This can be seen in the Layer 3 messages window in figure above. The Disconnect message occurs after the Radio Bearer is set up. The radio environment is good at the time of the Disconnect message as seen in figure above.Sometimes this example of blocked call can be also referred to Congestion problems in the measured cell.


Not RadioUE Sensitivity Fault

Problem Description: In figure above, an example of a drop classified as UE sensitivity fault is shown. The radio environment as reported by the UE is very poor when the UE attempts to initiate a call (i.e. Best server RSCP=-122dBm and Ec/No=-18dB). The scanner reports much better radio conditions for the same SC at the same instant i.e. RSCP =-89.06dBm and Ec/Io = -2.65dB. Although the blocked call is as a result of low RSCP as measured by the UE it should not be classified, as a poor RF block since the scanner indicates the radio conditions should be sufficient to set up a call.


Abnormal blocked callsUnclassified - Unanswered RRC requests

Problem description: In this example an RRC request is sent but the network never responds with an RRC connection setup message. It is not clear whether or not the network receives the RRC request. The radio environment in the downlink as seen by TEMS is good i.e. good RSPC, low CPICH Ec/No.


Abnormal blocked callsCall Initialization during L.U. signaling

Problem description: In this case the UE is involved in Location Update signalling. As seen in the RRC Connection Request message the establishment cause is registration and the Location Update request message is for Normal Location Updating. During the L.U. signalling a new call attempt is triggered by the command sequence in TEMS Investigation. This can be seen in the events window in figure above.


CROSS FEEDER

Content


What is crossed feeder issue (1)

The term crossed feeder is used to describe the problem that arises when the feeders for two or more sectors in a site are inadvertently connected incorrectly. For Example, consider a new cell site that has three sectors, A, B, and C:



The crossed feeder problem would arise

if the feeder for sector A is connected to

sector C and vice versa. When this

happens, the sectors typically continue

to provide good coverage. However, the

network parameters for the two sectors

are also reversed. For example, the

parameters storing the sectors' BCCH

and lists of adjacent sectors would be

swapped.

For example, suppose we run a drive

test through the area served by the cell

whose feeders are crossed display the

ServBCCH attribute on the Map while

the cell sectors are colored by BCCH.

This is what we might see:



• There are server types of crossed feeder:

Crossed transmit feeders

Crossed receive feeders

Crossed transmit and receive feeders


The problems raised by crossed feeder issue

Crossed Feeder SituationNormal Situation



• Crossed feeder will raise many problems, such as:

A greater degree of interference

A poor uplink signal strength

A poor performance of handover


How to detect crossed feeder issue by DT

• Crossed transmit feeders

Crossed transmit feeders will result in the swap of 2 or more sectors BCCH frequency and TCH’s. As the sectors are pointing in the incorrect direction, performance will suffer as the frequency plan has been changed and a greater degree of interference will be present.

In DT, we will find that the handset receives the single which shouldn't have been received in the current cell.


How to detect crossed feeder issue by DT

In the example shown above, point A is in the area of coverage of Cell D3, but the handset at point A receives the stronger signal of Cell D2. It indicates that TX feeders were crossed between Cell D3 and Cell D2.

Crossed transmit feeders



REPORTING


Drive Test Analysis – Reporting Levels

• Very High Level KPIs that give an users perception of the network (Network KPI)

• KPIs that provide an Engineering view of network performance e.g CSSR, CDR, OCSR, SHO performance. (KPIs required for each optimizers area)

• Highly detailed KPIs that give a detailed picture of network performance at an Engineering level and allow root cause analysis

• The different reporting levels may want to see KPIs based on different cuts of the data (e.g. raw or end user)

• Processing Drive Data to provide the information required at the bottom level means that the higher level information can be easily extracted

SeniorManagement

Regional OptimisationManager

Optimiser


KPI Reporting


KPI Reporting

• Weekly KPI trends (non-genuine failures should be excluded)

Thank [email protected]@gmail.com

[email protected]

Documents

NDS 3G Drivetest Analyze