3G RANOP3G Radio Optimisation

Module 4 Drive Test Analysis

3G RAN OptimisationRF Optimisation and Neighbour PlanningRF optimisationNew Site IntegrationNeighbour plan optimisationDrive Survey AnalysisSystem Performance (RRC and RAB phases)

Module 4 Drive Test AnalysisObjectivesAfter this module the delegate shall be able to:-Understand the different elements required for an effective drive test programUnderstand how all aspects of drive data can be used to obtain a view of network performanceDifferentiate between genuine (RF) and non-genuine (system) failuresUnderstand the KPIs that can be obtained

Drive Test ProcessNew Site IntegrationRF TuningNetwork OptimisationNetwork Benchmarking (Golden Routes)Why Drive the network?

Drive Test Analysis Test Equipment SwissQual 7.5, Nokia 6650 trace UEsTri-band scannerWDMA/GSM/DCSSwissQual 7.5 UnitGPSLaptopLog FilesLand UnitNQMPLog FilesFTPServerImportant to drive with Call logging equipment and 3G and 2G scanner in the same vehicle

Drive Test Analysis Call PatternsGPRS Attach, PDP Context ActivationFTP Download (1MB file)/FTP Upload (500 KB file)PDP Context DeactivationGPRS DetachAlternate download and upload with 30 sec idle timeSession is upload or downloadUE in Dual mode (2G/3G)Mobile Originated Calls (MOC)2 min calls30 sec idleUE in Dual mode (2G/3G)AMR CallPS CallMobile Terminated Calls (MTC)2 min calls30 sec idleUE in Dual mode (2G/3G)Enough call samples have to be made to make the measurement statistically valid.In a 50 call sample one dropped call will cause a change in performance of -2%In a 500 call sample one dropped call will cause a change in performance of -0.2%Call length should be defined at the beginningWe can use different call testing patterns for different optimisation techniquesShort Calls (for Calls setup performance and delay)Long calls (for Drop call performance and SHO performance)

Drive Test Analysis Defining KPIs Need to agreeWhat raw figures will containWhat End User will containOther cuts of Data

Need to Define the KPI measurement (from Drive test)Call Setup Success (voice, circuit switched data)Successful call setup means that DL/UL Direct Transfer (CC: Alerting) message is received by UE.Session Setup Success (packet switched)This is related to PDP context activation. Successfully activated PDP context means that activate PDP context accept message has been sent from RNC to UE (RRC:downlink direct transfer (SM:activate PDP context Accept)).Call Setup Time (voice, circuit switched)Call setup delay is measured from L3 messages, starting from RRC Connection Setup message to DL Direct Transfer (CC: Alerting) message.Session Setup Time (packet switched)The session setup time is the delay between the time the UE sends the data session activation request until GPRS attach and PDP context activation has been successfully completed.Call Drop (voice, circuit switched)A dropped call occurs. The call will be dropped in case RRC connection release (not normal release) message has been send from RNC to UE.Session Drop (packet switched)Session drop rate can be defined as the number of successful PDP deactivations against number of successful PDP activations.

Definition of Call Set-Up Success Rate (CSSR)RRC: Connection RequestRRC Connection Setup phaseResource Reservation in RNC, BTS, TransmissionRRC: RRC Connection Request SetupRRC Connection Access phase RNC waits reply from UE RRC: RRC Connection CompletedRANAP: Initial UE MessageRAB Connection Setup phaseResource Reservation in RNC, BTS, TransmissionRAB Connection Access phase RNC waits reply from UE Call Set-up Success RateCall Set-up Time

Definition of the Call Completion Rate (CCR) UERNCMGWNode BCall EstablishedIu Release CommandIu Release CompleteRRC Connection ReleaseRRC Connection Release CompleteRRC Connection Release CompleteRRC Connection Release CompleteRadio Link Deletion RequestRadio Link Deletion ResponseALCAP: Release RequestALCAP: Release ResponseALCAP: Release RequestALCAP: Release ResponseCall ReleasedDirect Transfer (Disconnect)Direct Transfer (Release)Direct Transfer (Release Complete)DIRECT TRANSFER (Connect Acknowledge)Call Drop RateCall Duration

