3g radio network optimisation best practices

Internal

3G RADIO NETWORK OPTIMISATION BEST PRACTICES RSQ

Product Technology Innovation/Network Architecture and Design/Radio Strategy and Quality Page 1/34

GT/NAD/RSQ/RNO/2005-0015 Version: V1.3 Date: 16/06/2005

3G RADIO NETWORK OPTIMISATION BEST PRACTICES

Page: 34 LEVEL: INFORMATION

Executive summary After analysing the optimisation methods in France and UK several key points are highlighted to provide the baseline for best practice optimisation process. These points might not be covered by the current processes and activities and a gap analysis is provided to enhance future activities. A good trade-off between time to market, flexibility, network performance and cost is paramount to deliver a good customer experience as early as possible. To achieve these goals a two phase optimisation is proposed whereby coverage is the main focus of the first phase including 3G to 2G handover performance. A second phase which can be completed after the coverage availability to the customer can drive the performance on a higher standard by tuning the different parameters. By consistently reporting RF and network KPIs for all MCOs (by aligning tools, measurements, and methods) the optimisation processes will provide similar customer experience across the different countries. The key points are described as follows: Requirements for a corporate Optimisation strategy: time to market and network performance

trade-off is key to 3G market success to reach a critical population coverage percentage for the market to take-off as soon as possible (NTT DoCoMo experience has shown that one of the key parameters for market take off was 60% population coverage).

3G 2G focus should be very high on optimisation priorities: at the moment no clear focus on 3G 2G interactions to improve customer experience on coverage.

Optimisation time scales should be a good compromise between network performance and coverage availability. The definition of the process can significantly help prioritise the tasks to be achieved before commercial availability of the network. A two phases proposal is formulated in the present document as a trade-off between the technical requirements of an optimisation activity and a delivery of coverage to the customer as soon as possible.

Consistent RF and network KPIs for all MCOs: aligning tools, measurements, and processes would allow consistent reporting. More importantly it would allow sharing experiences between networks on optimisation and provide similar customer experience.

Competitor benchmarking should be a good measure of competitive presence in terms of coverage and achieved performance after optimisation roll-out has been performed.

Participation of Orange France and UK to complete and define best optimisation process based on the lessons learned in France and the UK is reflected throughout the document.

Next Step: Provide guidelines on the use of tools to measure the specified performances.

This document will be updated on a regular basis to include all the progress made on optimisation experiences and include all the lessons learned from the different MCOs.

Internal



Written by : Yann Farmine Date: 20/05/2005

Signature

Checked by: Alain Wyns Date: 23/05/2005

Signature

Approved by: Alain Wyns Date: 23/05/2005

Signature

IMPORTANT These documents are Orange confidential and it is the responsibility of each Member Company not to transfer, nor copy, even partially, these documents to individuals not belonging to Orange Group without the written approval of Radio Strategy and Quality

Internal



TABLE OF CONTENTS

1. INTRODUCTION ........................................................................................................................... 5

2. LIMITATIONS ................................................................................................................................ 5

3. MOTIVATIONS FOR A BEST PRACTICE PROCESS ...................................................................... 6

3.1. Important Lessons Learned........................................................................... 6 3.2. BEST PRACTICE Optimisation process ......................................................... 7 3.3. Optimisation TASKS.................................................................................... 11

3.3.1. Deployment in clusters ......................................................................... 11 3.3.2. Cluster definition .................................................................................. 12 3.3.3. Cluster availability ................................................................................. 13 3.3.4. Site audit.............................................................................................. 14 3.3.5. Scrambling Code strategy. ................................................................... 15 3.3.6. Site Design impact on performance...................................................... 16 3.3.7. Drive test route definition ...................................................................... 17 3.3.8. Acceptance route definition .................................................................. 18 3.3.9. Preparation work before a drive test. .................................................... 18 3.3.10. RF CHAIN SETUP ................................................................................ 18 3.3.11. AERIAL Parameters Change control Process........................................ 20 3.3.12. Inter-cluster optimisation ...................................................................... 20 3.3.13. RF KPIs................................................................................................ 20 3.3.14. Network performance KPIs .................................................................. 21 3.3.15. Downlink Load ..................................................................................... 22 3.3.16. Exit/Acceptance Report specification ................................................... 22 3.3.17. Drive test methods ............................................................................... 22 3.3.18. Tools guidelines ................................................................................... 22 3.3.19. Optimisation Time scales and resources............................................... 22 3.3.20. Problem Areas identification and solutions............................................ 23 3.3.21. Single frequency deployment ............................................................... 24 3.3.22. Class 11 and Operator Use only process.............................................. 25 3.3.23. Infill site optimisation process ............................................................... 25 3.3.24. Common vocabulary ............................................................................ 26

3.4. Coverage targets......................................................................................... 26 3.5. Neighbour definition .................................................................................... 26

3.5.1. 3G 3G neighbour identification process ............................................. 26 3.5.2. 3G 2G neighbour identification process ............................................. 27

3.6. 3G 2G interactions performance............................................................... 27 3.7. RF Optimisation AND SYSTEM Performance KPIs....................................... 28

4. GAP ANALYSIS .......................................................................................................................... 31

5. CONCLUSIONS.......................................................................................................................... 33

6. DOCUMENT HISTORY................................................................................................................ 33

Internal



7. REFERENCES............................................................................................................................. 33

Internal



1. INTRODUCTION

This document attempts to summarise the task in best practice optimisation processes based on current knowledge of UMTS optimisation and the processes designed in MCOs which are in a lead position in terms of roll-out. Throughout the document the differences in optimisation processes in the different countries are analysed to form the basis of a best practice document. This document requires updates as more documentation becomes available either through formal reviews with the different countries of by informal meetings with the different parties involved.

2. LIMITATIONS

This document is based on the documents listed in the references and might not reflect the actual process followed in the countries either because a document is missing or because the processes are not documented. Moreover, the optimisation activity ownership is very different in each country and no process specification is a requirement in each case, e.g. only acceptance specification might be sufficient when the manufacturer is in charge of the optimisation process. Therefore this document should be seen as a snapshot of the current visible optimisation process status and provide information on best practices for countries wanting to set-up an optimisation process based on the lessons learned in each country. Moreover, a gap analysis is made to provide recommendations not available in any MCO at the current phase of optimisation roll-out. However, each MCOs has country specific constraints which are clearly seen in the way the MCOs are organised and function. Many of these aspects are out of control of the centralised team such as: Engineering team resources ( number of radio engineers and their technical knowledge), roll-out volume and time scales, network vendor, budget for tools, history in organisational structures,none of which has been considered in the scope of this document. This document has to be adapted to each country specificity and be considered as the aspiration process for all MCOs.

Internal



3. MOTIVATIONS FOR A BEST PRACTICE PROCESS

The main goal of aligning processes and network performance is two-fold: Provide similar customer experience across all Orange MCOs. Share experience between the MCOs:

o To achieve best performance possible. o To achieve best use of all engineering resources across MCOs (avoid duplication of work

and reduce costs). The resources are not the same for smaller MCOs than bigger MCOs and the work carried by bigger MCOs alleviates the pressure on the smaller MCOs very effectively.

A common approach would benefit in the long-term as experience across the different countries would be shared and provide a common customer perception of Orange network.

