CONFIDENTIAL

RAD IO ENG INEER ING SOLUT IONS

Procedures and Guidelines for Prelaunch Optimisation

CONTENTS

1 REVISION HISTORY

Revision Date Name Comments
1.0 04 August Paul Teixeira First Release

2 OBJECTIVES

This document aims to explain the procedures and guidelines used while optimising the network before commercial launch.

After reading this document, the reader should be familiar with the activities that are performed in this pre-launch optimisation phase and be able to address some of the common problems found during this phase.

3 BACKGROUND

Up to the Pre-launch Optimisation phase almost all the previous Rollout activities have been based on:

Theoretical knowledge of propagation characteristics, and GSM System design, Computer modelling, relying on digital topographic and morphologic data, and Previous experience of the Planning Engineer

It is therefore only logical that problems will be encountered in the real world that were not foresee in this theoretical approach. These problems can degrade the performance of the network and in some cased degrade the performance below the initial design criteria or targets.

The aim of the pre-launch optimisation phase is to detect the problems arising from the real world or practical limitations and to improve and where possible solve these problems. It must be remember that not all problems are solvable but hopeful they can be controlled to a point where they are acceptable.

4 MONITORING AND BENCHMARKING

There are two sources available for an engineer to use to monitor the network. The table below presents advantages and drawbacks of the two complementary sources.

Features

Represent a reproducible and Field Test objective customer Measurements view of network quality – suitable for competitors analysis Allows centralised data

NMS/OMC

collection – permanent flow of information – useful to monitor trends

Cost Efficiency

Very resources and time consuming

Geographical Scope

Restricted to specific areas – good to geographically locate problems – pinpoint coverage holes

Cost effective way to monitor network quality Limited geographical location of problems – can locate problems on a per cell (TRX,TSL) level

Before the commercial launch of the network, the subscriber numbers are low which results in an almost zero-count for most statistics collected by the NMS. The engineer is therefore unable to use this source during the pre-launch optimisation stage to diagnose most problems, hence almost all pre-launch optimisation are based from the detection of problems by monitoring Field Test Measurements and the improvement/degradation of the results from these measurements.

However other NMS Reports such as Equipment Alarms are useful to detect possible problems and can also provide answer to the poor performance found in a Drivetest.

Recent developments in vendor support systems have provided one more source of NMS performance data. The source of data is derived from the Measurement Reports sent from the mobile, and uplink measurements made by the BTS on active connections.

Alcatel's RMS and Ericsson's MRR are two such systems and can provide more insight to a problem by collecting data such as Timing Advance Distributions, Distribution of Signal Level on the Uplink and Downlink, Uplink and Downlink RXQUAL Distribution and Power Reduction/Control. The data collected from each of these indicators can be displayed individually or combined to help diagnose problems. For example the RXQUAL versus the Signal level distribution could indicate if the interference problem is due to low signal strength or poor frequency allocation plan.

As mentioned before, this data is collected from active connections and hence if the number of subscribers or network traffic is low, the sample size may be too small for valid statistical analysis. However this document will indicate where such data may be of use.

5 PRE-LAUNCH OPTIMISATION PROCESS

Implementation

Physical Site Optimisation

Neighbour Optimisation

Frequency Optimisation

Parameter Optimisation Customer Requirements

Field Tests Survey Strategy

Field Test Routes Definition

Site Configuration Change Request Field Test

Measurement Collection

Drive Test

Data Analysis and Interpretation

YES
NMS Reports
Problems Found?
NO
NO
Achieved Targets?
YES
Pre-launch Optimisation
Completed

Pre-Launch Optimisation Process

5.1 Drive Tests

5.1.1 Field Test Survey Strategy

The RNP group will organise teams and equipment to carry out field test measurement surveys. Since this activity can be very time consuming, extra personnel can be involved. In this case the RNP group will instruct the survey teams to be able to concentrate more on the interpretation of the measurements results.

5.1.2 Field Test Routes Definition

The RNP group will define the routes to be followed by the survey teams. These routes should be adhered to and reviewed only ever few months or where an areas dynamics have changed.

Examples of such changes include but are not limited to: new site integrations, new building developments and new major roads.

In the case where extra personnel carries out the measurements, it is recommended that the RNP engineers issue a field test measurement request form with a route map attached.

5.1.3 Field Test Measurement Collection

Drive Test Teams should conduct the field tests in keeping with the guidelines, strategies and routes defined by the RNP engineers.

