Вы находитесь на странице: 1из 53

3G-Pre launch Optimization

Contents
1. 2. 3. 4. 5. 6. 7. 8.

Introduction UMTS technology in brief Pre-Launch Optimization Phase 1: Site Verification Phase 2: Cluster tuning Phase 3: Market Area Tuning Phase 4: Inter RAT Handovers Appendix

8.1. Site Verification Form Sample 8.2. Definitions 8.3. References

Introduction
Pre-launch optimization basically deals with

assessing a newly-built network, uncovering problems and resolving them prior to commercial launch. It entails detailed field rf measurements, detecting and rectifying problems caused by radio, improper parameter settings or network faults and finally, grading the radio access part of the network to make sure that it passes certain evaluation criteria

UMTS technology in brief


Architecture UTRAN Interfaces

UMTS technology in brief


Wideband CDMA is the recognized air interface

standard for 3G-UMTS WCDMA utilizes the spread spectrum technology for radio access where users are identified by unique codes For optimal operation of the wireless system, several functions are in place to control the radio network and the many active handsets

UMTS technology in brief


Efficient power control in both directions regulates the

over-all interference level which is very important in a network with a frequency reuse of 1 Cell breathing is a phenomenon inherent in WCDMA. This is the trade-off between coverage and capacity where the size of the cell varies depending on the current load. Macro-diversity is another feature of the network which is achieved during soft handover. A user can be connected to two or three base stations at a time providing a more reliable connection, thus reducing the risk of premature disconnection

Architecture
For mobile network operators like Airtel, Vodafone

that has an existing GSM infrastructure, the migration scheme towards 3G primarily involves annexing a UMTS Terrestrial Radio Access Network (UTRAN) to the current setup. Both the GSM BSS and the UTRAN are connected to the same core network which handles all voice and data traffic from both systems, in circuit-switched (CS) or packet-switched (PS) modes

Architecture and Interfaces

Pre-Launch Optimization
Objective Phases of pre-launch optimization

Objective
In a nutshell, the main goal of pre-launch

optimization is to make the UMTS network ready for commercial launch. To achieve this, a series of tests and tuning methods must be carried out and repeated as many times as required in order to meet certain performance criteria. Tests will basically start from cell level and then progressively widen in scope to encompass larger groups of cells until the entire market is tested as one functioning unit

Phases of pre-launch optimization

Phase 1 Site Verification

Phase 2 Cluster Tuning: Unloaded and Loaded Cases

Phase 3 Market Area tuning

Phase 4 I-RAT Test

Network Launch

Phase-1& 2
Phase 1 testing is needed to check if the Node- B is able to perform all the vital functionalities and if its coverage conforming to the site rf design. Every Node B in the network has to pass this test. Phase 2 will be done at cluster level and will consist of two sub phases: Unloaded scenario involves testing a quiet network aimed mainly at optimizing Layer 1 performance. At this time Neighbor Lists tuning will typically be done. Loaded scenario with more rigid tests to evaluate the major services. In this phase, artificial load will be introduced to simulate real subscribers

Phase-3&4
Phase-3 is similar to Phase-2 in a loaded

configuration but on a geographically wider scale to encompass the entire Market area., and confirm inter cluster operation. The last phase will involve handover tests between the two Radio Access Technologies the existing GSM and the new UMTS networks.

Site Verification

Objective Inputs Log File Naming Convention Entry Criteria Tool setup and test process Analysis Change requests Exit criteria Deliverables

Objective

Site verification aims to guarantee that each cell is performing according to specifications. Both coverage and functionality tests will be performed to evaluate every cell in the network. At the end of the exercise the RF engineer should be able to:
Detect the possible causes if the coverage levels are too low Verify correct antenna orientation and fix swapped sectors, if any. Ensure that basic cell functionalities execute properly Check for uplink interference Document and compile log files and test sheets for each site tested. These can be useful references, especially while doing cluster tuning Datafill verification

Inputs Log File Naming Convention Entry Criteria

Tool setup and test process


Upon arrival at the site, an attempt to validate as much site information as possible should be made. Perform a basic site audit to verify the following:

Antenna location Antenna type height Azimuth Mechanical tilt

Tool setup and test process


