Pre-Post Launch Optimization techniques

Pre-launch RF Optimisation

Main Activities

Pre-launch Optimisation

▪ We are building a “Network” so get one layer done at a time▪ Set up Default RAN Parameters▪ Except for those we know already i.e Noise Rise Limit.▪ Get the Air interface Uu done first.▪ Do drive testing and look for good indicators to benchmark our

progress

Drive Testing purpose

▪ Drive testing can be done to:

▫ Evaluate initial Cell Plan (Pre-Launch)▫ Network Maintenance (Post-Launch)▫ Network Optimisation (Post-Launch)

▪ The main objectives are:

1- To collect the required KPI’s with enough accuracy2- To take the right number of samples under the right conditions3- To measure over representative areas (route planning)

Drive Testing and Post - Processing

Key Performance Indicators (KPI’s)

▪ Basic KPI’s for CPICH and SCH channels▫ RSCP▫ Ec/No▫ SIR▫ UL Tx Power

▪ Other important aspects to look at:▫ Peak, Aggregate values for the above KPI’s▫ Layer 3 messaging for Procedures▫ Mean Active Set

▪ To provide the required accuracy, good equipment is key…


When to use Scanners

▪ Use Scanners to:▫ Analyse signal quality and Interference▫ Provide fast and accurate measurements▫ Analyse Pilot Pollution issues▫ Measure all channels in the band▫ Provide L1 and L2 measurements

▪ Limitations of Scanners▫ Can’t make calls: no chance to analyse Accessibility▫ Can’t look at dropped calls: no chance to look at Retainability▫ Can’t analyse handovers


When to use Testmobiles

▪ Use Testmobiles to:▫ Get the customer’s perception of the network▫ Measure the Best Server▫ Check Neighbours and Handovers▫ To decode L2 and L3 messages

▪ Limitations of Test-mobiles▫ They see only what the NodeB tells them to look at▫ Can’t analyse Pilot Pollution▫ Can’t measure other servers▫ Limited Neighbour list


▪ Look at data summaries to get an overview of the drive results (software dependant)

▪ Look at coverage and other plots to find root causes

▪ Correlate predicted vs measured data

▪ Correlate Scanner and UE data

▪ Replay the data if necessary to obtain more information

Scanner File AnalysisDrive Testing and Post - Processing

▪ Look at data summaries to get an overview of the drive results (software dependant)

▪ Look at Layer 3 messaging to find root causes

▪ Analyse signalling flows

▪ Correlate Scanner and UE data

▪ Replay the data if necessary to obtain more information

UE File AnalysisDrive Testing and Post - Processing

Drive Test Team

▪ Drive representative routes gathering:▫ Scanner data (rooftop mounted calibrated antenna)▫ Mobile (UE) data (test mobile on rear seat connected to

laptop)▫ Scanner provides accurate measurements of pilot strength

etc.▫ UE data provides evidence of call success and uplink Tx

power.

▪ Drive test data is passed to the SAT team.


Team Work - Example

▪ Drive test reveals calls dropped in an area where best pilot is very low.

▪ SAT team checks with configuration engineer regarding cell status

▪ Check made with planning tool to see whether problem is “predictable”

▪ If no obvious reason, SAT directs drive test team to investigate.


Team Work – Example (continued)

▪ Drive test team report that an obstacle/terrain feature exists that is not on map data.

▪ SAT team recommend solution (antenna height/orientation)

▪ Effect checked on planning tool

▪ Configuration Engineer actions change and reports when implemented.

▪ SAT instructs drive test team to re-examine


Pre-launch (coverage)

▪ Optimising Coverage and Ec/Io▪ Control of cell antenna radiation is crucial to achieving designed

capacity. In particular “high sites” can dramatically reduce the capacity of a network.

▪ It becomes more difficult to achieve high Frequency Re-use Efficiency as cells are packed closer together.

▪ Problems only become apparent as system becomes heavily loaded.

Pre-launch (coverage)

▪ If a mobile experiences comparable path loss to a number of cells, problems can arise through no single cell dominating.

▪ Problems include: low Ec/Io; low capacity on downlink; frequent updates to membership of the active set

▪ Pilot Pollution

Neighbours Objectives

▪ Maintain a reasonable level of Soft and Softer Handover overhead: 30%-40%

▪ Minimise unnecessary handovers

▪ Minimise inter-technology handovers UMTS-GSM-UMTS

▪ KPI’s▫ Mean number of terminals in Soft and Softer Handover▫ Mean number of inter-technology handovers

Optimisation Overview