Definition of Session Setup TimeINITIAL DIRECT TRANSFER (Attach Request) Downlink Direct Transfer (Authentication & Ciphering Request) UE already has an RRC connectionSCCP: Connection Request SCCP: Connection Confirm RANAP: Authentication & Ciphering Request Security Mode Command Uplink Direct Transfer (Authentication & Ciphering Response) RANAP: Authentication & Ciphering Response RANAP: Security Mode CommandSecurity Mode Command RANAP: Security Mode CommandRANAP: Common IDDownlink Direct Transfer: Identity RequestRANAP: Identity RequestUplink Direct Transfer: Identity ResponseRANAP: Identity ResponseDownlink Direct Transfer: Attach AcceptDirect Transfer: Attach AcceptUplink Direct Transfer: Attach CompleteDirect Transfer: Attach CompleteINITIAL DIRECT TRANSFER (Active PDP Context Request) DIRECT TRANSFER (Active PDP Context Request) DIRECT TRANSFER (Active PDP context Accept) RANAP: RAB ASSIGNMENT REQUESTRRC: Radio Bearer Set-up RRC: Radio Bearer Set-up Complete RANAP: RAB ASSIGNMENT RESPONSERRC: Measurement Control INITIAL UE MESSAGE (GPRS Attach) Session Set-up Time

Failure BreakdownNon-genuine failuresMeasurement system fault (Collection Tool or Analysis)Genuine failuresRF issue (Coverage / Interference / Poor dominance)Missing neighbour System issue Node B System issue RNC Core network issue System(Unknown )It is beneficial to categorise call failures during the analysis and reporting

Failure BreakdownThe KPI measurement conditions should be used to define exclusion areas during drive test for acceptance of a cluster.All failures happening in those area, that do not respect the coverage requirements should be discarded.

DOCUMENTTYPE

1 (1)

TypeUnitOrDepartmentHere

TypeYourNameHere

TypeDateHere

110dBm

-

(A)

-

Call

Discard sample

Example of Call Success Criteria

Threshold

Ec/No

20dB

-

5dB

-

-

NOK

Call

NOK

Call

OK

Call

OK

Call

OK

Call

RSCP

Time

80dBm

-

-

110dBm

-

(B)

-

Call

(A)

-

Call

Discard sample

Example of Call Success Criteria

Threshold

Ec/No

20dB

-

5dB

-

12dB

-

NOK

Call

NOK

Call

OK

Call

OK

Call

OK

Call

RSCP

Time

80dBm

-

-95dBm

-

110dBm

-

(B)

-

Call

(A)

-

Call

Discard sample

Example of Call Success Criteria

Threshold

Ec/No

20dB

-

5dB

-

-

NOK

Call

NOK

Call

OK

Call

OK

Call

OK

Call

RSCP

Time

80dBm

-

-

110dBm

-

Discard sample

Example of Call Success Criteria

Threshold

Ec/No

20dB

-

5dB

-

-

NOK

Call

NOK

Call

OK

Call

OK

Call

OK

Call

RSCP

Time

80dBm

-

-

threshold

Ec/No

below

Signal

ld

thresho

Ec/No

Signal above

threshold

RSCP

below

Signal

threshold

RSCP

above

Signal

_935227290.doc

Failure BreakdownAMR Call Setup Failures

Non-Genuine Call Setup Failure ScenariosExamples of non-genuine failures seen:

Uplink: CM Service Abort within milliseconds from CM Service RequestCall attempt during Location Area update (LA clash)User initiated UL CC DisconnectLocation Area update interpreted as call setup failureCell reselection back to 3G from 2G interpreted as call setup failure

Measurement systems are often not perfect and may introduce errors in data collection or analysis

Non Genuine Call Setup FailuresMeasurement system failures by drive test toolCM Service Abort within milliseconds from CM Service RequestNo time for response from NW

Non Genuine Call Setup FailuresMeasurement system failures by drive test tool Call attempt during Location Area update (LA update clash)LA Update RequestCall attemptRRC Release

Non Genuine Call Setup FailuresMeasurement system failures by Actix workbookSuccessful or failed Location Area update interpreted as call setup failure

Non-Genuine Drop Call ScenariosMeasurement system failure examples:Drive test toolUser initiated UL CC DisconnectAnalysis WorkbookInter-Rat cell reselection from 2G to 3G interpreted as drop callComplete (e.g 90 seconds) call on either 3G or 2GNo drop in the log file / same drop listed twice

Genuine Call Setup Failure ScenariosRF issueInterference / Dominance / CoverageMissing neighbourSystem Issue - NodeBNo response to RRC Connection RequestRRC Connection Reject to RRC Connection Request System issue - RNCCC Disconnect after Call Proceeding due to DL RRC Connection ReleaseCore NWCM Service Abort after CM Service RequestSystem issue (test number)CC Disconnect after CC Progress