A stationary test to be performed under the best possible radio conditions within the cell area will consist of the following: In Idle mode, verify the PSC, Cell ID, LAC & RAC (displayed in SIB 1) of the test sector is correct
Test the following call scenarios in each sector: MO (mobile originated) to a landline number MT (mobile terminated) to a landline number MM (mobile-to-mobile) calls CS Video calls PS Call FTP downloads of various sized files, ping tests, web page browsing HSDPA FTP downloads of various sized files, ping tests, web page browsing Confirm that CPICH RSCP, CPICH Ec/No, UE Tx Power, BLER,

session application throughputs are within acceptable ranges

Tool setup and test process


A drive test should then occur to test the following: Test softer HO in both clockwise and counter clockwise directions around the site Check soft HO to neighboring site (if relevant) Check IRAT to neighboring site (if relevant

Analysis
Basically, the RF engineer should ensure that all functionality tests are successful. Proper call setup and termination within acceptable call setup times No dropped calls - except due to loss of coverage. No failed Soft and softer handovers Packet service data rate - at very close proximity from the site, it should be easy to achieve 384kbps DL throughput

Analysis
Coverage analysis involves a visual comparison of the actual and planned coverage plots. Naturally, the two plots should more or less be the same. Large discrepancies can mean many issues such as:

Propagation modeling via the planning tool is either extremely pessimistic / optimistic in presenting the coverage propagation for a cell Site issues such as faulty radio and antenna equipment. Non-optimal antenna placement may lead to blocked antennas reducing coverage. Inaccurate Azimuth settings set / revised during deployment Faulty test equipment could be used to incorrectly measure coverage criteria. Parameter settings such as overhead channel power settings could be incorrect. It is the RF engineers role to pinpoint the causes of the problem and develop the necessary solutions. One abnormality that is easily detected via a coverage drive-test is swapped feeders. Feeders terminated at the wrong antennas are commonplace in new site implementations and this is the best time to detect and correct this kind of problem. Be aware that swapped feeders on the receive path, if possible, will exhibit unacceptable TX / RX level mismatches.

Change Request & Exit Criteria


A system for issuing change requests should be in

place to fix any hardware and parameter discrepancies found during the activity. Fixes may involve difficult hardware repairs / parts replacement in the site or simple parameter changes at the NMC, like neighbor additions. Verification tests should follow afterwards to make sure that change request was implemented properly. Site verification is considered complete for a Node B if all functionality tests are successful, site coverage meets design objectives and there are no unresolved installation faults.

Deliverables
Planning tool Pilot RSCP plots for each sector Drive-test Pilot RSCP plots for each sector Drive-test Pilot Ec/No plots for each sector Drive-test UE Tx Power plots for each sector Drive-test Application Layer Throughput plots

for each sector Site Verification checklist Change Request checklist

Cluster Tuning
Tuning a large network composed of

thousands of sites calls for the old divide-andconquer principle. This exercise is called cluster tuning, wherein the entire RNC area is divided into manageable pieces, investigated and then optimized one by one.

Objective
The UMTS KPI document strictly sets the

levels of performance that have to be met prior to a network launch. For cluster tuning purposes, a set of KPIs covering voice and packet data services were selected and presented in next slide. The UMTS KPI document specifies targets to be achievable in both unloaded and loaded conditions in the pre-launch phase.

Cluster Acceptance KPIs

CSV Accessib

Cluster Tuning Process


Preparation (Drive Route, Neighbors, Cluster Definitions) Drivetest (Unloaded network)

Process Flow Chart

Post-processing & Analysis Exit criteria met?

Formulate & Implement Change proposals

Y
Drive test (Loaded network) Formulate & Implement Change proposals

Post-processing & Analysis Exit criteria met?

Y
Documentation

Preparation
Information database
The RF engineer will need various information about the network in all stages of the cluster tuning process. To start with, a site database containing at least the following physical information should be in order.

Site location Sector azimuth Node-B type Antenna height Antenna type Antenna mechanical tilt Antenna Variable Electrical Down Tilt (VEDT) remote control capability Antenna sharing Feeder length Jumper cables Diplexer / Duplexer / TMA equipment

Information database contd


Panoramic photos taken during the site survey are also excellent

references whereupon tuning changes will be based later.

It is also important that actual RAN parameter information is always

available. This includes cell parameters, neighbor lists, actual antenna tilt which can be retrieved remotely at the NMC. Information can change on a daily basis so it is important to keep past records in a database to be able to view the history of changes that have occurred. simulation results at unloaded and loaded configurations. Coverage and interference predictions generated from the planning tool will be used as references for preparing the drive test route and for identifying potential problem areas. The tool is also a means to verify the effect of tuning solutions before actual implementation. For the actual pilot coverage of each cell in the cluster, one may refer to the data collected during the site verification drive test.

A planning tool with a properly tuned propagation model will provide

Neighbor Generation
This task should aim to create an optimal set of 3G 3G and

3G 2G neighbor relationships. Since neighbor optimization is an evolving activity, constant monitoring via performance metrics and correlation between neighbours actually loaded in the system and those that RF Engineers have specified needs to occur. The steps involved with neighbor generation could be summarized as follows: Use Asset 3G or other planning tools to come up with an initial neighbor list for 3G to 3G neighbors ranked by priority Run a consistency check to ensure all neighbors defined are reciprocal. Also ensure that the maximum number of neighbor list for a particular cell has not been reached Run a consistency check to ensure that co-scrambling code reuse does not exist up to 2 tier neighbours away

Neighbor Generation Contd


Use either Asset 3G, other planning tools with GSM neighbour

definitions to come up with an initial IRAT neighbor list If available, consult with each RF Engineer with local knowledge about the neighbor definitions Instruct NMC / UTRAN personnel to add neighbors for sites / clusters into the RNC Perform a manual / automated check of neighbors loaded in the RNC versus those designed to ensure correct neighbor definition exists Add any new neighbours found during cluster and market tuning exercises Use OSS Neighbour tools to optimize neighbours and increase system performance and KPIs

Drive Test Route


The clusters will be drawn such that all areas within the market or service area are included in a given cluster. The goal of the drive routes should be to ensure that all areas within a given cluster are thoroughly tested. Listed below are some considerations when planning the drive test route:

All cells should be driven through the performance of every cell should be measured as well as the handovers to and from every cell. Dive all the necessary primary, secondary and neighborhood roads where applicable, consider commuter ferry routes, rail lines etc as part of the route. In the case of downtown areas expect to drive every street in these areas. The route should be evenly spread out across the cluster area it should consist of a variety of distance and bearing points with respect to the sites. An even route distribution across the cluster ensures that subsequent statistical inferences are representative of that area as a whole. Minimize duplication of routes this will make post analysis more convenient especially when replaying log-files to zero in on particular call events Explore potential pilot pollution / low coverage spots refer to planning tool simulation plots of best server Ec/No & RSCP to locate the potential trouble areas. For the purpose of stationary or In Building test purposes - anticipated hotspots like commercial complexes, stadiums, train stations and airports should be identified.

Pilot Test Scan


GSM coverage is measured in terms of BCCH signal strength

with the use of a scanner that is tuned to the correct frequency. In UMTS, this is done by measuring the received signal level of the pilot channel after despreading; in other words, the CPICH RSCP which stands for Common Pilot Channel Received Signal Code Power. There is one pilot in every cell transmitting at a constant level all the time. Essentially, a scanning receiver will take two measurements: RSSI or the total downlink wideband power and the RSCP of each detectable pilot. From these two measurements, a third parameter which is the signal quality or Ec/No of each pilot is calculated with the simple formula, RSCP/RSSI. Since RSSI is actually the combined power of all the pilots including the wanted pilot signal itself plus thermal noise, then Ec/No always turns out to have a negative numerical value.

Pilot Test Scan Contd


The pilot test scan process allows neighbor list

analysis and should easily pick up major neighbor list omissions. In some cases it can also be used to determine neighbor relationships that are not really relevant. This process is required if neighbor lists become too large to be well managed by the vendor specific composite neighbor list generation algorithms. The issue occurs when soft handover is entered and each active set member has its own neighbor list, hence some rules are followed to determine the new composite neighbor list.

CSV Test
Two UMTS handsets will test circuit-switched voice service. They should be configured to operate as follows: 1 UE for Long call

continuous AMR voice call (MOC) to the system test number carrying voice information redial waiting time of 10 seconds after a dropped call or call setup failure, if encountered; this is to allow the phone to fully return to idle mode applicable KPI: CSV Quality (BLER)

1 UE for Short call AMR voice (MOC) to the system test number carrying voice for 90 seconds 150 seconds idle period between calls 10 seconds waiting time before retry in cases of call setup failure or dropped call applicable KPI: CSV Access Failure Rate, CSV Call set up time, CSV Drop Rate, CSV Quality (BLER)

PSD Test
Two UEs will test packet-switched data service and should be configured to operate as follows:

1 UE for PS data call downlink transfer


PS data call to download 2 / 10 MB data block from an FTP server 10 seconds waiting time from RRC connection release to the next RRC connection setup redial waiting time of 10 seconds after a dropped call or call setup failure, if encountered 32 byte Ping measurement every 30 seconds Applicable KPI: PSD Access Failure Rate, PSD Drop Rate, PSD Latency, PSD DL Throughput UE Mobile per RB, PSD Call Set up time

1 UE for PS data call uplink transfer


PS data call to upload 3MB data block from an FTP server 10 seconds waiting time from RRC connection release to the next RRC connection setup redial waiting time of 10 seconds after a dropped call or call setup failure, if encountered Applicable KPI: PSD Access Failure Rate, PSD Drop Rate, PSD UL Throughput UE Mobile per RB, PSD Call Set up time

Drive Test Speed


To simulate actual subscriber driving conditions and ensure evenly distributed data points, the following vehicle speed ranges must be observed. However, note that all times, drivers must not exceed the speed limit and must follow all signed markers.
Urban and dense urban15 to 20 mph Suburban 30 to 40 mph Rural and Highways60 to 80 mph

Measurement repeatability
In any field measurement exercise, it is vital that the tool is set up to allow for repeatable and accurate measurements. The goal is to minimize, if not eliminate, the possible sources of inconsistencies by taking the following Measures:

Use of external antennas for all UEs; otherwise, UE performance could vary relative to its position inside the vehicle Ensuring all RF connections are tight and secure to guarantee accurate measurements. If any cables or connectors are deemed to be damage, they should be promptly replaced Calibrate all scanning receivers to get precise and uniform readings Maintain adequate RF separation between the GPS, scanning receiver and UE external antennas on the car roof by placing them at least 2 wavelengths apart (28 cm. for 2100 MHz) As the devices may affect each others RF behavior if positioned side by side inside the vehicle, it is suggested that they are spaced properly or placed in individual rf isolation boxes, if available Use the identical drivetest vehicles for all teams with a clean accessoryfree top for mounting the antennas

Unloaded Test
The first step in tuning a brand new live network is to conduct

tests in an unloaded configuration. By definition, an unloaded network is one where only the common channels are being transmitted by the base stations. This section defines procedures to be used for cluster testing & optimization under no load or minimum load conditions (no appreciable traffic in the network). The unloaded pilot survey results identify coverage holes, handoff regions, multiple pilot (pilot pollution) and non-dominant coverage areas. The pilot survey information highlights fundamental flaws in the RF design of the cluster under best-case, lightly loaded/unloaded conditions. The pilot survey provides coverage maps for each sector in the cluster, these coverage maps are used to adjust antenna, azimuth, tilts, transmit powers and neighbor lists. Measuring the pilot levels without load serves as a baseline for comparison with measurements from subsequent cluster tests under loaded conditions.

Optimization Objective with Unloaded Test


Ensure that acceptable coverage is achieved from

the common and traffic channels Ensure there are no evident drop calls Ensure optimum Soft Handover areas and pilot dominance Compare the RF predictions with actual measurements Check the accessibility, reliability & quality under vehicular environment. Neighbor list tuning Meet CSV KPI targets

Poor Coverage Issue


Problems related to poor coverage may be tackled in several ways. In order of priority, they are as follows:

Verify the downtilts implemented at the site and determine whether they are actually necessary. If not, use the planning tool to see if the downtilts can be reduced to improve coverage. Reducing downtilt, however, must be implemented with caution: it should not be performed at the expense of non-containment related problems caused elsewhere. One has the option between mechanical and electrical tilts, or a combination of both, to achieve the desired result. With the use of remote remote tilting features, the electrical tilt can be conveniently monitored and adjusted via a terminal at the NMC in real time, at any time of the day. Changing the mechanical tilt, on the other hand, still requires deploying riggers to the site. Change the antenna azimuth to focus the main lobe where desired Change the antenna type to provide more gain or a narrower beamwidth is desired Increase the antenna height of the serving cell Increase the CPICH power setting check design limitations for minimum and maximum settings. The total power allocation for the common channels should not exceed the set limit to leave ample power for traffic

Lack of Dominance
When the problem is lack of dominance brought about by overshooting cells, too many strong servers, adjacent cells with excessive overlap or stray signals resulting from reflections, back lobes or side lobes, a different approach is taken. Again, according to priority, tuning can be done by:

Down tilting the antenna of the interfering cell either electrically or mechanically when doing mechanical tilts, be aware that the back lobes and side lobes may become aggravated leading to more problems. Be careful about opening up coverage holes especially indoor when downtilting. Tilting can be done in steps of 2 to 5 degrees depending on the severity of the interference. Changing the antenna bearing of the cells that contribute to pilot pollution. Changing the antenna type of the cells that contribute to pilot pollution, e.g., higher gains for the server, lower gains for the interferer. Increasing the antenna height of the server and reducing that of the interferer Changing the CPICH power setting increase the serving cells transmit power and/or reduce that of the interferer

Note: the preference is to control RF by exhausting all the possible hardware modifications first before changing the pilot power. Any variation in pilot power produces a proportional effect in the maximum power allocated by the cell for dedicated channels

Layer-1 Analysis

Measurement Plot Best server RSCP Best server Ec/No

Voice Call Analysis (Dropped calls and Call setup failures


The causes for the failures can be classified

into three groups: RF planning-related, network-related and tool-related. Technically, job of the RF engineer may be limited to fixing only those that fall in the first category but the rest still need to be properly documented and referred to the concerned departments for their action.

RF Planning problems
Inadequate downlink coverage, poor

dominance, pilot pollution Inadequate uplink coverage, uplink interference Missing or one-way neighbors Rapid field drop Slow handovers Scrambling Code interference

Loaded Test
The performance of the cluster is affected by the amount of traffic load it is carrying. For one, the effective coverage shrinks as the level of the noise generated by the system rises. The objectives of the loaded test are: Assess network performance at the amount of load for which it was designed Fix the additional Layer 1 problems that appear when the network is under load Perform a more intensive optimization campaign to meet CSV, PSD and CSD Video KPI targets in a loaded configuration

Market Area Tuning


Market area tuning is essentially the same as cluster tuning but on a literally larger scale to gather data from several clusters working together. The entire Market area now becomes one single cluster. Below are the objectives of this phase: Assess the over-all performance of the radio network from Market level Test inter-RNC handovers Identify new problems that degrade the network Devise tuning solutions for the new problems Meet performance KPIs at Market level Make the RAN commercial launch ready

Inter RAT Handovers


Following are the possible instances of Inter RAT handover requirement in the network. The information about the possibilities of these instances should be obtained by the engineer in order to develop a drive test plan for IRAT handovers. The approach for the UMTS network deployment is to start the rollout from the core areas and extend outward progressively and to match the EDGE footprint. Thus the UMTS coverage area would be a sub set of that of GSM. For several reasons like, inability to install UMTS Hardware, interference issues in the out door network (may just apply to very dense GSM presence area like ,Connaught Place, New Delhi), etc. the rollout of the UMTS network may not be 1:1 for those specific areas. Effect of loading (cell breathing) on UMTS may result in the weaker coverage area of UMTS network with respect to that of GSM. Presence of in-building coverage may be different for GSM and UMTS due to existing GSM in-building solutions and ability to pump RF towards the buildings in GSM.

Inter RAT Handovers Contd


Thus from the IRAT handovers point of view following objectives of the pre optimization check needs to be considered. IRAT boundary should not fall in the high traffic / high mobility area. Parameters should be set in such a way that UMTS capable UEs stay on UMTS until acceptable quality can no longer be sustained Success Rate of IRAT handovers should meet the target KPI. Performance impact of IRAT handovers/reselection on all the bearer services should be taken into account. IRAT in UMTS area will be equivalent to a drop and hence should be optimized to only trigger to maintain the quality/ continuity of the call whilst meeting the planning criteria.

Inter RAT Handovers Contd


Following is required to meet above mentioned objectives. Detailed drive test to clearly define the UMTS coverage area boundary in terms of RSCP and Ec/Io levels. The significant patches of absence of UMTS RF need to be marked clearly. Thorough analysis of loaded and unloaded drive data to point out potential creation of IRAT boundaries due to loading. Pointing out major traffic carrying buildings like airport, big malls having weak presence/absence of UMTS RF

Site Name Address Cluster Area

Definitions

Acronym AMR BCH BLER

Definitions

MOC MTC NMC PSD