3.1. IMPORTANT LESSONS LEARNED

The lessons learned from the MCOs and the discussions involved are documented in the following order: from most important and general to the more detailed and specific. Whatever the process was the pressure of the time scales and resources limitations have

determined many of the choices on the tasks to perform. In some cases (e.g. crash programs) the process was specifically designed to meet the time scales requirements for launch. This reinforces the need for a process with built-in priority. This priority should be in the order of the tasks to be executed from the most important to the least important. The importance is assessed in terms of returns on system performance for the cost of executing the task. This way of defining the process would simplify the choices to be made when the process time scales or engineering resources have to be reduced.

Most of the issues related to the roll-out could be down to the operational aspects. And it is

possible to improve significantly the efficiency of the optimisation process if the time invested in those checks are made as early as possible in the process:

Defining a training cluster per regional entity is the best knowledge transfer possible, as

the teams would experience very early the issues they have to deal with. Focusing the acquisition/build/implementation teams on cluster delivery and driving the

delivery based on number of Node Bs available per cluster. A classification of the site in a colour code (Red, Amber, Green to assess likelihood of the site to be on air on time help the teams to plan the roll-out at all levels (radio and not radio related teams).

Creating a strong link with the core network team is paramount at all phases of the roll-out: delivery, site integration, site audits, cluster optimisation. A huge amount of time was wasted because the core network team and radio team were not in sync. The radio optimisation team can not proceed on its tasks if the core network issues detected are not solved in a cluster by cluster basis.

A process or tool to detect Core network issues is key for radio optimisation teams. Site audits/verifications and stability checks are critical too:

Scrambling code discrepancies/ Cross feeder issues can be greatly reduced by driving the network vendor at commissioning stage. For example the percentage of such issues in the Paris region was substantially reduced from 20% to 3%.

Stability of the Node Bs by checking alarms prior to the site audits and stability monitoring before drive test can save a lot of time.

Internal



The 2G processes have been aligned with the 3G processes: the optimisation based on clusters has been also adopted for the 2G process. It would more cost efficient to use the same drive test team to perform the periodic 2G optimisation.

Requirement for a tool to define the neighbours from the drive test data: at the current stage each country has built a custom in-house tool.

A tool to detect database discrepancies is key: check reciprocity or re-parenting issues. Note: a nice to have process would be to predict RA/LA growth.

3.2. BEST PRACTICE OPTIMISATION PROCESS

The current optimisation guidelines available are broadly speaking covering the same aspects of UMTS optimisations. In the proposed optimisation process the requirements are covered in the process in order of importance through two phases. This proposition is the main change compared to the current processes. By ordering the tasks based on the priority even if the processes are not performed completely would guarantee best minimal performance. The process described in the following paragraphs is designed for a cluster optimisation. Once the clusters have been optimised, the inter cluster optimisation can be performed. PRE-LAUNCH PHASE

1- Delivery of network based on clusters: focus implementation and build teams to deliver clusters of sites with high probability of number of sites available in the same clusters. If the cluster availability is below 80%, depending on expected availability in time, only coverage maximisation should be the main focus of the radio teams.

2- Planning tool based pre-optimisation: based on the cluster availability which should be updated compared to the nominal plan and potential availability of sites during the radio optimisation phase, review all tilts specified at nominal plan stage to take into account coverage gaps to be filled and fine tune the required tilts. A high percentage of the tilts had to be reviewed when the objective should be to minimise the number of changes required from the first drive.

3- Site audits prior to any optimisation activity: checking site characteristics saves invaluable time before optimisation process is started. Several scenarios are possible at that stage involving either the teams responsible for the commissioning of the site or optimisation teams. On top and above all the points specified in the document the following procedure were confirmed as good practice:

- Check Alarm status. - Test services (voice, video, PS) on at least one sector/site. - Produce site panoramic pictures.

4- Minimal network performance: a. Maximise coverage. b. Neighbours definition:

i. 3G 3G neighbours monitored by drop call rate. It is the key activity to drive the performance of the network.

ii. 3G 2G neighbours and HO success rate. It is key activity for the perceived coverage from the users perspective.

5- Reduced System KPIs benchmarks: to capture network vendor issues or data fill issues. Note: the main complaints from the 3G services in France were based on voice drop call rate because users are comparing their coverage to the level of GSM performance. The PS switched services are more robust and users do not have previous experience with packet switched services to compare with (unless GPRS which has a lower throughput). On the system KPIs achieving as much as possible as good as 2G performance should be considered to be the goal. POST-LAUNCH PHASE

Internal



6- Improve RF KPIs globally on a cluster basis:

a. Improve Dominance. b. Reduce interference.

7- Extended system performance benchmarks to monitor customer experience (includes the End to End tests).

This process is the result of a good trade-off between commercial network availability and system performance. PRE-LAUNCH should be carried out first on the widest area possible across the country and use all resources available. POST-LAUNCH should be carried out once PRE-LAUNCH has been rolled-out in most available areas. Several other scenarios are possible based on the two phase approach such as: Roll-out teams focus on PRE-LAUNCH hand-off to regional teams for POST-LAUNCH. Outsourcing of PRE-LAUNCH (network vendors or service providers) and handoff to regional

teams for POST-LAUNCH. The benefit of splitting the optimisation process in two phases is lost if the phases are performed sequentially (increasing time to market). However, the implementation of the phases sequentially still carries the benefit of prioritisation of the different tasks; focusing delivery teams on the most important tasks and adapt to the roll-out pressure by not performing nice to have tasks.

Internal



OPTIMIZATION PROCESS

PROCESS ACTIONSSTAGES

- Pre-optimization of RFparameters such as tilt andorientation based onprediction tools.- Scrambling Code planningincluding likely late sites.- Cluster definition.

Planning phase

ClusterAvailability >=

80%?

NO

Site Audits

YES- Update Tools RFparameters- Update Feeder Loss.- Neighbor list update basedon LOS measurements

Drive Test Routedefinition

Drive Test

Pass:- Coverage targets.

- Drop call rate.?

RF ChangesReview

NeighboursNO

- Update Tools database.- Update Neighbor list innetwork database:- 3G-3G neighbors.- 3G-2G neighbors.- RF Changes (tilt, azimuth)due to Poor coverage shouldbe cross-analyzed based onpanoramic and site auditinformation.

Pass 3G-> 2G HOsuccess rate?

YES

ReviewNeighboursNO

COMMERCIALAVAILABILITY

START PRE-LAUNCH:

PREPARATION PHASE

COVERAGE ANDNEIGHBORS LISTTUNING

END PRE-LAUNCH

Internal



OPTIMIZATION PROCESS

PROCESS ACTIONSSTAGES

- Update Tools RF parameters- Neighbor list if changes in listexpected (uptilt on site that wouldpropagate further).

START POST-LAUNCH:

Improve RF KPIs

IMPROVEMENT ONSPECIFIC ROUTES orSPECIFIC AREA(Corporate customers orhigh traffic areas).

SYSTEM KPIs

- Analyse RSCP and ECIOdistributions for the whole cluster.- Identify Poor Dominance areas fromcentre of cluster or from high trafficarea outwards.

- Propose a dominant site for uptilt anddowntilt other sites covering poordominance area.- This work should be carried byanalysing terrain, clutter andpanoramics to assess likelihood of RFchanges impact

Has the global RSCP and ECIOdistribution improved (compare

average and tail)?

NO

Note that the interferencemight shift away fromprevious geographicallocation to another area. Ifthe new problem area is aless important area from amarketing or trafficperspective, then the RFchanges can beconsidered as a success.

Has the problem area improved?

YES

NO

SYSTEM KPIdrive test on

acceptance route.

Pass system KPIs?

EXIT REPORT

YES

NO

Internal



3.3. OPTIMISATION TASKS

3.3.1. DEPLOYMENT IN CLUSTERS WCDMA technology makes an efficient use of the spectrum by using one co-channel frequency everywhere. The drawback of such system is a need for managing the interference between neighbouring sites. The system coverage and capacity heavily depends on how the interference is managed. The dominance of a site which is the ratio between the useful signal and the interference has to be maximised. From a theoretical point of view, on a flat earth and regular site to site spacing, the interference contributions of sites three tiers away are negligible. Obviously this is an approximation and in a real scenarios what is described as tiers of sites based on distance should be based on the interference matrix predicted by a planning tool. Therefore the distance should be assessed as sites with significant radio propagation up to another site.

Figure 1 Clusters

Figure 1 shows two theoretical examples which would provide a good picture of cluster definition requirements. On the left, the site in the middle is surrounded by two tiers of sites and the interference this site suffers is well estimated if all sites are radiating and further tiers of sites would not significantly change the interference the site would have to cope with. However, out of the cluster based on 19 sites, it is the only site which has a good estimate of the interference. If the interference has to be well established for the site in the middle and the first tier of sites surrounding it, then another tier of sites has to be radiating and taken into account to have a good statistical estimate of the interference. This situation is depicted on the right side of Figure 1. However, the cluster size comprises now 37 sites.

Internal



Figure 2 Clusters definition

Several conclusions can be drawn from these examples: The deployment has to be driven by clusters as opposed to individual sites. The cluster size is important from a radio perspective to have a good statistical knowledge of

interference in the core of the clusters. At the start of the optimisation process, it is very important to have all sites radiating. The stability

of the sites is very important and should be monitored before drive testing. The main focus of the drive testing should be on the core of the cluster: the drive test route has

to be as fine as possible in the middle of the cluster. The cluster buffer sites (outer tier) have an impact on the core of the cluster, however their

interference can only be estimated if the surrounding sites are radiating. When significant clusters adjacent to each other have been deployed then the inter-cluster has

enough tiers radiating around it to have stable interference estimation (white zones in Figure 2).

3.3.2. CLUSTER DEFINITION

Cluster size: Clusters should consist of between 20 and 40 sites. The actual number should be flexible to allow a faster roll-out and the constraints are country specific. Things to bear in mind:

The smaller the cluster the more inter-cluster borders exist: therefore the optimisation process is more complex at a deferred date.

The smaller the cluster the less effective the optimisation is: it is better to defer the optimisation process at a later date from a cost efficiency perspective.

The smaller the cluster the highest the importance of a buffer zone to radiate. The larger the cluster: the more stable the results.

Internal



The larger the cluster the more cost efficient is the optimisation process. The larger the cluster the more intensive is the drive test requirements. The larger the cluster the more RF changes impact is assessed properly. The larger the cluster the more effort on prioritisation of RF changes for each drives.

Unless a few changes requires the whole route to be driven again. However, it is possible to drive again only part of the larger cluster drive test route as long as the sites are all radiating.

Focus on integration and commissioning based on defined radio clusters: the temptation at a roll-out phase is great to define clusters based on available sites. However, if this definition is based on non-radio criteria it defeats the purpose of defining clusters to optimise a CDMA network. A good compromise should be found between availability of sites and cluster definition.

The local knowledge is very important to properly define the 3G optimisation clusters. The radio considerations to take into account when defining the clusters are the followings (ignoring any acquisition/ integration requirements). A site can only belong to one cluster for simplicity. The cluster boundary should be a polygon, ideally rectangular or hexagonal, to minimise

boundary areas with neighbouring clusters (exception of sites covering only roads or railways in a linear fashion).

Urban centres or areas of high traffic should where possible be near the centre of a cluster. Identified boomer or high sites in a key area should where possible be towards the centre of

the cluster, as these will have an impact on overall cluster performance. Cluster boundary checks

o No key road and rail routes at boundary due to the potentially large degree of re-work required after optimisation.

o Open areas such as water area, rivers or valleys where propagation would be enhanced cannot be considered in isolation and a cluster shall include the whole open area.

o Inter RNC boundaries should avoid being defined in a high traffic area as much as possible. RNC area should be at the centre of the high traffic area. Rivers in the middle of a big town should be treated very carefully to avoid having inter-RNC boundary following the river line as interactions would be high between the two RNCs, resulting in degraded performance.

At the border of two regional entities, the clusters should be defined regardless of ownership and then clusters redistributed among regional entities to keep the balance in the number of sites dealt by each regional entities.

The cluster size is similar in both the UK and France and comprises between 10 and 20 sites; the recommendation in the UK is 20 sites. The size of the cluster will be predominantly driven by the sites available and the size of the route to be driven.

3.3.3. CLUSTER AVAILABILITY A high number of radiating structures is required to have good statistical stability of the RF quality (even if the sites are not part of the cluster to be optimised sites surrounding the cluster should be radiating is possible). The thresholds are not sufficient to define a cluster ready for optimisation as other criteria need to be assessed. The current thresholds are:

Threshold for cluster Number of sites not

Internal



readiness available Recommendation 20 sites (typical)

80% 4

Table 1

Depending on the cluster size the same threshold can be too restrictive or too loose. The threshold is a good driver for acquisition, build and integration teams delivering clusters prior to optimisation. The trade-off between roll-out and extra optimisation cost should be assessed cluster by cluster. A Red/Amber/Green status per site can be used to assess the likelihood for a site to be ready in the short term. Obviously, these thresholds are not sufficient and other radio criteria are required such as: Shape of the cluster. Radio impact of the site on neighbouring sites:

o Position of missing site in the cluster. o Height of the site compared to the clutter. o Environment: DU, SU, RU, in car, Outdoor. o Terrain: boomer sites (high sites with enhanced propagation due to terrain or height

compared to the clutter surrounding the site).

3.3.4. SITE AUDIT The site audit should be as detailed as possible to help the optimisers working on the clusters to have a sanity check, track future changes (history) and keep knowledge within the company (even if the work is carried out by an external company or by team members who would change role in the organisation). One of the element that is very important to assess parameter changes such as tilt and azimuth are panoramic pictures of sites and site drawings, stored electronically on a central database. This way of working saves remarkable time at the optimisation phase.

Example of Detailed Site Audit: o Antenna structure:

Antenna Type Azimuth Mechanical Tilt Electrical Tilt Downtilt bracket Uptilt bracket Dual-band Multi-band MHA: antenna connection, bottom of mast, or BTS. Bias T Feeder Loss:

Audit of the feeder: o Minimal feeder loss achievable. o Cross-feeder and labelling checks.

From BTS to antenna, including all jumpers. Panoramic pictures with bearings.

o BSS Data Cell Id (hex) LAC (hex) RAC (hex) UARFCN (hex) Scrambling Code Position: Lat/Long

o Basic test:

Internal



EcIo (dB) No (dBm) MO, MT, MO-MT and Data call Check sectors, scrambling codes and cell Id to identify cross feeder issues.

o Neighbour list: this test consist in measuring in Line Of Sight potential neighbours on rooftop sites. A prepared list would be a requirement. Site ID, Cell Id, LAC, RAC, UARFCN, SC, Status (radiating only, audited, not

available).

3.3.5. SCRAMBLING CODE STRATEGY. The UK has adopted a now standard optimisation of the scrambling code strategy which compromises between battery life and speed of synchronisation. This strategy is a very good strategy which has also advantages from an operational perspective for field engineers. France has chosen a similar approach with a slight difference. The synchronisation is more complex than second generation CDMA systems such as IS95 with the advantage of being an asynchronous system (no GPS required at Node Bs). The synchronisation of a UE in UMTS is based on 4 stages: system synchronisation, slot synchronisation and frame synchronisation (code group synchronisation) and complete code identification. Each stage increases in complexity (higher battery requirement) but decreases in error probability (faster synchronisation at initial stages). There is 512 scrambling codes divided in 64 code groups, with 8 codes per code group. If the 512 scrambling codes are used randomly then each code has to be identified completely for each sector (high battery consumption and slow synchronisation). If scrambling codes of the same code groups are used, then the error probability is higher (faster synchronisation) but increases battery life. The way the scrambling codes are planned has an impact therefore on the synchronisation speed and battery life. A reasonable trade-off consists in allocating one code group per site and three codes of that code group for each sector (code 0, 1 and 2). This provides a 64 site reuse pattern for the scrambling code planning which should be enough. If problem arises in code allocation then the pattern can remain the same but choose instead the next three codes of the code group ( code 3, 4 and 5).

Figure 3: 64 code group pattern

Internal



Figure 4: switching lower and higher code within a code group

One of the biggest advantages of using the same code group per site is the operational ease of identifying sites by field engineers. When driving it is very easy to guess which site is detected at a given point (if 512 codes are used without planning code groups then only a map can help to identify sectors and sites). It is recommended to plan with 50 scrambling codes and keep 14 codes for infill sites. It defers the need for scrambling code planning when the sites are coming on air at a later stage (similar to a frequency planning exercise).

3.3.6. SITE DESIGN IMPACT ON PERFORMANCE Although, this section might seem obvious, it is very important that the basic RF site design is linked to the performance of the network. 3G technology imposes more stringent site design than GSM as it has a direct impact on network performance. None of the MCOs emphasized this message in the documents available. There is a high correlation between the basic RF parameters and WCDMA capacity/coverage. Best practices can include topics such as:

1 2 10

2 10

2 10

2 10

2 10

2 10

2 102 1

02 1

0

2 10

2 10

2 10

2 10

2 10

2 10

2 102 1

02 1

02 1

0

2 10

2 102 1

02

0

2 10

2 10

2 10

2 10

2 10

2 102 1

02 1

0

2 10

2 10

2 10

2 10

2 10

2 10

2 10

2 10

2 102 1

0

2 10

2 10

2 10

2 10

2 10

2 10

2 10

2 10

2 10

2 10 2 1

02 1

02 1

02 1

02 10

2 10

2 10

2 10

2 10

2 10

2 10

2 10

2 10

3 335 4

5 43

5 43

5 45 4

3

5 43

5 435 4

35 4

3

5 43

5 43

5 43

5 43

5 43

5 43

5 435 4

35 4

35 4

3

5 43

5 435 4

35

5 43

5 43

5 43

5 43

5 43

5 435 4

35 4

3

5 43

5 43

5 43

5 43

5 43

5 43

5 43

5 43

5 435 4

3

5 43

5 43

5 43

5 43

5 43

5 43

5 43

5 43

5 43

5 43 5 4

35 4

35 4

35 4

35 43

5 43

5 43

5 43

5 43

5 43

5 43

5 43

5 43

4

Internal



Optimal Feeder length: feeder length below 3dB total loss from BTS Top of the rack and antenna

is very important. The DL power available is important, the balance between UL and DL to be maintained (several parameters of the network are dependant on feeder loss).

Antenna height above the surrounding clutter to allow flexibility on tilts and good dominance. Antenna position on rooftops: avoid clipping, or blocking to control the RF footprint and allow

reorientation of the azimuth. Antenna type: dual-band, multi-band, VET antennas Tilt guidelines.

3.3.7. DRIVE TEST ROUTE DEFINITION The drive test route can be defined differently in different teams. The drive test route has mainly two purposes: Optimise coverage and interference using RF parameter such as: antenna type, tilt, and azimuth. Benchmark the system KPIs: call setup success rate, drop call rate, throughput, etc

However, the route required to optimise coverage and interference is a more intensive drive of all possible routes for each sector of a site (several radial roads at different distances and transversal roads to the sectors); as opposed to the system KPIs benchmarking route which can be a smaller subset of the previous route. The subset can make sure that the route goes at least once through the coverage of each sector, avoiding Line Of Sight roads. This latter route is sometimes called acceptance route if an external company is providing the optimisation services. The acceptance route should define 3G-2G routes to test the Handover success rate. This later point doesnt seem to be covered by the processes in the available documents. Once the detailed drive test route for RF KPI measurements has been defined, it is recommended that the drive test route remains unchanged so that the statistical evaluation remains unbiased. Therefore, every future drive test shall be exactly the same route.

Figure 5: Drive Test Route focus

As shown in Figure 5 the drive test route (blue lines crossing hexagons) should drive all possible routes (radial and away from the sites) to have a better statistical estimate of coverage and interference for each sector at different distances.

Internal



One typical mistake is to have very limited routes defined per sector which would not allow deciding on future tilts or azimuths changes to apply.

Another typical mistake is to try to drive test too much outside the core of the cluster, which covers a significantly bigger area. Therefore, it burns a lot of the drive test team time to cover areas which are in the buffer zone.

Defining a denser drive test route in the core (on a smaller area) significantly reduces drive test intensity and improves RF performance (RF changes implemented have more statistical stability).

At a second stage of optimisation for system KPI benchmarking a reduced set of routes should be taken into account, for example one that covers each sector of each site. Moreover, a few routes away from 3G coverage, should be chosen to benchmark 3G-2G handoff success rate.

3.3.8. ACCEPTANCE ROUTE DEFINITION A subset of the route required for RF optimisation is a very good trade-off to reduce the time required to optimise a cluster as explained in the previous paragraph. It is important to drive main routes and avoid as much as possible routes in Line Of Sight. Exclusion zones are typically zones where network vendor or optimisation service providers do not guarantee system performance because the coverage targets are not met. Exclusions zones should be agreed with optimisation service provider based on coverage thresholds in planning tool as opposed to measured levels. Obviously if the site design restricts propagation because of a non ideal design the third party company can not be held responsible for the poor performance due to that site.

3.3.9. PREPARATION WORK BEFORE A DRIVE TEST. There are a number of tasks that are very important to check before starting a drive test: Check Alarm status of sites. Check sectors off. Back-up network parameters (Tilts, azimuth) status on the day of drive test. Make sure no team is involved in RF parameters changes while drive testing.

3.3.10. RF CHAIN SETUP The difficulty from measurements comes from several limitations namely: Planning thresholds are based on Link Budgets with specific margins to take into account

Building Penetration Loss, Planning tool accuracy and QoS. Therefore, the link to live measurements can be aligned if the same assumptions are applied.

The measurements to be repeatable, meaning that driving twice on the same road would bring the same results, has to limit the variability of the conditions under which the testing is performed:

o Define a standard RF chain with nominal cable length (calibration to 0 dB of the antenna has the drawback to deform the antenna pattern and bias the measurements towards a given directions sometimes. It is not recommended to calibrate the antenna but to compensate in the measurements the system losses and system noise).

o Antenna placement on van rooftop: middle of the metallic rooftop (take into account roof opening windows if any).

o Verify RF cables and connectors before any drive (faulty connectors or wrong cable types is wasting a whole drive test worth of time and team resources).

Internal



o Use of a RF shielded box (Faraday cage) is a key component to limit variability due to the vehicle influence on losses.

The aim of the engineering team is not to reproduce a customer experience type of test but repeatable tests to detect impact of RF parameter changes such pas tilt, azimuth, antenna changes and so on.

3.3.10.1. Scanner measurements A standalone scanner can be in RF shielded box by design. If this is the case then the standard cables and connectors should guaranty the RF chain losses and performance. However, scanners have to be characterised to estimate Noise Figure and averaging methods impact when configured. If the mobile terminal is used in a scanner then to reduce variability of results requires an RF shielded box. For simultaneous 2G and 3G scanner measures, separate scanners are more likely to be used. The use of a splitter and dualband antenna might be required to be closer as much as possible to a mobile measurements (going through the same antenna and RF chain).

3.3.10.2. Mobile testing The use of an RF shielded box is highly recommended. It is possible as well to simulate different attenuations separately in UL and DL to either test within the Link Budget thresholds or simulate Indoor situations. It is very important to use this types of attenuations when defining the neighbours. Applying software attenuation is not necessarily the same when approaching the noise floor of the system.

Figure 6: RF Chain example with RF shielded box

UL and DL independent attenuator

Splitter

Splitter RF shielded Box

RF cable

Car Rooftop

Antenna

Common Attenuator

Internal



3.3.11. AERIAL PARAMETERS CHANGE CONTROL PROCESS Tracking the history of parameter changes is very important. It is a requirement to allow efficient optimisation by knowing the exact status of the parameter at any stage using tools (prediction and optimisation tools) and support future activities whether the first optimisation process has been performed by Orange or external companies. A very clear and flawless process is required between the different teams involved in parameter changes to ensure consistency of the data. Individual countries have probably a custom process for the 2G network and this process can be adapted to encompass 3G specific requirements, of which the rapid pace in parameter changes and the need to associate changes to specific drive tests.

3.3.12. INTER-CLUSTER OPTIMISATION The French process includes an inter-cluster optimisation within the process, as several clusters are optimised in parallel. This is a good approach allowing cost savings in the mid-term. This might be time consuming if the clusters are not ready at the same time from an acquisition, build and integration point of view. This step could be performed at a latter stage depending on optimisation strategy.

3.3.13. RF KPIS The KPIs are not aligned in the different countries as the link budgets are not yet aligned. RF KPIs include: Coverage KPIs: a distribution would be very useful. Interference KPIs:

o EcIo: a distribution of EcIo is very important o SHO zone: very difficult to measure this parameter.

Some additional or replacement parameters could be used: Active Set distribution (which is easier to estimate than SHO zone), UL Tx power, scrambling code reuse, Best server/Dominance measure. It is recommended that all RF Changes should be evaluated based on scanner measurements in conjunction with an extensive drive test route at the centre of the cluster and on sectors expected to propagate far away (terrain check, clutter check and panoramic pictures should be used to decide where to drive more extensively). It would be beneficial to have a more detailed KPI based on distributions of measured parameters. Test under load conditions can be a useful tool to push network vendor at acceptance stage to achieve the best system performance under agreed load conditions (as specified in the RFQs or SLA for optimisation services). Potential investigations are suggested in the following tables. Note that the levels remain to be discussed to take into account all networks and experiences. Note that some combinations are not duplicated in the table.

Low EcIo [ = 5%]

High Tx Power [ >= 18 dBm[

High RSSI [>=--98 dBm]

Low RSCP Lack of Lack of Lack of Coverage. if low EcIo then

Internal



[=-95 dBm]

Interference issue Neighbour list issue.

Interference issue Neighbour list issue.

MHA problem High external noise Correlate with call setup success rate.

If EcIo low then interference issue, if not then normal.

Low EcIo [ = 5%]

If EcIo low then interference Neighbour list issue.

High Tx Power [ >= 18 dBm[

MHA issues.

3.3.14. NETWORK PERFORMANCE KPIS The network KPIs should only be evaluated once basic parameters such as Coverage has been maximised, Missing neighbours activity complete. Currently, KPIs are also evaluated at the early stages but do not provide useful measure for future performance A process of root cause analysis should be triggered if the Drop Call rate is above a given threshold or if the dropped calls are mainly within a given geographical area. KPI Comment existing Drop call rate:

Voice CS64 (Video Call)

A specified number of calls by batches of 50 calls should be specified (specifically if the optimisation is provided by an external company)

Yes

DL throughput: 128 PS 384 PS

The process should clarify under which RRM parameter settings the benchmark are carried out.

Yes

UL throughput: 64 PS

Currently this measure is missing and can be useful to understand the user perception of the services in an upload situation.

No

Call set-up time: MO MT Video call

This measure can be useful only to detect abnormal conditions.

Yes

Call set up success rate: Voice Video

Blocking can be evaluated by counters from the network and this measure can become obsolete.

Yes

3G -2G HO success rate It is key for the customer perceived coverage that the neighbours for 3G-2G are accurately defined. Some vendor specific implementation are more sensitive to neighbour definitions and the performance can be greatly degraded.

Yes

Table 2

Internal



3.3.15. DOWNLINK LOAD It is possible to apply a uniform load in the Downlink to simulate load. From fields experience this load will shift the EcIo distributions as predicted by theory. It doesnt bring more information than available as it is possible to define EcIo thresholds mapped between unloaded distribution and loaded distribution. The geographical bins where the EcIo does not pass the threshold in unloaded condition is very likely to be the same than in the loaded case. The downlink load is very likely not uniform as a function of time, therefore the problem areas are likely to change and this information is not available from drive test data even with OCNS type of features. This uniform load has a big impact on the downlink availability probabilities and can only be predicted with the help of very fast Monte Carlo simulations. The only advantage to use the DL load is when benchmarking system KPIs which have been set contractually with the network vendors or optimisation service providers.

3.3.16. EXIT/ACCEPTANCE REPORT SPECIFICATION A single format either for exit reports from teams or external companies is a very powerful tool to review performance across the different regions and countries. The plots definition and requirements would be very important too.

3.3.17. DRIVE TEST METHODS Orange France uses a calibration of the antenna system of the VAN to 0dB and test with Indoor Daylight attenuation chain to simulate UL load and Building Penetration loss. This provides an excellent measurement of the network and provides a very reliable measurement as it avoids unpredictable fluctuations due to the handset position in the car. Antenna system calibration sometimes biases the pattern of the antenna towards a given direction and might not be the best approach. Moreover, it adds delay to the process if calibration has to be done regularly. A software adjustment of the RF chain can be more convenient from an operational perspective. A standardised approach to RF chain design and testing should be specified to ensure that measurements are comparable and can be reproduced.

3.3.18. TOOLS GUIDELINES Alignment of tools and tools usage would provide a remarkable tool to share experience between the different MCOs. However, this alignment can be specified as stability and functions of the tools are at a mature stage.

3.3.19. OPTIMISATION TIME SCALES AND RESOURCES No time scales was available in the documents provided by the UK. The time scales as defined in Orange France documentation were as follows:

Figure 7

Internal



The cluster optimisation phase is based on 5 drive tests (red in Figure 7) and the network optimisation phase on a total of 9 drive tests (green in Figure 7). A best case scenario of 11 weeks is a very long process to deliver a cluster. From a roll-out strategy perspective, reducing the number of week to around 6 weeks would be feasible if the tests were prioritised and no network performance KPI was measured at the initial phase. A good trade-off is to split the optimisation process as proposed in the current document in two phases whereby the pre-launch phase includes all the major activities to maximise system coverage and performance ( Neighbour list definitions 3G-3G and 3G-2G) and a post launch phase for the remaining fine tuning tests. Rolling out the pre-launch phase would allow a faster roll-out with a good system performance.

Total number of years to optimise vs Optimisation Process time

Assumptions: 20 sites/cluster, 10 optimisation teams

0.0

1.0

2.0

3.0

4.0

5.0

6.0

4 weeks 6 weeks 8 weeks 10 weeks 12 weeksNumber of weeks a process takes

Num

ber o

f yea

rs 1000200030004000

Figure 8

Figure 8 shows the obvious relationship between time scales for optimisation, resources, number of sites deployed and time to market. The time scales have a significant impact on time to market. This is an opportunity for operational teams to find the best trade-off between network performance and commercial launch date. Overall the optimisation was performed with between 5 to 7 drives (in addition to site verification in one MCO). The objective should be to reduce substantially the number of drive test required to around 5 in total (for all phases). From MCOs experience the general time scales for a town with 350 to 400 sites was 4 month of optimisation (not taking into account the KPIs achieved).

3.3.20. PROBLEM AREAS IDENTIFICATION AND SOLUTIONS At the exit report for optimised clusters a number of problem areas should have been identified. These problem areas can be classified in 3 categories: Orange shops/corporate customers requiring good in-building coverage. Poor coverage areas not possible to solve at optimisation stage. Poor interference areas not possible to solve at optimisation stage.

Internal



These problem areas might require specific solutions such as: indoor solutions, new site, new antenna type, new physical change to the antenna structure (changing position of the antenna structure on a rooftop).

3.3.21. SINGLE FREQUENCY DEPLOYMENT Orange France has taken the approach of using the second frequency when deploying new clusters or infill sites. However, this approach has different drawbacks and advantages which are discussed.

3.3.21.1. Second frequency usage

The current approach has been to use the second frequency when integrating new clusters and infill sites..

3.3.21.1.1 Advantages

Existing radiating sites have independent performance from new radiating sites. Basic RF test can be carried out without impacting the rest of the network performance. Infill sites can be analysed before coming on air.

3.3.21.1.2 Disadvantages

A UE travelling through coverage hole where the second frequency is available might drop the

call and start scanning the band. The result is a long scanning with eventually a reselection process which has an impact on users perception. There is currently no hard handover between the 2 frequencies.

Scanner collection for 2 frequencies is not always possible depending on scanner used. In addition no interference analysis is possible.

The RF checks with second frequency usage are very basic and do not guarantee any better performance when switched to the first frequency (neighbour analysis can not use best server analysis easily to define borders or take into account zones with poor dominance to a more careful neighbour plan).

In general the optimisation process is longer when using the 2nd carrier for initial deployment. Additional time is required to verify performance after switching to the 1st carrier.

Sourrounding sites which require tilt changes to accommodate a new in-fill site will suffer a loss of performance while the in-fill site radiates on the 2nd carrier.

Data-build issues might arise when switching frequency. For example when the frequency has to be changed in Nokia equipment, the cell has to be deleted and then re-build, it increases the risk of incorrect data fill after that site is unlocked.

3.3.21.2. Single frequency usage The single frequency usage is nearly the reverse advantages and disadvantages compared to the second frequency usage .

3.3.21.2.1 Advantages

No UE performance issues due to the mobile selecting cells on a different carrier after a drop. Scanner collection is much easier and allows EcIo analysis.

Internal



EcIo and neighbour plan issues can be identified and addressed straight away. Better information is available after tilting sites after the first drive test. The interaction with nearby

sites can be better understood when all sites are on the same frequency which in turn leads to a faster and more efficient optimisation cycle.

The processes are more simple and dont involve creating two separate Network Definition Plans.

Existing traffic will be less impacted due to unpredictable UE behaviour. Processes remain the same when second frequency is deployed.

3.3.21.2.2 Disadvantages

Sub optimal interference situations can be encountered by the mobile in some geographical

areas. No RF check before bringing the site on air.

Recommendation: In both scenarios there is a possibility of sub optimal performance. However, the UE behaviour, scanner issues and, faster and less complicated optimisation, favours the use of a single frequency. This approach is being used in many networks without any issues. Considerations to take into when implementing one approach or the other: One key activity is to monitor the network counters on the surrounding clusters when a cluster is

switched to the first frequency to check impact and degradation on existing and available clusters for immediate action.

Cross feeder issues is the main reason for the second frequency usage. A good process for cross-feeder checks should minimise risks and the use of the second frequency is not justified anymore.

Dealing with issues when the site uses a single frequency deployment is a good driver for the different teams involved and avoid increasing the time scales for optimisation.

One proposal was to lock the site but use the radiation feature (to be checked). In many cases the removal of the access restrictions should be decided in conjunction with

marketing on a town per town basis for launch.

3.3.22. CLASS 11 AND OPERATOR USE ONLY PROCESS Class 11 and Operator use only status has an impact on customer handsets with non-class 11 SIMs: some handsets ping-pong every seconds between the 3g and 2G layer which has an impact on user perception of coverage and drains the battery life. Most handsets seem to behave correctly when a call attempt is made and use the 2G layer to provide the voice service. For Packet Switched connections this behaviour has a huge impact on the service. A clear strategy is required for in-fill and new clusters coming on air close to existing clusters. The recommendation is the same than in the single frequency case; these features should be avoided as much as possible in the network or removed very early in the process. These crucial points require discussion with teams in the different MCOs.

3.3.23. INFILL SITE OPTIMISATION PROCESS Sites not ready when optimisation process ended or new sites coming on air on commercially launched areas, require a different optimisation process. Particularly the class 11 barring and operator use only restriction should be removed to limit impact on existing customers. A suboptimal performance might impact the cluster until the first drive test and changes are implemented. The most critical part is that the new site neighbour list and neighbours interactions defined prior to bring the sites on air.

Internal



3.3.24. COMMON VOCABULARY A best Practice optimisation process would benefit if the vocabulary is aligned, allowing an easier communication across the different companies. For example using at least the same titles for the each major milestone in the optimisation process would help reading the different exit report. To give a more specific example, if the process is divided in 4 milestones: Site validation, Cluster Optimisation, inter-Cluster Optimisation, End To End testing. The naming convention can be proposed by any team or any person, the important factor is to improve communication between the different teams.

3.4. COVERAGE TARGETS

The link budgets are based on the 64 CS in the UL which is expected to be the limiting link for a low load network (coverage limited link because of the limited mobile power). However, the link budgets are not aligned. The following two tables are based on UK and France coverage tables. They might not be representative of the actual targets. Clarification on thresholds used for planning (prediction tools) and drive testing (coverage optimisation) would help. Note: that this section needs to be updated as teams in the UK and France are currently trying to align most of the link budget parameters.

3.5. NEIGHBOUR DEFINITION

3.5.1. 3G 3G NEIGHBOUR IDENTIFICATION PROCESS It is one of the most important task to execute in optimisation and probably the most rewarding

task in terms of performance improvement. The main test service should be voice and driven by Drop Call rate, Call Success rate. Note that

long calls should be made on the first drive for neighbours definition and short calls on subsequent drives for statistics.

The neighbour list should be neighbour list with a ranking from most important neighbour to least important.

The neighbour list should include by default same site cells by as the most important neighbours to be defined.

No site should come on air without a neighbour list that has been checked at least once. Planning tool based neighbours: the planning tool based neighbour list generation accuracy is

probably very coarse. It can only be used as one input as a first step. Most of the time an experienced optimiser will outperform the tool by manually planning the neighbour list.

Several strategies are possible to define the list, however, it is very important to come up with a ranking system that is verified in the field:

o Distance based ranking. o Radio propagation matrix: For example, every site detected in every bin of a best server

area should be ranked in terms of percentage of occurrences in the best server area to rank the sites. Other methods can include a filtering based on power window of 10 dB for example.

o Scanner Drive testing results: a higher window or an attenuation chain should be used to take into account indoor scenarios.

Reciprocity: Site A which has in its neighbour list Site B defined as a neighbour, should be defined as a neighbour in Site B neighbour list.

Used the 2G -2G HO flow to define the 3G-2G and 3G-3G relationships specially if collocated. This is heavily based on a manual process and drive test results to identify missing neighbours. One manufacturer for the current software release has a limitation to 16 neighbours. This limitation should be applied only at the end of the list generation for several reasons: the limitation can change at different

Internal



software releases, help to detect problem site when analysing drive test results, and provide a history of optimisation work.

3.5.2. 3G 2G NEIGHBOUR IDENTIFICATION PROCESS Depending on the countrys 2G deployment strategy several bands might have been deployed: 900, DCS 1800, EGSM. Because of the limitation on the number of neighbours, only the layer that propagates best should be chosen to provide a fallback option to the 3G users moving out of coverage (indoor situation as well as on the fringe of 3G coverage). Several considerations when defining the 3G-2G neighbours: Define only GSM 900 neighbours ( if GSM 900 is the continuous layer) if several layer are

deployed (900, 1800, EGSM).. Always define co-sited GSM sites in the neighbour list. A 2G scanner should be used in conjunction with a 3G scanner (with GPS) to define a precise

list. Used the 2G -2G HO flow to define the 3G-2G and 3G-3G relationships specially if collocated. A reciprocal list should be defined on the 2G network to improve reselection to the 3G layer.

The UE shall not be locked to 3G to be able to see places with poor 3G dominance and a biased 3G coverage perception.

3.6. 3G 2G INTERACTIONS PERFORMANCE

A benchmark on performance for 3G 2G voice HO performance and 3G 2G PS reselection performances to be completed when agreed with the MCOs.

Internal



3.7. RF OPTIMISATION AND SYSTEM PERFORMANCE KPIS

These sections should be discussed with MCOs to agree on both best parameters to measure and what thresholds to specify in the requirements that are currently achievable. The following tables are a proposal to initiate the discussions with the different MCOs.

Optimisation Activities: Commercial Availability Activit Tools Tasks Connection type Connection frequency Typical duration

1er Drive 3G Scanner

UE

Detailed drive test route scanning an calls : - assess coverage - 3G neighbours

Scanner UE Long calls to identify neighbours

Continuous scan Calls until it drops.

2nd drive 3G and 2G

Scanner UE

Detailed drive test route scanning an calls : - assess coverage - 3G neighbours - 3G 2G neighbours

Scanner UE Short calls MO: 2mins long UE Short calls MT: 2mins long UE calls until 2G HO triggered

Continuous scan 50 calls 50 calls 10 calls per route for all main routes driving out of coverage The UE shall not be locked to 3G to be able to see places with poor 3G dominance and a biased 3G coverage perception.

3rd drive 3G and 2G

Scanner UE


Scanner UE Short calls MO: 2mins long UE Short calls MT: 2mins long UE calls until 2G HO triggered

Continuous scan 50 calls 50 calls 10 calls per route for all main routes driving out of coverage The UE shall not be locked to 3G to be able to see places with poor 3G dominance and a biased 3G coverage perception.

1 day/drive

Target KPI Nortel Nokia Alcatel Condition

EcIo

EcIo> -10dB (unloaded) A scanner based measurement in parallel could confirm Pilot Pollution or poor EcIo zones where tilts might be required. This approach is to solve problem areas rather than an effort to improve the EcIo distribution (which should be the aim of the ongoing optimisation activity).

RSCP>+-100 dBm

Call Setup success rate 98% With and without filtering the causes for drops or set-up failures.

Call drop rate 2% With and without filtering the causes for drops or set-up failures.

Call succes rate MO :

96%

With and without filtering the causes for drops or set-up failures.

Call succes rate MT: 96%

With and without filtering the causes for drops or set-up failures.

PR

E-

LAU

NC

H

3G -2G HO success rate 97%

Internal



DL PS 128 or PS 384

DL 110 kbps average throughput/ 90% of peak throughput DL 345 kbps average throughput/ 90% of peak throughput UL 57 kbps average throughput/ 90% of peak throughput Analysing throughput calculations is very difficult and time consuming because of the Cell-DCH, Cell FACH states and vendor specific implementations. PS384 would be important for MCOs with a 384kbps marketing requirements. The site density and parameter settings will have an impact on the reconfigurations from 384 to 128 which might not reflect the optimisation status. PS128 might be a fairer way to compare the networks across MCOs to estimate the optimisation progress. However, you would loose visibility on the customer experience.

These statistics represent statistics after removing/filtering calls which had a failure not related to the radio optimisation such as Core Network issues, Handset issues or exclusion zones (missing site). The reporting should report both the values before and after filtering based on the root-cause analysis of the call drops.

Table 3: PRE-LAUNCH activities.

Internal



Optimisation Activities: Performance improvements Activit Tools Tasks Connection type Connection

frequency Typical duration

1er Drive 3G and 2G

Scanner 2 UEs

Detailed drive test route scanning an calls : - assess coverage - 3G neighbours - 3G 2G neighbours PS performance on Acceptance Route. 3G-2G PS HO

Scanner UE 64 CS Short calls MO: 2mins long UE 64 CS Long calls UE PS UL 64 FTP transfers UE PS DL 128 FTP transfers

Continuous scan 50 calls FTP continuously on acceptance route

2nd drive

3G and 2G Scanner

2 UEs


Scanner UE 64 CS Short calls MO: 2mins long UE 64 CS Long calls UE PS UL 64 FTP transfers UE PS DL 128 FTP transfers

Continuous scan FTP continuously on acceptance route

1 day/drive

Target KPI Nortel Nokia Alcatel Condition

EcIo EcIo> -10 dB (unloaded) RSCP>+-100 dBm

Active Set AS +-100 dBm

Call succes rate MT:

96%

3G -2G PS HO success rate

97%

CS64/Visio success rate 95%

DL 128 Throughput 110 kbps average throughput/ 90% of peak throughput Based on FTP transfer time 4Mbytes DL and 1Mbytes UL

UL 64 Throughput 57 kbps average throughput/ 90% of peak throughput Based on FTP transfer time 4Mbytes DL and 1Mbytes UL

PS 128 DL BLER

Internal



4. GAP ANALYSIS

A high level view has been presented in previous paragraphs, in the following section only the gap is presented whether in one or more MCOs.

A roll-out strategy is required: commercial readiness can be defined very differently depending on company strategy. If coverage is considered as a compelling offer from a commercial perspective a different optimisation process can be defined to perform the optimisation in two stages.

o Vodafone in the UK has a high priority on Coverage and would bring sites on air to provide coverage even if the network is not optimised. The risk is user complaints possible in non optimised area but they see this as a competitive advantage in terms of commercial offer to show that the 3G coverage is very good.

o Orange France seem to release only cluster after E2E testing, which might be extreme in terms of time scales to deliver coverage for commercial use, but guarantees the best quality achievable for the user.

o It is possible to get the best of both approach by creating an optimisation process that is targeted to roll-out followed by an on going performance improvements. However, this implies a very different logistics in terms of resources. The High Level Document 3G Network launch requirements specifies only that the coverage requirements are MCO dependent and KPIs to be met. However, the access barring can be removed earlier in the process to provide best effort service. Coordination should be used between coverage information released to the

public and customer complaint handling department to identify areas with best effort service.

This approach can only pay off if the second stage of optimisation is performed after all areas have been through the first stage of optimisation. This could significantly increase the coverage availability by reducing the time to market by around an estimated 30 to 40 % reduction in time for the whole program.

If the second stage follows the first stage then only an estimated one month can be gained. Although this doesnt seem much it can be critical in countries with tight schedule to provide coverage for Christmas period for example.

Competitor benchmarking: o Coverage availability per town: scanner data should provide a mean to know the number

of sites (scrambling codes) available and coverage achieved. o RF quality. o Service performance: throughput.

Establish priorities in Optimisation process to perform important tasks first and avoid measuring KPIs when not necessary: for example, the neighbour list definition should be validated before Performance KPIs are started.

No clear focus on 3G 2G process at early stages of the optimisation process. A detailed Site Audit can save a lot of time at a later stage when the faults are captured earlier in

the process. The drive test time is not wasted to capture faults which would not require as much analysis from drive test analysis.

No UL throughput testing is specified in the End to End testing, however UL stability is not guaranteed. Those measurements as the traffic grows will most probably move to network based KPIs.

Inter RNC boundary test are important to understand impact of RNC parenting and changes required in high traffic areas or key roads.

In-fill site optimisation process is a process that needs to be specified to minimise impact on existing network and improve coverage availability as soon as possible. The documentation on those aspects are currently in progress in at least one MCO.

Class 11 and Operator use only status has an impact on customer handsets with non-class 11 SIMs: some handsets ping-pong every seconds between the 3g and 2G layer which has an impact on user perception of coverage and drains the battery life. Most handsets seem to behave correctly when a call attempt is made and use the 2G layer to provide the voice service.

Internal



For Packet Switched connections this behaviour has a huge impact on the service. A clear strategy is required for in-fill and new clusters coming on air close to existing clusters.

At the moment no cross border optimisation is specified: when Orange countries are adjacent and coverage can be sustained and coordinated.

Tools alignment for benchmarking KPIs allows to make the most of optimisation techniques and provide similar customer experience regardless of country.

Network performance counters alignment cross countries and cross network vendors: high level counters for the same vendor should be aligned and similar counter defined to compare vendors.

Internal



5. CONCLUSIONS

This document provides the baseline of a generic optimisation process that can be used by the MCos. Contributions from the different MCOs experience are very important to make sure that the designed process is the best in class in the industry. These processes in turn would provide a leading edge to the commercial offers and a similar high standard customer experience across the different countries. To achieve these goals a two phase optimisation is proposed whereby coverage is the main focus of the first phase including 3G to 2G handover performance. A second phase which can be completed after the coverage availability to the customer can drive the performance on a higher standard by tuning the different parameters. By consistently reporting RF and network KPIs for all MCOs (by aligning tools, measurements, and methods) the optimisation processes will provide similar customer experience across the different countries.

6. DOCUMENT HISTORY

Version Author Modifications/Comments 0.1 Yann Farmine Structure first draft 0.2 Yann Farmine Completed detailed analysis. 0.3 Yann Farmine Completed KPIs sections 1.0 Yann Farmine Details on scrambling code strategy, cluster definitions and

rearranged sections. 1.1 Yann Farmine Details on Neighbours and optimization tasks added. 1.2 Martin Bluer

David Cole Olivier Fabre Yann.Farmine Maylis Figer Ivan Froger Glyn Roylance Sandrine Sourp Alain Wyns

A workshop was organised by RSQ to finalise recommendations for a best practice optimisation process. The teams involved represented central and regional teams from France and UK. Each party provided argumentation and shared their experiences on the trade-offs and general consensus was found on some subjects, leaving some of the subjects for the MCOs to decide. The Participants are in the Authors list.

1.3 Alain Wyns Corrections and deleted sections compared to v1.2

7. REFERENCES

Document Author Date Version Procdure dOptimisation dun rseau UMTS: Optimisation Cluster et Rseau DRA/CPR/SO/04.120

S. Ortega, L. Ecale, S. Plantier, J.M. Batcave

20/04/2004 V1.3

3G Network Launch Requirements UTRAN GT/NAD/RSQ/RAT/2004-0007

D. Smith 20/12/2004 V1.0

WCDMA Radio Network Optimisation Guidelines November 2004

R. Joyce, B. Graves, I. Horne

02/11/2004 V1.0

3G Drive Survey KPI Definitions & Targets R. Joyce, I. Horne 01/11/2004 V1.3 NATSUIT User Guide For 3G Drive Survey Analysis, 3G Scanner and NEMO 3G UE

I. Horne, R. Joyce, Tristan Lee

05/03/2004 V2.0

Planification de codes UMTS

Philippe Manzano 01/10/2003 V1.0

Internal



Affectation des frquencies de travail sur les sites UMTS

QOP3G, JM Batcave 19/12/2003 V1.4

Procdures dOptimisation des sites Tardifs en UMTS

S. Ortega, L. Ecale, S. Plantier, J.M. Batcave, M. Figer, I. Froger

24/11/2004 V3.0

Procdure de vrification de site couverture Macro Outdoor

Malis de Jouvencel, MJ, LE, JMB, SKW, SO

10/04/2004 V1.0

Processus dOptimisation Radio 3G par Plaque Laurent ECALE

17/05/2004 V2.0

3g radio network optimisation best practices

Documents