Interference Objectives

▪ Avoid Scrambling Code interference

▪ Minimise inter-system interference (UMTS-GSM)

▪ Minimise inter-operator interference (UMTS-UMTS)

▪ KPI’s▫ Pilot Coverage overlaps▫ Adjacent channel interference power ratio (ACIR)

Optimisation Overview

Pilot Ec / N0 of cell 1



Reporting_range- Hysteresis_event1A Hysteresis_event1C

Reporting_range+ Hysteresis_event1B

TTT TTTTTT

Connected to cell 1

Event 1A=add cell2

Event 1C=replace cell 1 with cell 3

Event 1B=remove cell 3

WCDMA IF Soft Handover Algorithm

Note: Maximum number of SC in AS is 2

Connected to cell 1 and 2

UTRAN Parameters

Pre-launch (hard handover)

▪ Customers transferring to 3g should:▫ gain access to video telephony services▫ benefit from higher data rates for GPRS and HSCSD▫ experience a service “at least as good as GSM” for voice services

▪ Satisfying this last requirement will necessitate successful inter-technology radio access test handovers occurring.

Pre-launch (hard handover)

▪ Active UE will hand over to GSM when Ec/No thresholds are met.

▪ Ec/No should be logged.

Ec/No

time

Enter compressed mode

Perform Hand Over

2d

3a

Pre-launch (hard handover)▪ Active UE will not hand back to UMTS network.

▪ Idle UE can undergo reselection in both directions.

▪ Compressed Mode (“slotted mode”) is needed when making measurements from another frequency without a full dual frequency terminal.

▪ Secondary issues: compressed mode requires higher power (or reduced throughput)

▪ Fast power control loop is interrupted.

▪ At cell edge, compressed mode overhead estimated to be between 2 and 4 dB.

Pre-launch (handover)

▪ In active mode: drive will be uni-directional▪ In idle mode: drive should be bi-directional▪ Active mode: make a continuous call

▫ monitor for IRAT hand over (or call drop)▫ monitor rapid GSM hand overs after IRAT (10 seconds)▫ check GSM network sustains connection (30 seconds)

Different strategies for HHO Event RSCP (dBm) TTT (msec) Ec/Io (dB) TTT (msec) Hysteresis

Operator1

e1e -105 640 -12 640 0

e1f -108 100 -15 100 0

Operator 2

e1e -107 1280 -9 1280 0

e1f -110 640 -13 320 0

Tx Power Thres (dBm) TTT (msec) Hysteresis

e6a 18 0 0

e6b 18 320 0

UTRAN Parameters

Event CPICH Ec/Io (dB) TTT (msec) Hysteresis

Operator 3

e2d -10 1280 0

e2f -9 320 0

UMTS CPICH Ec/Io (dB) GSM RSSI (dBm) TTT (msec) Hysteresis

e3a -12 -95 100 0

Different Strategies fo HHO (2)

UTRAN Parameters

Pre launch (scrambling codes)

▪ Scrambling code planning▪ 64 Groups of 8 codes▪ If the number of groups and codes can be limited, advantages

will result.

▪ If fewer codes per group are used, then the mobile will find its best server more rapidly.

▪ Also, the fewer the codes per group, the less processing that has to be done by the mobile in general. This increases the battery life.

▪ Handover, is made faster and more reliable by limiting the number of groups.

▪ The challenge is to avoid interference whilst limiting the number of codes and the number of groups.

Pre-launch (neighbours)

▪ Likely strategy:▪ Make co-sited GSM cell a neighbour▪ Make neighbours of this cell a neighbour▪ Manually adjust “as appropriate”.▪ Again, drive test data will be used to tune the list.▪ Big message “If we missed a neighbour it becomes a

interference, hence capacity is decreased”

Incorrect Neighbours

Neighbours and Scrambling Codes

▪ Similar case to “Too many Neighbours”, though here it’s not the quantity but the quality of the Neighbours that’s a problem

▪ Some Neighbours may not be strong candidates, and some strong pilots may be left out.

▪ There may be a SC from a distant boomer site that need to be removed

▪ Detected through drive testing and Post-Processing

Pre-launch (test-mobile measurements)

▪ Test-mobile measurements, depending on the availability of engineering mobiles, should allow measurement of:

▫ CPICH and P-CCPCH availability▫ DCH - Dedicated channel DL performance ▫ Cell dominance▫ Active set size▫ Required UL Tx Power

Pre-launch (test-mobile)

