T sel3 g optimization process and guideline ver01

1 © 2006 Nokia TSel3G Opyimization and Guideline ver01.ppt/2006-05-18/DPCompany Confidential

TELKOMSEL 3G Optimization Process &

Guideline


CHANGES HISTORY

NO. DATE VERSION REMARKS DONE BY

1 2006.05.18 Ver01 created Optimization process & guideline Dayanti

Note :Note : The processes, guidelines, and figures described or used in this document will be fine-tuned The processes, guidelines, and figures described or used in this document will be fine-tuned or updated whenever necessary during optimization activities.or updated whenever necessary during optimization activities.


Optimization Process & Guideline

1. Cluster Pre-launch Optimization Process

2. Change Request (CR):• Parameter Change Request• Antenna Change Request

3. RAN Parameter Audit4. Troubleshooting Process5. Network Parameter Change Process6. Optimization Guideline


Cluster Pre-Launch Optimization Process


Objective

•To optimize the outdoor part of the 3G network, this done cluster wise, as they are being integrated.

•The main elements for this process are:•Pre-optimization survey•Network check•Initial drive test, baseline•Pre-Launch optimization

•Cluster tuning until break-out point is reached•Ready for network acceptance & reporting


Overview• Project team will inform when site is integrated• Site will be locked after integration, RF team need to unlock the site before

drivetest.• The CR will be raised to inform Telkomsel when a site is locked/unlocked

• Pre-Optimization survey to be conducted• RF team will verify the site by making some test calls/HO on site• A short drivetest will be done to verify coverage area, coordinate with RNC

engineer just in case to lock site if necessary• At least initial drivetest have been done for the cluster of sites (min.8sites), this

cluster will stay “ON AIR”

• Pre-Launch Optimization may include antennas engineering (reorientation; tilting; relocation); updating of parameters; and neighbors audit.

• As an on-going process, RF team will need to monitor the list of integrated sites; & perform optimization of clusters.

• Check cluster is ready for Cluster Acceptance & Network Acceptance later on (basic requirements are: Ec/Io, RSCP, DC, Setup Success Rate, Call Setup Time, etc)

• Deliverables: Cluster Verification Report• Inform Project team “Site Optimized” status based on cluster level

• Monitor list of cluster ready for Acceptance

Site Integrated

Preparation for Optimization

Activities

Pre-Launch Optimization

Cluster Ready For Acceptance ?

Cluster Optimized

Site On-air

yes

no

Preparation for Network Acceptance


Pre-Launch Optimization Process

Drive test

Cluster ready for NW Ayes N

o

Pre-optim survey

Implement changes

Propose changes

1’ Drive test

Finalize and report

Analysis

NetAct

CR

Site data

Pre-requisites

Cluster integrated

Stability, alarm and consistency chk fix

OSS

Weekly progress report

Final report

PE

RF Planning Parm “Master” List

Cons checkRAN par audit

Change request

Change request

Stability, alarm and consistency chkfix

Cons checkRAN par audit

Change request

1

2

3

4

5

6


Pre-Launch Optimization Process1. Pre-Optimization Survey• Objective

• To provide prerequisites for Pre-Launch Optimization• Input

• Cluster definition• At least 80% of sites in cluster on air

• Process The optimization engineers will conduct a survey of the defined cluster area. This will

consist of a 2-3 day survey of the area and this will give the engineer the necessary knowledge of the nature of the area, in terms topology, customer distribution, abnormalities. This should then be the background info for finalizing the drivetest routes. During the survey all sites must be visited and a pictures each sector should be taken from ground in the azimuth and in LOS to the antenna.

• Output• All site information (picture; site survey report)• In depth knowledge of the site and area• Drivetest route defined by Nokia & Telkomsel


Pre-Launch Optimization Process2. Network Check• Objective

• To ensure that the network is stable and consistent before drivesting• Input

• Planned parameters and NW upload• Alarms• Integration plan from project team

• Process Perform a parameter consistency check to ensure that the actual RAN parameters

are set as planned, in case discrepancies take action to correct them. Check if recent alarms for the cluster and surrounding sites to prevent unstable network elements are not jeopardizing the measurements. Review the integration plan and make sure that no new sites are in the vicinity of the cluster are being integrated and the cluster neighborhood is the RF environment is stable.