Teams should take notes of any equipment problems and other abnormal events (site outages, swapped sectors etc.) and inform the appropriate parties. If the problem can be rectified on-the-spot, the teams should continue the drive test, else discontinue the Drivetest until a further date.

After carrying out the requested measurements, the survey team will produce a report of the key performance indicators of the network. This report will then be provided to the customer.

5.2 Data Analysis and Interpretation

The analysis and interpretation of the drive tests will allow the RNP engineers to assess the performance of the network, detect network problems and recommend changes to improve the network.

The combined use of all sources of data is strongly recommended for a complete investigation of a later stage network. This section will contain some example of common problems found on the network and how they are interpreted.

5.2.1 Undefined or Missing Neighbour

This problem is listed first because the symptoms can mimic those problems described later. An example of misdiagnosing of a missing neighbour is when the Drivetest shows that the signal level is dropping below the coverage target, which is then misinterpreted as a low coverage problem. Therefore it is better to analyse the Drivetest data for a missing handover before proceeding to detect the other possible problems.

Before going through examples of the diagnosis of a missing handover, one must be aware if Downlink Power Control is active on the current connection or not. Power Control has the effect that the signal level measured may not made with the BTS at full power and hence can not be compared with the reported neighbour signal levels which are always made on the BTS transmissions at full power.

This can be done by checking the parameters of the cell in the OMC, the Drivetest and using the following table. This will help in deciding the likelihood that the signal level of the current connection has been reduced by the effect of power control.

Current connection only using BCCH carrier No Power Control Used

Power Control disabled on cell
No Power Control Used

Serving Cell BCCH in BA-Active list and is reported to have a RXLEV consistently close to the RXLEV of the connection (by 1-2dB) No Power Control Used

RXLEV below the desired DL Signal Strength value or outside the DL Power Control Window (by 2-3dB) Most likely No Power Control Used

RXLEV near DL Desired Signal Strength Value or within the DL Power Control Window Most likely Power Control Used

Serving Cell BCCH in BA-Active list and is reported to have a RXLEV consistently greater than the RXLEV of the connection (by 2-3dB) Most likely Power Control Used

As it can be seen in the above table there are cases where one can not definitely say that power control is or is not being used – mainly due to the fact that the BTS does not inform the mobile of the power control used. Therefore in cases where there is doubt, further Drivetests can be made to verify the problem. In cases where the serving cell RXLEV is also reported as one of the neighbours then by using this RXLEV value the effect of power control can be ignored. If this is not the case and power control has most likely been used for the connection then the Drivetest may be showing normal operation.

If the missing neighbour uses a BCCH frequency that is already defined as part of the serving cell Active BCCH Allocation list then detecting the missing handover is fairly easy. An example of this scenario can be found in the next figure.

From the figure we can see that the connection is on the BCCH, so from the previous table Power control is not in use. We can further see that the mobile is reporting a signal (blue line) that is stronger than the serving signal (brown area) but that no handover has been attempted to this stronger cell.

This example suggests that the "blue" cell is a strong candidate for a missing neighbour, but the checks below need to be performed to confirm the diagnosis:

• Check if reported BCCH/BSIC combination match to a known cell in the network. If no BSIC is decoded, use planning tool to find a probable cell. If no matching or probable cell can be found as a candidate then investigate if other operators are using that frequency
• If a neighbour relationship is already defined to the candidate cell:

o In the case that the BSIC was not decoded or only available intermittently then check for possible inference on the candidate. If a BSIC can not be reliably decoded, a handover will not occur. o Check if the cells are controlled within the same BSC, LAC and/or MSC. If any of these are different, then check the relevant databases to ensure that cell identities and handover information are defined correctly.

o Check for congestion on the candidate cell. If it is congested, no handover will occur. o Check parameter "Disable Incoming Handover" for the candidate cell. If incoming handover is disabled, mobiles will not hand to the cell.

o Check HCS layer settings and other vendor specific handover algorithm parameters for possible causes. o Check the transmission of the candidate cell. Some vendors have designed their equipment to continue transmitting the BCCH carrier even if the BTS is not connected to the rest of the network. However if you see soon after in the Drivetest that the candidate cell was in fact used, transmission failure is unlikely the cause.

A change request should be issued only for the missing neighbour in the case the all the checks show up no other problem. Problems that are detected during the checks should also be corrected by issuing a change request

If the missing neighbour uses a BCCH frequency that is not defined in the serving cell Active BCCH Allocation list then detecting the missing handover is harder but not always impossible. An example of this case can be found in the next figure.