Genuine Drop Call scenariosRF issueInterference / Dominance / CoverageSystem issue NodeBSudden CC Disconnect due to DL RRC Connection ReleaseSudden drop to idle, no disconnect messagingSystem issue RNCSudden CC Disconnect due to DL RRC Connection Release

Drive Survey Analysis Process Summary Diagram

Failure LocationAnalyse the signalling flow to find the location of failure and potential causeUE log may only capture some of the messages

Call Setup Failure Analysis ProcessStartBest servers RSCP > -102dBmBest servers Ec/No > -12dBCoverage OptimisationDominance OptimisationAICH(ACK) received?RACH failureMessage sent?UL coverage & RACH param. Opt(changing serving cell)Check system messageReport & Finish(FACH) RRC ConnectionSetup received?Report & Finish(Check failure cause)(DCH) RRC Connection setupCompleted sent from UE?Report & Finish(Reason of problem: L1 sync fail)Radio Bearer setup failureReceived?Report & Finish(Check failure cause)RRC setup reject received? AC optimisation(check PrxNoise& interferer around BTS)Report & FinishCheck failure cause (Not radio problem/cell update)YesNoYesNoYesNoNoYesNoYesYesNoYesNoNoReport & FinishYesABCDENeighbourlist OptimisationMissing Neighbour ?YesNo

Call setup failures RF issueRF issue? Coverage / Interference / Dominance

See the example in Module 3 RF Optimisation

Call setup failures Missing NeighbourMissing neighbour analysis over the whole route (3G-3G, 3G-2G)Search for failures due to missing 3G-3G neighbours Search for failures due to missing 3G 2G neighboursIt is suggested to place 2G scanner to the test vehicle

Call Setup Failure Analysis- Block 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 that UEs Tx power cannot reach serving cell.The Basic theory for RACH setup procedure and planning parameters can be found in Module 7 Parameter Optimisation

Call Setup Failure Analysis- Block B -

RACH Process

DownlinkBSL1 ACK / AICHUplinkMSPreamble1Not detectedMessage partPreamble2PRACH_preamble_retrans# PRACH preambles transmitted during one PRACH cycle without receiving AICH responseUEtxPowerMaxPRACH RACH_tx_Max# preamble power ramping cycles that can be done before RACH transmission failure is reportedPowerRampStepPRACHpreamblePowerOffsetLastPreamblePRACHmessageInitial preample power:Ptx = CPICHtransmissionPower-RSCP(CPICH) +RSSI(BS) + PRACHRequiredReceivedCI

Call Setup Failure Analysis- Block B-Solutions for RACH optimisationMax UE Tx power hit the UE_P_MAX(24dBm)?To increase PRACH_Preamble_retransOr PowerRampStepPRACHPreambleNoYesIs UL Interference abnormally HIGH?YesNoReport there might be an interfering source Nearby the serving cellChange the Serving cell to cover the problem Area=> UE is too far to reach the serving cell

Call Setup Failure Analysis- Block B

Call setup failures System issue Node BNo response to RRC Connection RequestGood RF conditionsWrong MHA settings or cable loss settings can cause the site not to hear the UEPrxNoise statistics, receive link parameters and HW units to be checked (faulty MHA, wrong MHA parameters, wrong cable / feeder loss parameters, faulty units)

C

Call setup failures System issue NodeBRRC Connection Reject after RRC Connection RequestGood RF conditionsAdmission Control can reject too many (or admit too many) connection requests due to wrong PrxNoise measurements.PrxNoise statistics, receive link parameters and HW units to be checkedC

Call Setup Failure AnalysisUE 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 setupPREVENTATIVE STATE: 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 STATE: 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

C

Call Setup Failure AnalysisDuring the pre-optimisation 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.C

Call Setup Failure AnalysisTo check if Layer 1 Synchronization (slot/frame sync) has failedIf RRC Connection Setup was received by UE but UE does not send RRC Connection Setup Completed, we will report L1 synchronization failure and have to check L1 system messages.D

Call setup failures System issue RNCCC Disconnect after Call ProceedingGood RF conditionsFailures 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 NodeB and Core Network.E