• Output• Parameter fixes if inconsistencies• Go / No-Go for drivetest


Pre-Launch Optimization Process3. Initial Drivetest, Baseline• Objective

• To establish the reference performance, of which the optimization efforts will benchmark against

• Input• Drivetest route will be jointly defined by Nokia and Telkomsel in cluster survey.• At least 80 % of sites in cluster on air• Parameter upload and alarms

• Process Drivetest performed according to route definition recording:

• Ec/No performance• Area of service availability or coverage performance• AMR call, 64k uplink and 128k downlink test• Other metrics

• OutputSummary of KPI’s, CPICH RSCP and CPICH Ec/No and data mapped on drivetest routes.


Pre-Launch Optimization Process4. Pre-Launch Optimization• Objective

• To implement changes in the RAN that improves performance in order to achieve or exceed the agreed performance

• Input• Drivetest data• Local knowledge

• ProcessOptimization actions with focus on the basic radio functionality, with focus on:

• Coverage and interference performance, Cell shaping by means of azimuths, E/M tilt pilot power.

• Adjust neighbour definitions and HO parameters to ensure basic RAN function.• Verify effect changes by drivetesting• Track and reflect all changes in databases consistent with change sub-process.

• Output• Pre-launch optimized network cluster• Weekly progress report


Pre-Launch Optimization Process5. Change Process Summary• Objective

To implement and track all changes in the RAN; The changes carried out will be informed to Telkomsel

• Network wide changes. All network wide changes should follow the normal process of:

• Proposal• Test/study• Evaluation• Implementation

This done in very close cooperation between Telkomsel and Nokia.• Normal RAN par changes

In the process of the pre-launch optimization change request are being submitted in batches on daily basis by the engineer responsible for the cluster. The team leader will approve these and submit to implementation person both for parameter changes & physical changes. In the case changes don’t produce the required results a fall back plan will be instituted.


Pre-Launch Optimization Process6. Finalization and Reporting• Objective

To document and share the result of the cluster optimization• Input

• Performance data derived from drivetest data• Specific experience

• Process Write report containing:

• KPIs before and after optimisation whenever applicable• Actions taken to improve performance• Share the lessons learnt with complete Telkomsel/Nokia team to increase the

speed and quality of the optimisation on the network level• Output

Report with KPI’s before and after, and methods used effective as well as non-effective.


Pre-Launch Optimization ProcessReporting Detailed• Weekly Cluster Report

• To be ready on every Monday 2pm for the previous week activities.• To report on cluster weekly activities,

• Optimization activities• Summary of Change requests• Any other issues…

• 2. Cluster Verification Report• Report to be ready 3 weeks after Cluster is 100% integrated.• Cluster MUST be ready for Network Acceptance, if not, reasons must be clearly

stated (should not be any RF related issues…).• Report must contain :

• Cluster coverage performance, Key KPI counter performance,..• Cluster must be ready for Network acceptance unless if problem is caused by

other elements not related to RF. • Document to be Approved by Nokia Team Leader, and Telkomsel to review


Pre-Launch Change Request

Note :Note : The term of CR here is related with pre-launch change request The term of CR here is related with pre-launch change request

which is generate frequently and need to implement immediately. which is generate frequently and need to implement immediately. Pre-launch CR submitted from RF team to RNC team for Pre-launch CR submitted from RF team to RNC team for parameters CR or Rigger team for antenna CR and CC to parameters CR or Rigger team for antenna CR and CC to Telkomsel.Telkomsel.


Parameter Change Request

• From the RF optimization activities, RF team will have a list of parameters (pilot power, neighbor list, HO parameters..) to change frequently.

• This process will require RF team to work closely with the RNC team.

Change Request (CR)• RF PIC will consolidate the lists of data parameters need to modify

(either xml format or excel file) and will send a copy via email to RNC PIC.

• RNC PIC will implement changes, and revert to RF PIC by email or phone when changes is done.

• Frequency of CR will depend on the optimization activities, may be once a week, or even daily


Parameter Change Request ProcedureCluster

Fine-Tuning Update Weekly Cluster Report

Update Parm Change

Request Log File

Compile CRs from Log File

Send Compiled CRs to RNC Engr

Confirm CR

updated in N/W?

CR Done.yes

no

(i)

(ii)