In this example we can see that a handover occurred to a cell (the blue line before the first handover) that was detected as stronger than the server, then immediately after the handover a new cell (light blue line) is measured which is stronger than both the new and old serving cells. A second handover is then made to this new strongest server.

In this case there is a strong indication that the original serving cell and final serving cell should be defined as neighbours. If a neighbour relationship is already defined to the candidate cell following checks should be made:

• Check the Measurement Frequency List from either the System Type Information 5 or from the OMC. If the neighbour frequency does not appear in the list then no handover will occur.
• Check if the cells are controlled within the same BSC, LAC and/or MSC. If any of these are different, then check the relevant databases to ensure that cell identities and handover information are defined correctly.

If no relationship is defined then a change request should be issued to add the missing neighbour.

In some cases it may be advisable to delete and recreate the neighbour relation in case there has been a corruption of the OMC/BSC configuration database.

5.2.2 Low Coverage Problem

This is generally the simplest problem to detect and analyse. However the solution to this problem is normally not the easiest to implement.

The reason that the low signal level condition is evaluated for is because a general side effect of a low signal is that the C/I also reduces. This lowering C/I causes then quality of the call to be degraded, firstly the BER increases to a point where voice quality is degraded and then later to when the FER increases where voice samples are lost all together and finally to a dropped call.

If the interference condition was evaluated before the signal level, the optimisizer might be tempted to diagnose the problem as poor quality and retune the frequencies only to find that he or she has wasted their time because the real cause of the interference is thermal or background noise which cannot be mitigated by a frequency change.

The solutions for correcting low coverage problems are:
1) Increase radiated power by increasing BTS output power or reducing BTS

loses
2) Redirect, tilt or increase the height of antennas.
3) Use a repeater to extend coverage area of existing cell
4) Build new base station to expand network coverage.

Depending on vendor equipment, it may be possible to increase the output power to the maximum rated power via a software command or replace the TRX with a higher power TRX.

Another possibility may be to reduce combiner and/or feeder system loses by either implementing the concept of "air-combining" or using lower-loss feeders. Air-combining is a concept that instead of using a filter/hybrid combiner to combine 2 TRX outputs to one antenna a separate antenna is used for each TRX and thereby removing the 3dB to 3.5dB loss introduced by the combiner.

It is important to remember that the downlink and uplink coverage must be balanced, so by increasing the downlink coverage it may be necessary to match the uplink coverage by adding a TMA.

If the low coverage problem exists in an area that is close to an existing site and is caused by obstructions, then it may be possible to solve the problem by increasing the height of the serving cell antennas sufficiently to overcome the obstruction.

If the low coverage problem existing in an area near an existing cell but is situated in a direction that is between the sectors of the site (the "null") then it maybe be possible to redirect the sectors slightly to obtain some improvement.

Redirection is a "give and take" technique, it will give some signal for the area that is now in the main beam but will take some signal away from the area that was in the old main beam. However if in the direction of the old main beam there was excess signal strength or there is another site that could cover the area within the design targets then the redirection can be advantageous and increase the total area meeting the design target.

Uptilting of sector antennas may provide some gains in cases where the bore-line angle falls short of the problem area. However the negative side of doing so is the increased spillage from the cell which may cause interference to other cells. In most cases placing the top -3dB angle/point above the horizon will not provide any signal level gain.

In rural areas and where the capacity requirements are low, it may be possible to use a repeater to cover the low coverage area. There are many repeater products available on the market so selecting the best repeater must be done on a case-bycase basis.

When analysing low coverage areas it is important to check if the low signal is due to power control in which case if the quality is acceptable there is no problem to be fixed.

The figure above and the next map show an example of a low coverage problem. The possibility of a missing neighbour relationship has been previously ruled out.

In the next signal level graph you can see the signal level is decreasing steadily from when the call is started until about midway of the call at which stage it begins to increase. As mentioned previously as the signal level decreases so does the C/I and quality, this can be seen from the graphs; the calculated C/I decreases, the RXQUAL (BER representation) increases, the Speech Quality (SQI) decreases, and the Frame Erasure Rate increases.

In the map the route has been shown and the midway point is has been selected. The signal level decreases while the mobile is moving away from the base station up until the midpoint, where at the mobile changes direction and starts to move back towards the base station. In the list of the serving and neighbour cells it can also be seen that the signal level of the server and the neighbours are all below 100dBm and the designed threshold.

In this example the distance measured to the low coverage area fairly far and from the current antenna directions the low coverage is in the null of sectors 1 and 2, but it would be unlikely that a major improvement could be obtained (without degrading the other areas below acceptable limits) by redirecting the sectors to better cover the area.