Call setup failures System issue RNCCC Disconnect after Call Proceeding (cont.)An example (site shows high values on counter Rab_stp_fail_cs_voice_bts during the drive testIn the recent check the counter showed no failures.

E

Call setup failures Core NWCM Service Abort after CM Service RequestGood RF conditionsSecurity Mode Command-message not received by UE, thus the failure is believed to be at Core Network.E

RRC: Initial Direct Transfer message is sent using acknowledged mode RLC to the CS core domain. Routing is to be based upon the local P-TMSIThe NAS message is not read by the RNC but is forwarded to the multimedia gateway. The NAS message includes the IMSI as a UE identity The SCCP: Connection Request message establishes the connection orientated signalling link in the same way as it was for the RRC connection phase.This does not reserve any resources for the AMR call itself.The Connection Confirm message identifies the RNC with a destination local reference which is the same as the source reference within the Connection Request messageThe Connection Confirm message identifies the CS core with a source local referenceThe CS core sends a RANAP: Location Reporting Control message to the RNC requesting information regarding the location of a particular UEThe RANAP: Common ID message specifies the IMSI belonging to the UEThe Security Mode Command message triggers the start or stop of ciphering and integrity protection.

Call setup failures System Issue (test number)CC Disconnect after CC ProgressCause: recovery on timer expiryThe 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

30 secCause: recovery on timer expiryE

Call Drop Failure Analysis ProcessStartBest servers RSCP > -102dBmBest servers Ec/No > -12dBCoverage OptimisationDominance OptimisationYesYesYesNeighbour list OptimisationMissing NeighbourYesSHO FailedInvestigate possible Node B or RNC problemNoISHO FailedNoISHO Failure AnalysisBYesSHO Failure AnalysisNoA

Call Drop Failure Analysis Process (SHO Analysis)DL Active Set Update receivedYesSC ClashUE Tx Power MaxFix SC ClashCPICH OptimisationUplink InterferenceLoad Optimisation/External InterfererLink UnbalancedYesYesYesYesNoNoNoYesInter RNC HOCheck IurYesCongestion on target cell Load OptimisationNoYesNoCheck neighbour definition parametersCheck RF LevelsNoDL Tx Power Max NoYesStartCD

Drop call failures RF issueRF drops mostly due to poor dominance or interferencePoor coverage could lead to ISHO, although poor dominance or interference can cause ISHO to fail.Rapid field drop can cause drop due to coveragePoor dominance or interference can cause Compressed Mode (CM) to start even if RSCP is still good.In CM UE transmits with higher power (more interference) and spends less time on 3G (less accurate measurement reporting)Poor dominance or interference can lead to Active Set update failures and eventually to drop call.Poor dominance causes Active Set update failures

Drop call failures RF issue

Drop call failures RF issueTransport Channel BER. Btw UERNC (MAC layer) Sometimes DPCCH BER (btw UENodeB) can be a better indicator of what's happening to the dedicated channel than the CPICH EcNo, in particular in the case that power control may not be tracking well.

Fairly good CPICH Pilot EcNo

Drop call failures System issue NodeBSudden drop to idle, no disconnect messagingSite malfunctions to be checkedIn the example below site had faulty unit (WTR)

Drop call failures System issue RNCCC Disconnect due to DL RRC Connection Release No response to UL Measurement Reports In the example site had no alarms, good RF & BERNot 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

Drop call failures (SC conflict)Sudden drop to idle mode (no disconnect messaging)Cause of the failure: overshooting site and SC reuseShort term solution to add overshooting neighbour in ADJS definitions

Drop Call - Uplink InterferenceUL interference from the SIB7 message

Drop Call Link BalanceUL & DL Power Control commands can help indicating problems in link balance.PC frequency is 1500 Hz, thus ideally the sum of PC commands to increase or decrease power is 1500E.g. if the sum of UL PC commands is < 1500, this would indicate UE is starting to loose synchronizationin Compressed Mode there is less PC commands, UE spends time on 2GUE RX power control message: DL reception weak -> UE is ordering WBTS to increase power.

Drop call failures System issue RNC or Node B ?CC Disconnect 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

Node B or RNC failure? => Suspect Node B first, then RNC

Rule out Node B failuresCheck the site performance from OMC counters (Iub, Servlev, SHO, etc) and that site is carrying trafficPrxNoise, receive link parameters, alarms SCreuseUE performance ?Identified causes for Active Set Update failureDeaf sites (PrxNoise)Faulty HWSC-reuse

Drive Test Analysis Reporting Levels Processing Drive Data to provide the information required at the bottom level means that the higher level information can be easily extractedThe different reporting levels may want to see KPIs based on different cuts of the data (e.g. raw or end user)

KPI reportingNon-genuine failures to be removed from the raw KPIs

Non-genuine call setup failures removedNon-genuine drops removedFinal KPIsFinal KPIs

KPI reportingWeekly KPI trends (non-genuine failures should be excluded)

KPI reportingNode B failure chart (call setup failure & drops)Cumulative number of failures that occurred per site over timeIf the UE is spending only a small percentage of time on 3G problems may not be identified.CELL_CCell_ACell_DCELL_B

Node B failure examples: CELL_ALong history of failures (over weeks 46, 47, 02)Call Setup failure scenarios: CC Disconnect after CC Call ProceedingCM Service Abort after CM service Request3rd sector showing low average PrxNoise 108 dBm Commissioning data (feeder loss) was found incorrect.After this site was still failing, not carrying traffic. Alarm 7750 failure in WCDMA BTS O&M Connection. COCO rebuilt (27.1.05)

NodeB failure examples: CELL_BFailures only on week 49No response to RRC Connection RequestNo alarmsAt WBTS: MHA parameters okAt RNC: MHA=0, cable loss = 3 dB (DPCCH init pwr)PrxNoise checked OK, OMC statistics showed the site carried traffic during the drive.No failures in the following weeks drives

NodeB failure examples: CELL_CFailures over weeks 44, 45, 49, 50No response to RRC Connection Request most frequent failure, also one case of sudden drop to idle.Test calls were made, the counters were not incremented during the test. Protocol analyser proved no activity in Iub. The counters were incremented only after site reset.Alarm WSMA RR-bus errorThe site had faulty WTR, incorrect feeder loss in the commissioning file.

NodeB failure examples: CELL_DFailures on weeks 47 and 48No response to RRC Connection RequestIncorrect feeder loss in commissioning data.

Module 4 Drive Test AnalysisSummary

Services to be measured and KPIs to be calculated need to be clearly definedVarious call patterns exist to exercise the KPIsReporting Levels should be understoodDefine and agree exceptions in advance

Usually Service verification is performed in the whole optimisation area (including several clusters) for performance acceptancePurpose is to reach target KPIs for defined services like AMR, CS video, Packet services (FTP server attached to the GGSN)Ideally this should only be done after RF optimisation but often call performance data is also collected during initial drive surveys to reduce costs (at the expense of complexity during analysis)Make gap analysis between measured KPIs and target KPIsInvestigate bad quality related to radio interfaceCoverage problems, Dominance, Interference, Missing neighboursPerform troubleshooting (call trace with logging, analysis etc.) in used to find out if the problem is related to System, configuration, blocking, UEs

Need to stress need for automation of the post processing. Include need to automate up to and including the breakdown of the failuresSignalling diagram, check where the L3 signalling ends (last L3 message) to find out the failure locationSystem issue = NON-RAN issue, I.e. Iur-link (link dimensioning), non-Nokia element issue

Signalling diagram, check where the L3 signalling ends (last L3 message) to find out the failure locationSystem issue = NON-RAN issue, I.e. Iur-link (link dimensioning), non-Nokia element issue

RNC fails to reserve recourses from NodeBLoss of downlink synchronisation forces the UE to stop transmitting which results in a subsequent loss of uplink synchronisation (T313, N313, N315)Radio link failures are caused primarily by a Node B losing uplink synchronisation across the air-interface (N_OUTSYNC_IND, T_RLFAILURE, N_INSYNC_IND)Dedicated Physical Control Channel (control info) DPCCH pilot sequence is used for channel estimation as well as for the SIR ratio determination within the inner loop power controlALWAYS SUSPECT NODE B FIRST, THEN RNCALWAYS SUSPECT NODE B FIRST, THEN RNCNon-genuine failures to be removed from the raw KPIsAttempt and failure (i.e. the whole call) should be removed from the raw KPIs some scenarios:CM Service Abort within milliseconds from CM Service Request Call attempt during Location Area update (LA clash) User initiated UL CC DisconnectCell reselection back to 3G from 2G Location Area update interpreted as call setup failureOnly the failure should be removed from the raw KPIs for some scenariosComplete 90 seconds call on either 3G or 2GNo drop in the log file

Time on 3G Test calls were made, the counters were not incremented during the test. Protocol analyser proved no activity in Iub. The counters were incremented only after site reset.