Update RF Planning Parm “Master” List


Parameter Change Request Procedure

Cluster Fine-Tuning

Change Request1. Get CR # from Parm

CR Log File2. Enter required info in

CR Log File

Update Weekly Cluster Report

Date CR # BTS ID Sector Week # / Year Cluster # Parameter Name Old Value Proposed Value Requested by Date

ImplementedImplemented

by

001 week 10 /2004 1002 week 10 /2004 1003 week 10 /2004 1

-Summary of the CRs in the week.- Conclusion within the cluster

- CR Log File stored in common RF planning drive.- Planner will be able to get the “latest” CR #.- CRs will be compiled based on daily/weekly basis by PIC.

(i)

Update RF Planning Parm “Master” List

- Planner request CR to update Parm “Master” List (See RAN Parm Audit Process)


Parameter Change Request Procedure

Compile CRs from Log File

Send Compiled CRs to RNC Engr

Confirm CR

updated in N/W?

CR Done.yes

no

- PIC will compile CRs from Log file on a daily to weekly basis. He may generate an “xml” file, or excel file, depending on the size of CRs list.- PIC will email to RNC PIC and call at the same time, cc Telkomsel PIC.- CRs will mainly consist of pilot power, ADJS, and HO parameters …- RNC engr will implement changes- call back RF PIC once completed changes - Lead time – 1 day

- Planners who Initiate CRs will check if changes is implemented correctly thru’ daily RAN Param Audit.

(ii)


Antenna Change Request

• From radio optimization activities, RF team will have antenna directions and tilts to change.

• CR PIC will send a copy of CR via email to rigger team• CR PIC will send site access request to Telkomsel• Rigger team will implement changes and send sms confirmation to RF

team leader. • Rigger team to return signed CR to CR PIC.• Rigger team required to inform Telkomsel team when on site, i.e.

before they access the site, and when leaving the site.


Antenna Change Request ProcedureCluster

Fine-TuningUpdate Weekly

Cluster Report

Update Antenna Change Request

Log File

Send Compiled CRs

to Rigger

Confirm CR CR Done.

Yes

No

(i)

(ii)

Update Site database file

Site accessarrangement


Antenna Change Request Procedure

Cluster Fine-Tuning

Change Request1. Get CR # from Antenna

CR Log File2. Enter required info in

CR Log File

Update Weekly Cluster Report

-Summary of weekly CRs.- Conclusion within the cluster

- CR Log File stored in common RF planning drive.- Planner will be able to get the “latest” CR #.- CRs will be compiled based on daily/weekly basis by PIC.

(i)

Date Week # / Year CR # Cell ID Sector Site Name Site Type Cluster # Parameter Old Value Proposed Value Requested by Date

ImplementedImplemented

by Comments

24.3.2004 week 10 /2004 001 123456 1 PB C1 M-tilt 2 424.3.2005 week 10 /2005 002 123457 2 HDB C2 E-tilt 4 824.3.2006 week 10 /2006 003 123456 1 HDB C3 Direction 0 20


Antenna Change Request Procedure

Send Compiled CRs

to Rigger

Confirm CR CR Done.

Yes

No

(ii)

Update Site database file

Site accessarrangement

• CR PIC will compile CRs from Log file on a daily to weekly basis.

• CR PIC will email to Cornwall PIC & cc to Telkomsel PIC and RF team leaders.

• Rigger engr will implement changes• SMS and submit signed CR to CR PIC once completed

changes • Lead time 2 days


RAN Parameter Audit


RAN Parameter Audit Process

Daily Dump from RNC

RF Planning Parm “Master” ListCompare

Difference in Parameters

- Team Leaders in each region to check file on a daily basis- To identify discrepancies in params- To identify if CR changes is implemented

Objectives is to detect the following :• Missing Neighbours

– Missed during integration, Site is deleted and re-created

– CR not processed, missed ...

• “Extra” neighbours, changed param for tests..

Create CR


RAN Parameter Audit Process

Daily Dump from RNC

RF Planning Parm “Master” ListCompare

Difference in Parameters - Team Leaders in each region to check

file on a daily basis- To identify discrepancies in params- To identify if CR changes is implemented

Create CR

- RNC PIC will generate Daily dump- Daily dump to be sent daily (morning) to RF PIC