Further analysis shows the signal level is below the outdoor coverage level so the use of high powered TRXs or low loss feeders will not significantly help. There are no more sites to the South-East so the serving cell is on the edge of the network, but considering that the low coverage area is still within the town limits the best solution would be to build a new base station.

The next map view on the following page shows another example of a low coverage problem, however in this example the area is surrounded by sites and not on the edge of network. Analysis of the area shows that there is no significant obstruction near the serving site and the distance to the problem area is on the edge of the designed coverage radius. Further inspection of the low coverage area results in the conclusion that the area is significantly more dense (roads are very narrow 4-5m and buildings are contiguous) with little chance of line of sight or reflected and refracted signals from the surrounding cells penetrating enough to reach the mobile.

The best solution again is to build another site in or near the area because area is dense and hence will have high traffic (repeater does not increase capacity) and only a over-the-rooftop signal will be able to penetrate enough to reach the mobile (reducing the feeder losses or increasing the output power will not improve penetration into the area)..

5.2.3 High Interference and Poor Quality Problem
The degradation to the network caused by high interference or poor quality can
include the following:
• An increase in Bad Speech Quality
• A decrease in GPRS transfer rates with high number of retransmissions
• An increase in dropped calls (from radio link timeout)
• An increase in handover failures and handover drops
• An increase in call setup failures

The major source of interference is the cells within the operator's own network and therefore is normally controllable or sometimes can be completely eliminated by the operator.

Other same technology and band operators followed by other different technology and same band operators are more sources of interference to a lesser degree. A point to bear in mind is that sometimes the interference from these sources can not be detected from Drivetests because they are either within the uplink band of GSM or use a difference technology. In theses cases the idle channel measurement statistics available from most vendor systems and wideband receiver (spectrum analyser) tests can help to detect these external sources. Background noise or thermal noise is the last source of interference but it is usually only a problem at very low (<100dBm) receive signal levels. However in areas with a high site density, the noise floor (from thermal noise plus the spillage from other cells) can be substantially increased and cause an interference problem that is difficult to solve.

Because most interference results from within the operator's own network, it is this type of interference that will be targeted during the pre-launch optimisation.

Some of the methods available to improve on interference problems include:
1. Change of frequencies on server and/or interferer (and in some cases a

local retune around the affected area)
2. Downtilting of interferer in cases where there is too much spillage
3. Increasing output power of server and/or decreasing output power of

interferer
4. Implementing of power control, frequency hopping and DTX

Detecting interference from Drivetest logs is somewhat easy however the Drivetest logs usually do not specifically identify the source. Some examples from Drivetest measurements are shown next.

In the figure above, it can be seen in the section before the first handover that many neighbours (the lines of different colours) are being reported around equal signal level, this indicates that there is a lack of dominance in the area. Many handovers occur during this short section with some being obviously due to interference (since the power budget criteria – the HO margin of 3dB – is not met). In this case it will be unlikely that the problem can be resolved with just one frequency change. Solutions to this type of situation will be discussed further on.

Single Interferer In cases where interference is between two specific cells the first method – a frequency change on either the server or the interferer – can correct the interference problem.

The detection of whether or not the interference is from a single source or many can vary in complexity. The first step is to look at the frequency plan for the area and find the most likely interferers. Sometimes a very dominant cell or a cell that is very high (a boomer) can be quickly identified with this method.

Multiple Interferers When the area with high interference receives many signals from different cells at similar levels the problem is compounded exponentially for every extra interferer. In these cases local area frequencies retune maybe necessary to reduce the interference to within acceptable limits. The extreme case of this is where there are so many signals that effectively you have a raised noise floor, and frequency retuning will rarely obtain any gain.

In networks which have tight reuse of frequencies or that use fixed groups, or in low cell density areas bordering high cell density areas, this raised noise floor can become a major problem. Implementation of Frequency Hopping may help by averaging this interference out but it cannot eliminate it.

When faced with such an increased noise floor, the remaining methods are better suited to improving the quality in these high interference areas. Their main objective is to decrease the interference without decreasing the carrier power such that the C/I ratio improves sufficiently to achieve good quality.

Down Tilting of Antennas The goal of downtiliting is to match the coverage area (footprint) of a cell with the serving area of the cell. If the coverage area of the cell is larger than the serving area then the cell is effectively spilling RF interference energy into the surrounding area.