▪ Potential for inconsistency:▫ Different (uncalibrated) antenna/feeder▫ Different drive test route▫ Different UE speed over the route (hold ups at traffic

lights etc.)▫ Different analyser being used.▫ Different level of network loading (affects Ec/Io).

Pre-launch (cluster optimisation)

▫ Procedure▪ Identify size and location of clusters

▪ Define Cluster characteristics▫ Coverage, Interference, Handover region size and location▫ Neighbour list assessment▫ Access, handover and call failures

▪ Take Measurements▫ Drive tests▫ Ec/Io, pilot power, UE TX Power, Neighbours, call success drops and

Handover stats.▫ Service allocation, FER/BLER, Throughput, Max and Av. BER, Delay

▪ An engineer will have responsibility for a particular cluster.

Pre-launch (Benchmark)

▪ Typical Criteria Unloaded:▫ 95% of area delivers pilot strength of >-85 dBm (dense

urban) or -91 dBm (urban).▫ 95% of area covered should register Ec/No better than -10

dB.

Pre-launch (Benchmark)

Ec/Io >-12 dB 99.91%Ec/Io >-11 dB 99.44%Ec/Io >-10 dB 98.14%Ec/Io >-9 dB 94.97%Ec/Io >-8 dB 89.44%Ec/Io >-7 dB 81.22%Ec/Io >-6 dB 68.83%Ec/Io >-5 dB 53.66%Ec/Io >-4 dB 34.94%Ec/Io >-3 dB 13.46%

•Typical drive test result from optimised cluster.

Pre-launch (interference)

▪ Identify areas of low Ec/Io

▪ Examine pilot levels (there will probably be more than three).

▪ Identify any unwanted pilots (from cells that are not intended to provide coverage in that area).

▪ Reduce level of these pilots (usually by down-tilting) be aware of the effect on coverage in service area of cell: use planning tool

Pre-launch (Functional testing)

▪ When carrying out cyclic testing with AMR or VT the Call Completion Success Rate (CCSR) is the most significant parameter.

▪ When testing packet traffic, the Context Activation Success Rate (CASR) and the throughput/time to download are of great interest.

▪ Agreement must be made on suitable timeouts: e.g. how long should the UE attempt to establish a call (20 seconds?) before a failure is registered. Likewise for context activation.

▪ Driving till drop checks for continuous coverage requirements, neighbour planning and hand over procedures.

Pre-launch (handset testing)

▪ On some occasions failure may be specific to a handset.▪ Perhaps the handset does not respond to a paging command or other

message.▪ Perhaps the handset drops a call in an environment where other

handsets do not drop calls.▪ UMTS technology is still improving.

Conclusion -What is different in UMTS

▪ Single Frequency▫ Cannot frequency plan around problems caused by “rogue” sites.▫ Need to optimise clusters of sites rather than single cells.

▪ Level of loading affects performance▫ Cell activity affects coverage and throughput.▫ Interpretation of measurements required.

▪ Flexible structure sensitive to small changes in performance

▫ Air interface performance directly affects capacity and coverage.

▪ Mixed Services

Pre-launch KPIs

▪ Coverage RSCP▪ Ec/Io▪ RRC success rate▪ SHO %▪ HHO failed %▪ Average RACH, FACH, PCH, UL/DL DCH throughput [kbps]▪ PDP Context Activation set up time▪ 10% retransmissions for PS▪ Latency for PS

Post-launch Optimisation

Main Activities


“Proper optimisation”

▪ Increasing network capacity

▪ Serving hotspots

▪ Increasing coverage for higher data rate services

▪ maximising return on investment


This will involve

▪ Adding more sites

▪ Further sectorisation of existing sites

▪ Optimising RAN parameters

▪ Reducing interference

▪ Utilising more than one carrier

▪ Implementing a hierarchical cell structure

▪ Providing indoor solutions

Post-launch

▪ Assuming the network has been launched and:▫ Coverage is “OK”.

▫ Higher services coverage is “patchy”.

▫ Coverage prioritised over capacity

▪ Aim is that we,

▫ Increase Network Capacity

▫ Increase Coverage for high resource services

▫ Improve quality of service offered to users.

Post-launch (hard capacity)

▪ There is no value in increasing the “soft” capacity of the air

interface above the network’s “hard” capacity.

▪ Often the network will be launched with a low level of “hard”

capacity.

Post-launch (remarks)

▪ Optimisation is a cycle▪ UMTS is being optimised with a much statistic analysis

approach.▪ Other things to consider – protocols and applications this is

something new for RF Engineers.

www.mspsinc.com

Pre-Post Launch Optimization techniques

Documents