- RF PIC (Nokia) will perform comparison

- RF Team when creating CRs will be required to update the “RF planning Parm Master list”.- This list ensure the param consistency between the network and RF plan


Troubleshooting Process


Troubleshooting Process

• During Drive test activities, DT team may encounter the following problems :

• BTS not transmittingBTS not transmitting• BTS transmitting, but UE unable to make calls (ie 90% failure rate)BTS transmitting, but UE unable to make calls (ie 90% failure rate)• Setup rate is poor…. Etc.Setup rate is poor…. Etc.

• The attached Excel worksheet looks at troubleshooting tracking• Under this situation, drive team have to stop the data collection, and

escalate the problem to team leader.• Team leader will try to resolve the problems and decide if drive test is

to proceed.


Troubleshooting ProcessDT encounter ab-normal setup, drop call failures

DT inform Team Leader

Team Leader will liase with RNC/BTS engr and DT to resolve

problem

-Example: - BTS not transmittingBTS not transmitting- BTS transmitting, but UE unable to make BTS transmitting, but UE unable to make calls calls - Setup rate is un-usually poor.Setup rate is un-usually poor.

Continue/Abort Drive Test Activities

Team Leader will contact RNC engr to check BTS

status and alarms

if problem needs to escalate to BTS Team OR if problem needs to escalate to BTS Team OR remains unsolved have to inform John Pereira remains unsolved have to inform John Pereira immediatelyimmediately


Network Parameter Process


New Network Parameter Changes

required

Pre-Test Drive Testyes

Confirm parameters are applicable in existing

network releases

Load into Test Cluster

Post-Test Drive test

Analysis

Is param performing as expect?

Implement to network

Fall back to original param setno

Cont’ to monitor network perf. thru routine drive tests

yes

noTest param in

Test Bed*, results ok?

Troubleshoot Troubleshoot parameter set.parameter set.

* Whenever applicable

Network Parameter Change Procedure


Optimization Guideline

• The solutions and topics presented in the following sections are only for references used during optimization.

• Not all the solutions discussed are applicable.• The RF figures/threshold used are not related to any KPIs of

the project. They are set as a general standard for 3G optimization purposes as of now.


Optimization GuidelineOverview


Optimization OverviewDrive Test

Measurement

Coverage area

optimisation

Dominance area

optimisation

Complete Measurement

Analysis

Best server’s CPICH RSCP> -95 dBm

Best server’s

Ec/No > -10 dB

Yes

No

Yes

No

Coverage problem area

Dominance problem area (Low best server Ec/No)

Dominance area

optimisation

Dominance problem area (High best server Ec/No)

4th Best server’s

Ec/No < 6 dB (ref to Best

server)

No

Yes

A

B

C


Block-ADrive Test

Measurement

Coverage area

optimisation

Dominance area

optimisation


Analysis


Best server’s

Ec/No > -10 dB

Yes

No

Yes

No



Dominance area

optimisation


4th Best server’s


server)

No

Yes

A

B

C


Block-A• Task

• To identify area where RSCP is less than –95 dBm and to optimize the coverage of that affected area

• Reason• Area where RSCP is less than –95 dBm and poor Ec/No value would be consider coverage

problematic area or has poor coverage• This would lead to call set up failure, HO failure, drop call and degradation to the PS throughput

• Items required for analysis• RSCP and Ec/No plots for best server on map• Plot of RSCP vs Ec/No to have quick understanding of the problem• Measurement log files

• Solution• Up-tilting, panning and height of antenna changes• Increase CPICH power• Antenna type changing to a higher gain • Check missing neighbors• Use NetAct to check coverage prediction by changing the inputs of the site• Use the MapInfo tool for antenna tilting to estimate coverage improvement (optional)


Block-APlot of RSCP vs Ec/No (example)


Drive Test Measureme

nt

Coverage area

optimisation

Dominance area

optimisation


Analysis


Best server’s

Ec/No > -10 dB

Yes

No

Yes

No



Dominance area

optimisation


4th Best server’s


server)

No

Yes

A

B

C

Block-B


Block-B• Tasks

• To identify area which RSCP > -95 dBm but Ec/No < -10 dB and to optimize the affected area

• Reasons• In this area problems are more on the dominance and pilot pollution• This would lead to call set up failure, HO failure, drop call and degradation to the PS