To correctly tilt the cell, the planner must determine the border of the cell and then tilt the antenna such that the cell edge is within the top half of the main lobe. The exact tilt depends on the vertical beamwidth and electrical tilt of the antenna and what the target range of the cell is.

As a first guideline, placing the top -3dB point of the antenna above the horizon is not recommended normally since this would result in a large portion of the transmitted energy being lost into "space" or worse being trapped in atmospheric thermal ducts to only return to the ground at some far off distance and interfering with the cells in that area. The following paragraph may suggest a tilt that does not follow this initial recommendation and if so, the pros and cons of doing so need to be assessed and a compromise reached.

If the cell is there to provide coverage in areas where there is low site density (rural or open areas), then the centreline of the antenna main lobe may be pointed towards the cell edge. If the cell is to provide coverage in an area where there is a high site density (urban areas), then the top -3dB point of the antenna main lobe should be pointed towards the cell edge.

In areas with uneven terrain, the decision process for tilt angle needs to consider the relative difference in height between the BTS antenna and the MS. For example, if the antenna is pointed up towards a hill, then the top -3dB point should be just above the top of the hill. This will reduce possible spillage further on (also reduce uplink interference to the cell) and concentrate the transmitted and received power within the target area.

In order to gain a clear definition of the cell edge/border many Drivetests need to be performed and analysed. Look for the area where the cells are received at equal powers, if both the cells are down tilted to this edge then the final power levels at the edge will not change by much but the spillage will be reduced significantly. However if the signal levels at the cell edge are still very high (+3dB above the level considered to be sufficient for good indoor coverage) then tilt the antenna further until the signal level at the cell edge is acceptable.

Cell edges should roughly be equidistant between 2 cells which will in turn balance the traffic between them. Sometimes a large barrier or obstruction which one of the cells can not overcome defines the cell edge. Examples of such obstructions include top of hills or large built up areas.

Once the cell edge or range is known, some simple trigonometry constructions can be used to calculate the correct tilt angle. If Timing Advance distribution data is available from the OMC/NMS then these may also help in defining the cell edge or range. Using this data, an engineer can tilt the antenna such that the top -3dB point of the antenna main lobe to the cover the majority of the traffic/users.

Below is a Timing Advance Distribution Graph of cell that has areas of spillage. In this example it would be good to downtilt the antenna such that the top -3dB point falls about 6km (TA = 12) from the site. This should shed the unwanted traffic around 9 and 15km away which is degrading the cell's performance

25.00% 100.00%

90.00%
20.00% 80.00%

70.00%
15.00% 60.00%

50.00%
10.00% 40.00%
30.00%

5.00% 20.00%
10.00% 0.00% 0.00%

11 13 15 18 20 22 24 25 27 29
% of samples cummulative % of samples

Power Adjustments to Server or Interferer In areas with good coverage but poor interference it may be possible to reduce the signal level of either the interferer. This increases the C/I ratio of the server and may lead to an improvement in performance.

Increasing power on a server that is well contained (a low site or coverage area is limited by barriers or obstructions) and is interfered with by another cell can usually lead to a better C/I and improved performance as well.

Network Features Implementing conservative power control settings (those that have quality thresholds well within good RXQUAL values and high RXLEV) can still offer improvements since the major gains are obtained with the first 2-3dB of power reduction.

DTX and Frequency Hopping can both reduce the interference that any single connected MS receives and hence obtain better network results.

5.3 Site Configuration Change Requests

All problems detected in the previous section should result in some requirement for a configuration change. The change could be one that just requires a software command to be implemented or one that requires some physical change to be implemented.

Whatever the case may be it is important to document the changes by completing a Change Request. This prevents someone in the future removing a much needed neighbour or changing an antenna configuration on the notion that the configuration does not seem logical.

Change requests should document the reason and the change itself, identify the possible effects to the network such that the performance counters can be evaluated to see if the change has improved the performance or not.

5.4 Implementation

The optimisation cycle should start again once the change requests have been implemented by either change in:

• Allocated Frequencies on Server or Interferer
• Antenna Configurations
• Neighbour Definitions
• Parameters controlling Network Features

Because not all changes will result in performance improvements it is important to re-evaluate the network after the change has been made and fall back when necessary. Such fall backs should also be documented as an annex to the original change request.

The optimisation process is repeated until the performance targets are achieved or until all possible solutions have been tried. Those problems that were not solved should be documented and revisited every few months in case a new solution can be found (for example after a new site has been integrated or a new feature available).

Anh Đức Blog

Thứ Sáu, 30 tháng 8, 2013