pre-post launch optimization techniques
DESCRIPTION
Stages of RF network optimization, before and after launch operationsTRANSCRIPT
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…
Drive Testing and Post - Processing
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
Drive Testing and Post - Processing
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
Drive Testing and Post - Processing
▪ 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.
Drive Testing and Post - Processing
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.
Drive Testing and Post - Processing
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
Drive Testing and Post - Processing
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
Pilot Ec / N0 of cell 2
Pilot Ec / N0 of cell 3
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
Post-launch Optimisation
“Proper optimisation”
▪ Increasing network capacity
▪ Serving hotspots
▪ Increasing coverage for higher data rate services
▪ maximising return on investment
Post-launch Optimisation
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