throughput • Items required for analysis

• Plots of Ec/No and RSCP for best server on map• Plots of Ec/No of each scrambling in the affected area• Plots RSCP vs Ec/No • Measurement log files

• Solution• Down-tilting, panning and antenna height changes• Increase CPICH of serving cell, decrease CPICH of interfering cells• Check for missing neighbors• Check co-scrambling code• Change antenna type to lower gain


Block-CDrive Test

Measurement

Coverage area

optimisation

Dominance area

optimisation


Analysis


Best server’s

Ec/No > -10 dB

Yes

No

Yes

No



Dominance area

optimisation


4th Best server’s


server)

No

Yes

A

B

C


Block-C• Task

• To identify the 4th best server is < 6dB to the reference of best server and optimize the area

• Reasons• To meet the KPI• Too many best servers would cause unnecessary HO • Wasting resources (hardware channels, Iub capacity etc)

• Item required for analysis• Measurement log file

• Solution• Down-tilting, panning and antenna height changed• Increase CPICH of serving cell, decrease CPICH of interfering cells• Use MapInfo to generate the percentage • Antenna type change to lower gain


Summary Of Solutions

•Down-tilting of interfering cells’ antenna, which generate pilot pollution•Change CPICH Tx Power: Increase serving cell’s Tx power but decrease interfering cell’s Tx power•Change antenna bearing angles of cells involved in pilot pollution•Decrease antenna height of interfering cells and increase antenna height of victim cell with adequate tilting angle•Change antenna patterns of cells involved in pilot pollution. Smaller gains for interfering cells and higher gain for victim cell

• Up-tilting of serving cell’s antenna to extend coverage radius and to improve unsatisfied coverage area•Increase CPICH Tx Power of serving cell•Change Antenna Bearing Angle: Focus the main beam of antenna to coverage holes and low RSCP area•Increase serving cell’s antenna height to get higher effective antenna gain but there is risk to make undesirable inter-cell interference to adjacent cells•Change Antenna Pattern: Displace with higher gain antenna with adequate antenna tilting.

Tuning methods for

Coverage Problem Area

Tuning methods for Dominance Problem AreaHigh Priority


Optimization GuidelineCall Setup Optimization


Call Setup Failure OptimizationCall Set Up

Neighbour Optimisation

DL Coverage

optimisation

UL Coverage optimisation

(Change serving cell)L1 sync failure

Check failure cause

Check failure cause

(No radio issue)

Dominance optimisation

Missing Neighbours

Best Server’sRSCP > -95 dBmEc/No > -15 dB

UE Tx Pwr=Max &TPC increase

(DCH) “RRC Connection Set Up

Complete” sent from UE?

Radio Bearer Set Up Failure” receive?

No

Yes

No

NoYes

No

Yes

No

Yes

No

A

B

C

D

Yes


Block-ACall Set Up


DL Coverage

optimisation



Check failure cause

Check failure cause

(No radio issue)


Missing Neighbours






No

Yes

No

NoYes

No

Yes

No

Yes

No

A

B

C

D

Yes


Block-A• Task

• Verify the radio condition is good• If the radio condition does not meet the criteria optimize the area

• Solution• Check for missing neighbors

• If there is missing neighbor do optimization on the neighbor list by adding neighbors. If the neighbor list is full replace the least important neighbor

• To look for other suitable neighbors do pilot scanning. From the Mapinfo tool decide whether to add the neighbor by the number of samples to the reference of the pilot.

• Coverage optimization for downlink & Dominance Optimization• Antenna change, panning tilting and tilting• Change antenna height• Adjust CPICH power

• Cell Reselection option• Parameter Tuning : Qhyst2, Sintrasearch etc


Block-BCall Set Up


DL Coverage

optimisation



Check failure cause

Check failure cause

(No radio issue)


Missing Neighbours






No

Yes

No

NoYes

No

Yes

No

Yes

No

A

B

C

D

Yes


Block-B

• Task• Check whether UE transmit power hitting the maximum power and power

control increased drastically• Solution

• Admission Control optimization• Check PrxNoise and PtxTotal levels from Nemu (RNW Monitoring Online)• Check loading of the cell• Check the stats from the EOSFLX reporter

• Min/Ave/Max_Prx_ Noise• Ave_PtxTot_Class0 to Class5

• Parameter tuning : PrxTarget, PtxTarget, CPICHtoRefRABoffset

• Cell edge (Uplink Coverage Optimization)• Change serving cell• Installing MHA


Block-CCall Set Up


DL Coverage

optimisation



Check failure cause

Check failure cause

(No radio issue)


Missing Neighbours






No

Yes

No

NoYes

No

Yes

No

Yes

No

A

B

C

D

Yes


Block-C

• Task• Verify that the UE has sent the “RRC Connection Set Up Completed”

message to the CN• Reason of failure might be caused by L1 synchronization out of sync

• Solution• Check the stats from the EOSFLX Reporter for the cause of the RRC drop

• RRC_Conn_Act_Fail_Iu/BTS/Radio/Iur/etc• Change N312 or T312 parameter for L1 out sync cause• Transmission problem• May cause by hardware blocking


Block-DCall Set Up


DL Coverage

optimisation



Check failure cause

Check failure cause

(No radio issue)


Missing Neighbours






No

Yes

No

NoYes

No

Yes

No

Yes

No

A

B

C

D

Yes


Block-D

• Task• To verify when there is a RAB establishment failure whether the UE sent

the message indicating the failure• If there is message sent “Radio Bearer Set Up Failure”, the radio interface

has no issue and it is more likely caused from the network side since the UE has triggered the message

• Solution• Normally when there is successful RRC set up, the likelihood of RAB set up

failure is very low• If there is a RAB failure check whether the RRC connection is released and

is the caused for the RAB drop• Checks the stats for the EOSFLX reporter for the cause of the RAB drop

• RAB_Act_Fail_’Service Type’_Iu/Radio/Iur/BTS/etc• Check capacity


Optimization GuidelineDrop Call Optimization


Drop Call In Dedicated Mode

Active Call


DL Coverage

optimisation



Missing Neighbours

HO failureHO parameter optimisation

No

No

NoYes

Pilot Pollution

Check BLER

Check failure cause

(No radio issue)

A

B

C Yes

Yes

No

No

Yes


Block-A

Active Call


DL Coverage

optimisation



Missing Neighbours


No

No

NoYes

Pilot Pollution

Check BLER

Check failure cause

(No radio issue)

A

B

C Yes

Yes

No

No

Yes


Block-A• Task

• Verify the radio condition is good• If the radio condition does not meet the criteria optimize the area

• Solution• Check for missing neighbors

• If there is missing neighbor do optimization on the neighbor list by adding neighbors. If the neighbor list is full replace the least important neighbor

• To look for other suitable neighbors do pilot scanning. From the Mapinfo/UMTS decide whether to add the neighbor by the number of samples to the reference of the pilot.

• Coverage optimization for downlink & Dominance Optimization• Antenna change, panning tilting and tilting• Change antenna height• Adjust CPICH power

• Cell Reselection option• Parameter Tuning : Qhyst2, Sintrasearch etc


Block-B

Active Call


DL Coverage

optimisation



Missing Neighbours


No

No

NoYes

Pilot Pollution

Check BLER

Check failure cause

(No radio issue)

A

B

C Yes

Yes

No

No

Yes


Block-B

• Task• To verify whether the drop call is caused by handover problem

• Solution• Tune the handover parameters: Add Window, Drop Window, Replace

Window, Add time, Drop time, Maximum Active Set etc• The best solution is to reduce the number of handover because this would

utilise the hardware resources• Capacity issue• Check parameter consistency


Block-C

Active Call


DL Coverage

optimisation



Missing Neighbours


No

No

NoYes

Pilot Pollution

Check BLER

Check failure cause

(No radio issue)

A

B

C Yes

Yes

No

No

Yes


Block-C

• Task• To verify whether the drop call is caused by pilot pollution• When there is a sudden change of Ec/No and BLER increased, while there

is no issue for coverage, the likelihood the UE suffering from pilot pollution is high

• Solution• Check BLER• Check for co-scrambling surrounding area• Do pilot scanning and include the interferer as neighbor if possible• Dominance optimization

• Downtilting, panning and changing the height of the antenna• Reduce the CPICH power of the interfering cells


Have a nice day

T sel3 g optimization process and guideline ver01

Technology

Transcript of T sel3 g optimization process and guideline ver01