UTRAN Optimisation Process v01%2E01

38
UTRAN Optimisation Process Document number: UMT/IRC/APP/019972 Document issue: 01.01 / EN Document status: Draft Date: 18/Jul/2006 Confidential document - Not to be circulated outside Nortel Copyright © 2004 Nortel Networks, All Rights Reserved Printed in France NORTEL CONFIDENTIAL The information contained in this document is the property of Nortel Networks. Except as specifically authorized in writing by Nortel Networks, the holder of this document shall keep the information contained herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties and use same for evaluation, operation and maintenance purposes only. The content of this document is provided for information purposes only and is subject to modification. It does not constitute any representation or warranty from Nortel Networks as to the content or accuracy of the information contained herein, including but not limited to the suitability and performances of the product or its intended application. This is the Way. This is Nortel, Nortel, the Nortel logo, and the Globemark are trademarks of Nortel Networks. All other trademarks are the property of their owners.

Transcript of UTRAN Optimisation Process v01%2E01

Page 1: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Document number: UMT/IRC/APP/019972 Document issue: 01.01 / EN Document status: Draft Date: 18/Jul/2006

Confidential document - Not to be circulated outside Nortel

Copyright© 2004 Nortel Networks, All Rights Reserved

Printed in France

NORTEL CONFIDENTIAL

The information contained in this document is the property of Nortel Networks. Except as specifically authorized in writing by Nortel Networks, the holder of this document shall keep the information contained herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties and use same for evaluation, operation and maintenance purposes only.

The content of this document is provided for information purposes only and is subject to modification. It does not constitute any representation or warranty from Nortel Networks as to the content or accuracy of the information contained herein, including but not limited to the suitability and performances of the product or its intended application.

This is the Way. This is Nortel, Nortel, the Nortel logo, and the Globemark are trademarks of Nortel Networks. All other trademarks are the property of their owners.

Page 2: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 2/38

PUBLICATION HISTORY

18/JUL/2006

Issue 01.01 / EN, Draft

Creation

Page 3: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 3/38

CONTENTS 1. INTRODUCTION .........................................................................................................................4

1.1. OBJECT.................................................................................................................................4 1.2. SCOPE OF THIS DOCUMENT .....................................................................................................4 1.3. AUDIENCE FOR THIS DOCUMENT ..............................................................................................4

2. RELATED DOCUMENTS............................................................................................................4 2.1. APPLICABLE DOCUMENTS........................................................................................................4 2.2. REFERENCE DOCUMENTS........................................................................................................4

3. INTRODUCTION TO THE 3G OPTIMISATION SERVICE ..........................................................5 3.1. ROLL OUT SCENARIOS............................................................................................................6 3.2. SERVICE DELIVERABLES .........................................................................................................7

4. OPTIMISATION PROCESS OVERVIEW ....................................................................................8

5. PROJECT PREPARATION.......................................................................................................11 5.1. RF DESIGN AUDIT WORKSHOPS AND STUDIES.........................................................................11 5.2. FEATURES AND PARAMETER ALIGNMENT WORKSHOPS ...........................................................15 5.3. MONITORING WORKSHOPS ...................................................................................................15 5.4. PROJECT PROCESSES ..........................................................................................................16 5.5. PROJECT DATABASE ............................................................................................................18 5.6. MEASUREMENT AND ACCEPTANCE PROCESS .........................................................................18

5.6.1 Deviations and Exclusions ..........................................................................................21 5.7. PROJECT PLAN.....................................................................................................................22

6. 3G INITIAL OPTIMISATION PROCESS ...................................................................................23 6.1. SITE SHAKEDOWN ................................................................................................................24 6.2. CLUSTER OPTIMISATION .......................................................................................................25 6.3. NETWORK OPTIMISATION ......................................................................................................29 6.4. FINAL PERFORMANCE ACCEPTANCE ......................................................................................30

7. NETWORK EXTENSION OPTIMISATION................................................................................31

8. NETWORK DENSIFICATION OPTIMISATION.........................................................................32

9. OPTIMISATION RESOURCES .................................................................................................33 9.1. TOOLS.................................................................................................................................33 9.2. TEAM SKILLS .......................................................................................................................34 9.3. TEAM ORGANISATION ...........................................................................................................35

Page 4: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 4/38

1. INTRODUCTION

1.1. OBJECT

This document describes the procedures that are recommended to follow during the optimisation of a rolled-out UMTS network.

The RF Optimisation Service is described from an operational point of view giving extensive hints on the project management main challenges.

The contents of this document is derived from the experience of Nortel’s Core and Regional Engineering teams in large optimisation projects in EMEA.

1.2. SCOPE OF THIS DOCUMENT

The document contains information on the project level procedures, typical project and organisational issues and provides advice on topics to consider during the creation of the service offer and contract negotiation.

This document does not intend to describe the technical decisions in terms of parameter tuning or antenna tilting that follow particular performance issues.

1.3. AUDIENCE FOR THIS DOCUMENT

Project and Account Teams.

Optimisation and Engineering Teams.

2. RELATED DOCUMENTS

2.1. APPLICABLE DOCUMENTS

[A1] UMT/IRC/APP/019970 UTRAN Optimisation Process for Swapped Networks

[A2] UMT/IRC/APP/019971 UTRAN Optimisation Process when Introducing HSDPA

[A3] UMT/IRC/APP/XXXXX Indoor Optimisation and Acceptance Guidelines

2.2. REFERENCE DOCUMENTS

[R1] UMT/IRC/DD/0011 UTRAN Parameters User Guide

Page 5: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 5/38

3. INTRODUCTION TO THE 3G OPTIMISATION SERVICE

The main focus of the 3G optimisation is the assurance of an adequate RF layer (maximise coverage, minimise interference) in order to be sure that the 3G services will be granted with the maximum quality at the maximum number of users (capacity). RF control is the foundation of a good 3G network.

The optimisation service is usually contractually required to achieve a set of performance related targets at network level. It is a results-oriented service. The services to test and their performance targets are negotiated between Nortel and the customer before the signature of the contract.

The number of test protocols and services to report may be different depending on the verifications needed before a commercial launch and/or on the level of optimisation detail that the operator wants to achieve (fine tuning of complex features).

The goodness of a radio optimisation work can be demonstrated with a reduced set of reported KPIs1. If the RF layer is of good quality, the 3G product performance should be close to the standards observed during the product qualification phase. An optimised RF layer will permit an homogeneous performance in all the network of the user services (cf. chapter “ 5.6 Measurement and Acceptance Process” for more details).

It is recommended to deactivate features that can impact the collection of performance data (IRM scheduling, traffic segmentation…) specially at the first stages of the optimisation project.

The fine tuning of the complex features can be therefore done in just few clusters (Golden Cluster) or following the indications of Nortel Engineering teams (the main parameter setting recommendations are gathered in [R1]).

The feature parameter tuning and the End to End performance tests are stages of the optimisation process that help in improving the quality of service of the 3G network.

In any case, coherence has to exist between the contractual requirements in terms of optimisation and what is possible to achieve in a dynamic environment as WCDMA. The work involved and the test conditions that need to be guaranteed have to be well understood during the definition of the scope, budget and schedule of the optimisation project.

The optimisation service involves: Drive Test teams, RF tuning teams, Datafill and Network design teams, O&M teams, Cell Planners, RF Design experts, End-to-End experts, Optimisation experts, Core Network teams, Tools’ suppliers, Project Managers… The precedent teams can be composed, depending of the degree of outsourcing applied to the project, by Nortel employees, Operator employees or Third Party employees (sub-contractors).

1 This point is important as the cost and duration of the optimisation activity depends on the number of verifications to be made. For example, the higher the number of services to tests, the higher the number of drive tests to be done.

Page 6: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 6/38

The success of an efficient optimisation process relies on a strong mutual cooperation between multiple parties, ruled by comprehensive SLA (Service Level Agreement). Amongst all of them, the key ones we can list are:

• As a preliminary step as well as to ensure a proper continuity between the RF Design done by the operator and the optimisation done by Nortel, it is fundamental to have an extensive exchange of information on the different hypothesis and objectives during what we call the Preliminary RF Design Review. This is required as the optimisation contract usually includes performance targets to achieve with penalties associated.

• Homogeneous delivery of sites within a cluster (standard is that 90% of sites have to be integrated before the optimisation starts). All the sites using WCDMA technology share the same frequency. It is not possible to assess realistically the levels of interference and coverage in a cluster if there are missing sites (delayed sites).

• Fast implementation of antenna changes (even more critical when RETA system is not available), typically within 2-3 working days.

• Fast implementation of parameter changes (neighbours …), typically within the day which implies having a specific resource integrated within the optimisation team.

3.1. ROLL OUT SCENARIOS

The 3G Initial Optimisation (optimisation of new sites) can happen in different scenarios :

• Greenfield Network: isolated areas not currently opened to customers. For example: cities where currently there is no 3G service available and where the operator is investing to increase its customer base, or countries/regions where the 3G network is deployed from scratch.

• Network Extension: the continuity of the 3G service is being extended from an area where there are already 3G users to a “non-3G” zone (currently without 3G coverage). For example: the 3G coverage of a “UMTS” city is extended to its outskirts, or the elimination of the initial gaps of coverage left during the initial roll out and launch of the network (areas between two cities).

• Network Densification: isolated sites are being deployed in areas where the 3G service is available. For example: due to the 3G traffic increase or the introduction of new services (HSDPA) new sites are being deployed to offer the requested capacity.

Network Extension and Network Densification optimisation scenarios can be considered as special cases of a generic Greenfield Network optimisation process. This document will illustrate the latest and will specify the Extension and Densification process particularities wherever required.

Page 7: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 7/38

In the Greenfield and Network Extension scenarios, the areas where the roll-out and optimisation teams are operating have not been opened before to the 3G service (because of the operator’s deployment priorities, new contract…). This means that while those operations are taking place, no subscriber is impacted. This allows some liberty in the way the optimisation is organised (set of priorities, interaction with the operator…) and defines the way the performance indicators are obtained (there is no traffic so counters cannot be used, the radio load is fully controlled by the optimisation teams by OCNS or test mobiles…). The process associated are therefore quite similar. The only difference is that, in the case of a Network Extension, special care has to be put in the operations management around the boundary between an “3G-opened-area” and a “Greenfield-area” as the user performance can be impacted. We consider that in the Greenfield scenario there is no interaction with areas where 3G service is already available (isolated areas).

During the Network Densification, the operations can highly impact the service perception of the current users. The densification consists in adding new sites in an already optimised area where 3G traffic exists2. The optimisation is more delicate and much more care must be brought in the operations management (organisation, issues, alarms, speed in the performance tuning…). Moreover, tests with simulated load (OCNS) are not recommended.

Other optimisation scenarios are possible in a 3G live network. Although the optimisation process for those scenarios are quite similar to the one described in this document (cf. chapter Optimisation Process Overview), a deeper insight can be found in:

• Optimisation following the swap of another supplier: cf. [A1]

• Optimisation following the introduction of HSDPA: cf. [A2]

• Optimisation of Indoor Sites: cf. [A3]

3.2. SERVICE DELIVERABLES

Nortel can propose two options for the RF Optimisation of UMTS networks with two different sets of protocol tests and associated KPIs:

• Optimisation Level 1:

o RF Optimisation report

o Three protocol tests with 6 KPIs : minimise tests & speedup network rollout.

• Optimisation level 2:

o RF Optimisation report

o Seven protocol tests with 15 KPIs : strategic areas or important cities.

2 In the Network Extension scenario, the sites were being added in an area where there is no traffic (coverage).

Page 8: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 8/38

The optimisation and acceptance procedures can also include tests under simulated-load conditions (except in Network Densification scenarios).

The following table describes a typical set of KPIs that the optimisation teams have to measure and optimise. This list does not intend to be exhaustive and can be different depending on the customer requirements as said previously in this chapter (page 5).

Optimisation deliverables Optimisation

Report RF Optimisation report with Drive test coverage maps including Radio quality measurements Ec/Io & RSCP

Quality of Services - KPIs Test area PROTOCOL TEST KPIs Associated

success rate Retainability CS long call voice BLER DL & UL

Accessibility CS/PS short call success rate success rate CS HHO O

ptim

isat

ion

Leve

l 1

Mobility HHO 3G-2G success rate PS HHO

success rate

Service video call CSD (video call)

BLER DL & UL success rate

Service PS UL PS 128 or 384 UL Throughput

success rate

Service PS DL PS 384 DL Throughput

Throughput - function of CQI

Opt

imis

atio

n Le

vel 2

Service HSDPA HSDPA DL success rate

4. OPTIMISATION PROCESS OVERVIEW

The 3G Initial Optimisation process consists in a series of phased activities. The delivery of these activities are organised around several steps, which are summarised in this chapter.

In addition to the following phases, it is recommended to have the possibility of performing specific testing and parameter tuning of complex features in a representative cluster of the network: Golden Cluster. The main optimisation activity (RF control) will be performed in all the clusters but the parameter fine tuning of some features and other customer oriented tests should be done in a specific cluster in order not to delay the main RF optimisation objectives.

Nortel’s experience shows that networks which RF design has been thoughtfully done considering the right assumptions and with a pre-optimisation phase (simulated results of live conditions) need shorter periods of optimisation: less verification, less aerial changes…

The feature parameter tuning and the End to End performance tests are stages of the optimisation process that help in improving the quality of service of the 3G network once the RF layer has been optimised.

Page 9: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 9/38

PREPARATORY WORK AND RF DESIGN AUDIT

This step, largely described in the chapter “Project Preparation”, can be articulated in a series of workshops between Nortel and the operator and has to take place before any operational activity. The objective is to discuss upfront and agree upon the details of the following:

• the processes to be put in place during the project

• the existing interdependencies

• the committed deliverables

• the exit criteria

• the various required interfaces and communication channels

In this phase, specially important is to perform a detailed and comprehensive audit of the radio design: chapter “ 5.1 RF Design Audit workshops and studies”.

SITE SHAKEDOWN

Before the performance optimisation process can actually begin, network testing at node level and inter-working with Core network must have progressed to the point that basic call routing (voice and data) has been validated (i.e. local calls can be completed). Shakedown tests are done to verify the basic functionality of the RNS, rather than performance. Transmit power, scrambling code allocation and basic call processing functions are tested on a per-sector basis. Shakedown tests are completed when correct codes are set up, power levels are measured, basic call setup and softer handoffs are successfully executed during drive tests around the site.

Once all the sites belonging to the cluster have passed the shakedown test, the RF optimisation can begin.

Note that in some cases, all or some the tests associated with the “shakedown” can be done by the I&C teams during the site commissioning and integration.

CLUSTER OPTIMISATION

Cluster optimisation provides the first pass of optimisation and will adjust settings for parameters, antenna tilts and antenna orientations where required. The recommended cluster size is around 20 up to 40 sites to make faster the optimisation with regards to the roll-out activities. The system performance metrics are calculated for the cluster when basing the acceptance at Cluster network level, in this case the Network Optimisation phase would not occur.

Simulated load (OCNS) can be used during some phases of the optimisation process to assess the RF conditions that the user will observe when the network carries traffic.

Page 10: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 10/38

Usually, the Initial RF Optimisation is first done in unloaded conditions. As a second step, load is simulated in order to perform a second round of verification.

The optimisation and acceptance procedures under simulated-load conditions must be agreed previously with the customer. Tests under simulated load are not usually done in Network Densification scenarios.

NETWORK OPTIMISATION

The objective of Network optimisation is to optimise the sum of all neighbour clusters (inter-cluster areas would be optimised at this stage) covering an entire region of just deployed and optimised clusters but not yet accepted. This phase can starts with two optimised clusters and ends with all the clusters in the region optimised. This stage could be required when basing the acceptance at an area level instead of cluster level. The entire region is fine-tuned with remaining and new issues resolved. In addition, action plans for future work are defined. The system performance metrics are calculated for the entire region to base network acceptance

NETWORK ACCEPTANCE

Phase dictated for Acceptance data reporting purposes and cluster/area acceptance meetings with the customer. The contractual requirements are verified, the deliverables transferred and the acceptance certificate signed-off (invoicing launched). As we are considering that the operations are done in an area without UMTS subscribers, the optimisation objectives in terms of performance are measured with drive-test-based indicators (KPIs). In the case of an “Extension” some counter-based objectives can be added in the boundary zone.

The scope of the acceptance phase can be limited to the cluster or to a larger area.

Refer to chapter “ 5.6 Measurement and Acceptance Process” for more details on this step.

Page 11: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 11/38

5. PROJECT PREPARATION

As in any complex project, the preparation phase is key for the success and the efficiency of the work to be done by the on-the-field teams.

The following chapter aims at describing some important steps that need to be addressed in order to prepare the optimization activity.

Obviously, the extent and contents of each of the following workshops and project processes will depend on the customer quality requirements and the operational tasks that need to be executed. Indeed, if the process only requires performance monitoring at counter level or if there is no budgeted antenna optimisation, there is no need to define the drive testing processes or the protocol to deal with antenna sub-contractors.

Each one of the outcomes, processes and agreements that follow each any workshop and preparation work must be correctly documented.

The following workshops need to be held before starting any operational activity. These steps should be part of the overall project plan and be planned appropriately in advance of the operational activities.

This phase of the project will help in creating the project processes (aligning them with the customer needs and constraints) and in defining the detailed project plan.

The ultimate objective is to diminish the project risks.

5.1. RF DESIGN AUDIT WORKSHOPS AND STUDIES

The RF Design Audit allows the optimisation team to be aware of all design assumptions that could impact the service performance of the network. The best trade off between capacity, coverage and quality of coverage is what needs to be discussed at this stage.

As the optimisation service has to achieve contractually challenging performance indicators, this phase permits the team to verify that the design assumptions used by the operator will not impeach that goal. If during this step, important issues are discovered, the KPI targets, the exclusion zone definition or the measurement methodology should be reviewed.

During this phase, the optimisation team also begins to know the network that need to be optimised: sites, routes, simulated RF footprints, design tools …

This phase can be forfeited if Nortel has had the responsibility of the network design. Nortel will assure the transfer of the necessary information between the design and optimisation teams.

Nortel’s experience shows that networks which RF design has been thoughtfully done considering the right assumptions and with a pre-

Page 12: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 12/38

optimisation phase (simulated results of live conditions) need shorter periods of optimisation: less verification, less aerial changes…

A pre-optimisation service based on simulation tools can be proposed to the customer at this stage.

Other items to consider are:

• Noise floor measurements and antenna sweep reports in order to verify the lack of RF interferers (spectrum clearance).

• Review the RF design and assumptions (type of service per area, traffic per service and per area, clutter documentation and definition) in each region.

• Access to cell planning tools and databases (DTMs, propagation models…) has to be guaranteed during the whole duration of the project. It is recommended to use a common RF planning tool between the customer and Nortel’s teams. If necessary, plan a training period and a validation of the customer planning tools if they are not correctly known by Nortel.

• RF Configuration Audit. A special attention is needed during the definition of the CPICH power, CCCH powers, TX power and the study of the HSDPA evolution and strategy (number of carriers, reserved power, points of reference for the NodeB power setting…).

• Set the configuration of the OCNS if tests with simulated load are required.

• Gather the sites aerial constraints (antenna set, feeders, couplers, access…) in order to anticipate the solutions available if problems arise. Site dossiers (pictures, installation details …) must be available to the optimisation teams.

• Flag the indoor coverage requirements: indoor sites, margins/methodology used to guarantee indoor coverage from outdoor sites… Define the priorities to respect when a compromise is needed between indoor coverage and pilot contention.

• Flag Hot Spots and marketing-driven “Golden areas”.

• Define the neighbouring plan conversion steps and rules (in accordance to O&M constraints).

• Determine the optimisation clusters and the routes for the optimisation and acceptance drive tests3. A cluster has to be coherent from a RF coverage point of view. Define the Golden Clusters of the network.

• Prioritise the clusters following schedule (accessibility, densification) and marketing (traffic, HSDPA ready) constraints. Use that plan to influence roll-out and I&C plans. Fine tune the plan with the rest of the operational teams involved (I&C, OMC ...).

• Set the minimum percentage of sites needed in order to launch the optimisation of a cluster. It is recommended to have at least 90% of the sites available. The acceptance methodology will need to consider the cases of not fully completed clusters and late-sites.

3 Acceptance routes are generally a subset of the optimisation ones. The optimisation routes pretend to cover comprehensively the cluster area.

Page 13: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 13/38

• Understand operator’s process in terms of network design and configuration (validation of the changes, publication of the changes, reporting …)

• Try to define rules of thumb on the way the tilts and azimuth changes have to be decided, depending on the type of antenna, site height and distance to clear. This will help in homogenising the optimisation choices.

CLUSTER DEFINITION

The cluster definition rules are specific for each one of the network deployment scenarios. The definitions of the cluster borders will be done based on cluster predictions applying design thresholds, topology information and customer feedback. A cluster has to be coherent from a RF coverage point of view.

The drive test routes for performance acceptance will be defined inside each one of the cluster when the acceptance is done at cluster level.

Network Rollout Cluster – Geographical area covering not-optimised sites without any radio interactions or dependencies with other live clusters (carrying live traffic). A cluster has a reference number of 20 to 40 sites, customisable on cluster specificities.

Network Extension Cluster – Geographical area covering not-optimised sites with radio interactions or dependencies with live clusters (carrying live traffic). It must include the first tier of sites around the new sites, and eventually other existing sites which influence area is potentially impacted by the new sites.

Network Densification Cluster – Or “Site-Cluster” is to be defined by the influence area of the new site/s to be deployed, and considering the neighbour live sites service areas. It must include the first tier of sites around the new sites, and eventually other existing sites which influence area is potentially impacted by the new sites.

DRIVE ROUTES

The optimisation routes for drive testing intend to cover a representative section of the cluster and include:

• main thoroughfares: primary and secondary roads

• areas of particular interest: hot spots…

• all areas of overlap between all inward-facing sectors in the cluster

• if the acceptance is done at cluster level, the routes shall include the overlap areas with already-optimised and accepted clusters.

Bad covered areas should be excluded from the drive routes. Some exceptions can be accepted if it is requested to validate 3G-2G continuity but, in general, it is preferable to dedicate specific tests to 3G-2G and focus the teams in maximising 3G-only coverage.

Page 14: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 14/38

Engineering judgment should be used to determine these routes. Marketing concerns, design issues and driving constraints (directions, duration…) should also be considered when defining the various drive test routes.

The drive routes shall be defined conjointly by Nortel and the customer. They must be designed according to threshold definitions in order to avoid crossing exclusion zones. If different threshold levels are applied in different environments (urban, rural…), then drive test routes shall be designed accordingly for each one of those environments.

The routes shall be broken into manageable stretches of roughly 4 to 6 hours drive duration. If this is not possible due to the size of the cluster, then drive routes should be redefined or cluster size should be limited to timescales targets. This must be defined before starting optimisation.

Figure 1 - Example of Cluster Optimisation routes

Acceptance or control routes will be used for demonstrating system performance on an individual cluster basis and on a system wide basis. These routes are used, primarily for performance progress monitoring and should reflect typical network performance, and finally for cluster acceptance purposes.

The control routes should be a subset of the optimisation routes and should require no more than 3 hours of driving for a 20 site cluster. When possible, control routes should be chosen to be contiguous with those from neighbouring clusters. Control routes are extended as each cluster is exited.

Page 15: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 15/38

5.2. FEATURES AND PARAMETER ALIGNMENT WORKSHOPS

• Describe Nortel’s UTRAN features and associated parameters and recommended values. Analyse the chosen settings.

• Gather the main RF configuration parameters. Identify those that could be tuned during the optimisation Put special attention to the mobility features: neighbour plan, SHO setting, IRM…

• Understand operator’s process in terms of network design and configuration (validation of the changes, publication of the changes, reporting …).

• Align and homogenise the parameter setting within the network (Configuration Audit).

• Define lists with parameters and setting ranges that can be set locally by the optimisation engineer without approval, those which the optimisation manager has to approve and those that need to be sanctioned by the customer. Try to define rules of thumb on the way the parameters need to be tuned.

• Prepare, conjointly with the customer, a preliminary test plan for the Golden Cluster or Pilot areas indicating the features and parameters to test.

5.3. MONITORING WORKSHOPS

• Explain Nortel’s Monitoring process and tools, and recommended typical metric targets.

• Define conjointly formulas which could match the metrics the customer is used to manage and report.

• Recommend reporting methodology during the project. The methodology must be adapted to the project plan, i.e., it can evolve following changes in coverage, list of activated features or traffic.

• Recommend reporting and supervision methodology during the hours that follow the integration of each site (“worst-cell list”). Specially in the Densification and Extension scenarios.

• Define carefully the metrics used during the quality benchmarks including the averaging procedures and the minimum sample size to make them significant.

• Call Tracing capabilities must be fully dedicated to the optimisation team. The limitations of that feature must be known and respected.

• Alarm management and troubleshooting must be guaranteed during the optimisation process.

• Access to cell Performance Management server has to be guaranteed during the whole duration of the project.

• Determine the hand-over of the supervision responsibility between Nortel and the operator once each site has been swapped / integrated / optimised / accepted.

Page 16: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 16/38

5.4. PROJECT PROCESSES

The processes associated with the optimisation project need to be agreed by all stakeholders: customer, engineering, partners, project management. They need to be clearly defined and accepted before starting any operation in the network once the contract has been granted.

The process description should include: working templates, accountabilities (escalation / approval), service levels to be respected, reporting metrics (both internal to the project and external to the customer) and the description of the contractual deliverables.

If confidential information is exchanged with the customer and between partners and subcontractors, it is mandatory to sign Non Disclosure Agreements (NDA) with all the involved parties.

The sign-off reports (deliverables) for each step of the project phases need to contain enough relevant information without impacting the project progress. The report’s usefulness, timeliness and workload need to be balanced. A heavy reporting can delay the work without bringing enough benefits.

Study, in each case, the impact of “out-of-the-process” scenarii and conduct “what-if” analysis (Risk Analysis). It is also necessary to prepare procedures to change or complete the process during the project execution (Change Control system).

The following are critical operational processes that need to be agreed between the optimisation manager and the managers of the involved organisations: NOC, Configuration, Supervision, Partners, Customer …. Their SLA need to be clearly defined and respected in order to honour the planning and the efficiency of the on-the-field teams:

• Trouble Ticket Process (both at project and at Product Support (GPS) levels).

• Datafill / Configuration Change Request Process.

• Aerial Configuration Change Process. This process needs to cover the approval (deliverable) of the change by the customer (after control), the communication path to the subcontractor and the managing of issues and performance metrics.

• Communication Plan. Internally within the optimisation team but also externally, with all the project stakeholders. Define the operator’s needs in terms of progress reporting (including quality metrics to be provided).

• Contract Management Process. Identification of the stakeholders, definition and follow-up of the contractual deliverables, deliverable reception sign-off, follow-up of the penalties, JCO process, invoicing and formal final acceptance. This process is to be defined, at enough level of extent, together with the customer and with each third party company involved in the project.

Page 17: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 17/38

It is recommended to establish direct communication links between UTRAN, CORE and Service Platform teams. The reason for this is two fold: the optimisation team has to be informed on any activity or event that affects performance and also be able to contact the adequate peers in order to debug any issue.

In order to increase the reactivity and facilitate the communication, it is advisable to make available to the optimisation team a direct link to the supervision reports (trouble tickets) or the Fault Management system of the UTRAN, Core Network and Service platforms. That will help in crosschecking any important degradation observed in the field and the status of the opened tickets.

The following are internal processes used within the optimisation team. They have to be primarily agreed between the optimisation manager and the partners and subcontractors controlled by her. They can include customer requirements when needed (for example in the communication path) and can be used as a quality assurance procedures:

• Drive Test Procedures and Checklists: trace mobiles (hardware and software), radio chain, calibration procedures, averaging, binning, scanner configuration…

• Optimisation Data Management process (and related database specification).

• Optimisation Equipment Management Process (and related database specification).

• Optimisation Training and Quality Process (of the team involved in the optimisation project).

• Measurement and Acceptance Process (cf. chapter 5.6 below for details).

The optimisation teams need to be aware and eventually provide feedback on the site Integration and Commissioning (I&C) Process. The nature and results of the tests performed by the “commissioners” are of vital importance to assess the readiness of the site to become part of an “to-optimise-ready” cluster.

In addition, the management of the RF configuration parameters at the NOC (Network Operations Center), when the site is brought into the live network, is vital to feed the optimisation databases and plan the steps that precede the live testing: neighbouring relationships, frequencies in use, service templates, alarm status …

It is advisable to think in the office constraints the project team will require: office footprint, desks, PCs, networking, IT support… Indeed, big optimisation projects can need a large headcount which needs to be served accordingly.

Finally, it is likely that, by the final phases of the optimisation project, the customer requires knowledge transfer sessions (KTS) including formal or informal (on-the-job) training (OJT). That training can cover both technical and procedural topics. Therefore, it is important to plan those activities accordingly and agree on their scope and duration in advance.

Page 18: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 18/38

5.5. PROJECT DATABASE

It is mandatory for a correct follow up of all the operations to have a common and unique project information system (Project Database) which should include, among other information:

• Site configuration.

• Site issues.

• Updated operations plan.

• Implemented/Planed Changes.

• Metrics: performance KPI, downtimes, workload, delays, escalated issues…

• Work Orders and implementation delays.

• Reporting templates.

• Equipment tracking.

5.6. MEASUREMENT AND ACCEPTANCE PROCESS

Measurement process (tools, UEs, radio paths…) and methodology (exclusions, statistical methods) will be presented and consolidated with the customer. This process needs to be linked to the “Drive Test Procedures” document and known by the whole data acquisition team.

A special attention must be brought to the radio chain of the drive test car. The attenuation of all elements must be known and proper calibration has to be periodically done in order to guarantee the exactness of the recovered data. The optimisation teams need to trust the collected data. It is mandatory to use the same radio elements, if using external antennas, for both the test handset and the scanner. If attenuation boxes are used, they need to be calibrated as well.

Figure 2 - Typical configuration of measurement equipment

Page 19: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 19/38

In order to better control the tests conditions, it is desirable to perform all the drive tests (during optimisation and acceptance phases) being the new sites “barred for operator use” (the optimisation team will use specific SIM cards).

The acceptance methodology is a key document that needs to be studied carefully and that will define the final contractual deliverable and influence the whole optimisation and verification steps. The exit criteria has to be defined properly and in very detailed manner including all the exclusions allowed.

The number of test protocols and services to report may be different depending on the verifications needed before a commercial launch and/or on the level of optimisation detail that the operator wants to achieve (fine tuning of complex features).

However, the goodness of a radio optimisation work can be demonstrated with a reduced set of reported Key Performance Indicators (KPI). Indeed, when the goodness of the RF layer (interference control, coverage enhancement, neighbouring plan) is demonstrated with one service (and eventually a WCDMA scanner) and the feature parameter tuning has been properly studied in a golden cluster, chances are that any additional service to test will pass the performance criteria.

It is important to find the good trade off between optimisation effectiveness, cost and customer satisfaction (assuring him that the optimisation done is the best we could deliver).

The scope of the acceptance phase can be limited to the cluster or to a larger area:

• Acceptance at Cluster Level: As soon as a cluster is optimised, passing through site shakedown and cluster optimisation phases (considering the areas of inter-cluster borders and the clearance of major issues) triggers the acceptance phase for the cluster. The number of samples collected during the cluster optimisation (last drive on the acceptance routes) needs to be statistically relevant for acceptance purposes.

• Acceptance at an Area or Region Level: Within an area or region covering more than one cluster without any live neighbour cluster (carrying traffic), as soon the Network Optimisation phase has been completed, it will be available for acceptance purposes. The recommend maximum number of sites to be “accepted” simultaneously is 100 sites (area with 4 to 5 typical clusters), mainly due to possible time constraints limitations.

Economies can be achieved if the driving routes (acceptance routes) cover several clusters (typical cluster size equals 20 to 40 sites). That is, if 100 calls is the minimum statistically valid sample size to calculate one KPI, and if we need to benchmark each one of the clusters, we will need to generate 100 calls per cluster. If we group 4 clusters for acceptance, we would need to generate 100 calls in the whole area, instead of 400.

Concerning the target KPIs, when the acceptance tests are performed in larger areas, the effects of poor performance in some places due to design constraints is balanced with excellent performance in other areas. The average value of the performance indicator is compensated. That is not possible when the acceptance is to be done in

Page 20: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 20/38

small areas. If that is the case, several options are possible and need to be negotiated with the customer:

• Allow the possibility of not reaching the target values in a small percentage of clusters

• Set a minimal value for the desired performance and average then the results of a larger area.

• Define exclusion areas where the design impeaches the achievement of the desired targets (as indicated in chapter 5.6.1 below).

The acceptance methodology will probably need to include ways to manage the acceptance of a “not fully optimised cluster” (exclusions to be defined during the benchmark) and the acceptance of a “late-site” (need of a “light” procedure).

The KPI measurement methodology has to be very clearly described:

• The KPIs need to be calculated using the information available in the collected traces: use only objective formulas and avoid difficult post-processing.

• Determine the minimum number of samples (minimum number of hours driven and calls performed) and how the averaging must be performed (at cluster and city levels). The results need to have enough statistical value.

• Bound the accountability to the areas of the network controlled by Nortel. Include exception management when the team faces issues with the mobiles or the Core Network.

• Clearly take into account the coverage-related exclusion zones and define the methods to not count the samples recorded in those zones.

If testing under simulated load or simulated indoor conditions is requested, it would be necessary to determine the precise configuration of the whole measurement chain (including attenuators).

If the data collection activity is outsourced, it is important to be able to recover the reports and traces and be able to post-process them with Nortel tools. It is important to verify the format needs both of the optimisation teams and the support teams (GPS).

If any comparative performance benchmark is necessary during the optimisation process (feature analysis, equipment upgrade, equipment swap…), in order to fairly compare results, it is mandatory to perform all the measurement campaigns on the same routes, with the same equipment (mobile, car, antenna, radio chain, server…) and the same post-processing tools.

In order to be able to compare correctly the performance within each one of the optimisation phases, it is assumed that no change occurs in the core network, transmission network or services platform. Should the customer decide to perform any changes or modifications on those nodes, Nortel would expect to be made aware and commonly re-examine with her the potential impacts on the overall methodology and targets.

Page 21: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 21/38

5.6.1 DEVIATIONS AND EXCLUSIONS

Deviations and exclusions will be triggered where it was not possible to implement the appropriate optimisation recommendations:

• Derived from the RF Design Audit

• When the built network does not comply with the design rules in that area.

• Inability to set the correct antenna tilt / azimuth: GSM/UMTS antenna…

• Inability to optimise further due to limitations on site profile: street furniture…

• Non ideal antenna heights due to site or planning constraints

• Sites missing: not-contracted sites, next-phase sites, not-radiating sites…

This process will include the development and agreement of situations for triggering those exclusions and deviations; and defining consecutive concessions on the KPI. It should be agreed prior to service commencement and include an escalation process for non-agreement on non-compliant design issues.

Where non-compliance issues exist:

• Nortel may propose new performance indicators for the area (cell/group of cells/subset of cells) affected by the minor non-compliance. The contractual targets are lowered.

• Nortel may exclude the number of failures affecting the KPI due to this situation. This will be described in the “KPI Measurement methodology” document. The contractual targets are kept.

• Nortel may propose to enlarge the exclusion zone where major issues exists or if they cover a large area. The performance indicators will be reported but they will not be bound to the contractual targets.

After a site or area, the RF design and neighbouring settings of the surrounding region might be revisited.

Figure 3 - Example of Call Drop impossible to avoid with current design.

Page 22: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 22/38

5.7. PROJECT PLAN

Preliminary project plan will be finalised once all the processes, KPI definitions, exit criteria and communication channels have been discussed and agreed.

The following aspects should be covered:

• Phases

• Activities

• Timelines

• Interdependencies

The project plan has to include details on the resource plan (headcount, skills…) and indicate when those resources are available to the project.

All the necessary software (tools, databases,…) and hardware (mobiles, scanners, PCs, cars, desks …) elements that are needed by the optimisation team must be identified and available before starting the optimisation phases. The logistics has to be managed. All the resources, both human and material, must be on site at the planned moment.

The following figure shows a typical optimisation planning for a city of 180 sites based on a several project assumptions (which may largely differ between different projects):

Figure 4 - Project Plan example

The following chart shows the ramp-up and ramp-down in a monthly scale of the headcount of a large optimization project (per type of resource):

Figure 5 - Resource plan

Commisionned sites 10 10 5 5 20 20 20 10 15 15 15 15 10 10 10Cumul of sites available 10 20 25 30 50 70 90 100 115 130 145 160 170 180 190 190 190 190 190 190

Drive Test Teams 1 2 2 2 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 2 2 2 2 2 1 1Optim Engs 1 1 1 2 2 2 3 3 3 4 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 4 3 2 2 2 1 1

Aerial Tunning Engs 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1HC Sum 1 1 1 2 3 5 8 8 8 11 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 9 8 7 7 6 3 3

System optim + Radio performance

Cluster # optimCluster # optim

Cluster # optim

Local preparation Cell shakedown

Cluster # optimCluster # optim

Cluster # optimCluster # optim

Cluster # optimCluster # optim

Cluster # optim

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10 11

Month

Hea

d C

oun

t

Page 23: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 23/38

6. 3G INITIAL OPTIMISATION PROCESS

The bulk of the OPTIMISATION PROCESS follows the PREPARATION PHASE described in the previous chapter. It is mandatory to complete all the preparatory activities before starting the optimisation phase.

The following schema summarizes the overall process:

Preliminary RF Design

Release RFDesign

Acquire and Install sites

Configuration Audit : Entrance Criteria• Predicted RF coverage area• Noise Floor Measurements• Antenna Sweeps • Site parameters ( carrier(s), codes,

configuration ... full datafill)• Complete Integration

Configuration Audit : Exit Criteria • Set of documents containing results

of all preset actions.• Set of documents giving the final

state (configuration, parameter set, parameter values)

Shakedown : Entrance CriteriaEach cell must exit Configuration Audit

Shakedown : Exit Criteria • Sector tests completed

(could include calls and handoffs) • Carrier(s) checked• Codes checked• Power levels checked

Cluster Optimization : Entrance Criteria Each cluster must exit Shakedown

Cluster Optimization :• Complete drive-tests• Collect metrics and

statistics

Cluster Optimization : Exit Criteria• Provide report on control route

complying with agreed metrics.

• Provide issue list

System Optimization : Entrance Criteria Each cluster must exit cluster optimization

System Optimization :• Complete drive-tests• Collect system-wide

metrics and statistics• Address issues in

the issue list

System Optimization : Exit Criteria• Provide report on control route

complying with agreed metrics• Provide optional reports on

optimization.

System AcceptanceThe client and Nortel Networks signoff on the acceptance of the system

( upon customer request)

( upon customer request)

Preliminary RF Design

Release RFDesign

Acquire and Install sites

Configuration Audit : Entrance Criteria• Predicted RF coverage area• Noise Floor Measurements• Antenna Sweeps • Site parameters ( carrier(s), codes,

configuration ... full datafill)• Complete Integration

Configuration Audit : Exit Criteria • Set of documents containing results

of all preset actions.• Set of documents giving the final

state (configuration, parameter set, parameter values)

Shakedown : Entrance CriteriaEach cell must exit Configuration Audit

Shakedown : Exit Criteria • Sector tests completed

(could include calls and handoffs) • Carrier(s) checked• Codes checked• Power levels checked

Cluster Optimization : Entrance Criteria Each cluster must exit Shakedown

Cluster Optimization :• Complete drive-tests• Collect metrics and

statistics

Cluster Optimization : Exit Criteria• Provide report on control route

complying with agreed metrics.

• Provide issue list

Network Optimization : Entrance Criteria Each cluster must exit cluster optimization

Network Optimization:• Complete drive-tests• Collect system-wide

metrics and statistics• Address issues in

the issue list

Network Optimization : Exit Criteria• Provide report on control route

complying with agreed metrics• Provide optional reports on

optimization.

Network AcceptanceThe client and Nortel Networks signoff on the acceptance of the system

( upon customer request)

( upon customer request)

Page 24: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 24/38

6.1. SITE SHAKEDOWN

The shakedown is the last check after integration and prior to optimisation to detect any residual issues such as cross feeder or errors in the site. It is performed on site by site basis and any issues shall be corrected.

Note that in some cases, the site shakedown is performed during the integration of the site by I&C teams.

Whenever possible, and in order to better isolate the site from the neighbouring ones, it is recommended to perform the Shakedown in a dedicated frequency (the I&C one for example) and with only the intra-site neighbours in the list (to avoid Soft HO with other sites).

ENTRANCE CRITERIA

Integration tests must be passed and accepted. Integration tests are used to show construction completion and basic network readiness.

TASKS

The transmission and reception cabling have to be double-checked based on the drive tests data:

• UE transmitted power is analysed to check possible reception cabling problems.

• Ec/Io and RSCP are analysed to check possible transmission cabling problems.

• Scrambling Codes are analysed to determine if all antennas are pointing to the right directions and that there is no cross-feeder.

If an antenna is found to be incorrectly installed, then a work order will have to be issued as soon as possible to fix the problem.

The RF Design audit performed during the project preparation phase can be used as an input to determine specific routes or highlight special constraints in the shakedown report.

Drive tests must be performed by driving in circular routes around the base station. These drive routes for shakedowns are defined as circles around the cell at approximately 30 percent of the expected cell coverage area.

In addition, the drive tests test the call setup of CS and PS services in each cell and the goodness of the handoffs (softer) between cells in the site.

During this phase, a specific configuration audit at site level can be done in order to verify specific node-B level parameters: feeder loss, initial neighbouring …

Page 25: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 25/38

EXIT CRITERIA

• Site testing is completed when correct code and reasonable power levels are measured and softer handoffs are successfully executed.

• Calls on both domains (Circuit Switched and Packet Switched) must have been completed successfully on the site.

• There should be no issue list after shakedown tests. If issues are remaining, the warranty area might be revised before starting the next phase.

• Agreed deliverables and reporting finished.

6.2. CLUSTER OPTIMISATION

The objectives of the cluster optimisation are:

• Perform RF design verification,

• Identify, categorise and correct RF control, network or coverage issues.

• Optimise for best performance according to the acceptance criteria,

• Serve as a first pass of problem resolution.

During the last stages of the cluster optimisation, samples of the acceptance performance data have to be collected in order to verify the readiness of the cluster for the network optimisation phase (if existing more than one cluster) and final performance acceptance data collection stages.

Areas not meeting targeted performance must be included in the issue list.

ENTRANCE CRITERIA

Each of the following criteria must be met prior to starting optimisation on each cluster:

• Shakedown tests must have been successfully completed on all cell sites in the cluster.

• The sites not available (not yet deployed or without I&C) at the cluster optimisation phase will not be considered for optimisation and acceptance purposes. This occurrence would trigger an exclusion within the acceptance process. These sites (Late arrival sites) will be managed (optimised) later following the Network Densification process. However, the RF footprint of the missing site has to be taken into account when deciding to optimise the aerial configuration in the area supposedly covered by that site. That is why it is better to get the highest amount of sites integrated before starting the cluster optimisation.

• Ideally, the cluster must not have any UMTS mobiles operating other than those by the team performing the optimisation (i.e. controlled environment). The Network Extension and Network Densification processes will differ on this.

Page 26: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 26/38

• The network is locked from any hardware or software changes, except for maintenance purpose (e.g. hardware failure, critical software bug...).

TASKS

The optimisation process is divided in a set of iterative drive tests which will produce inputs for the following analysis:

• RF Coverage Control, primarily based on Scanner traces

• Neighbour list tuning (3G to 3G and 3G to 2G)

• Performance assessments

Raw data files from the drive tests shall be brought back to a central location for processing and analysis by the optimisation engineers. Drive test data may also be merged with UMTS RNC diagnostic call trace logs for further analyses.

The optimisation engineers will identify areas where optimisation goals are not met, produce and submit recommendations for changes and classify and analyse the observed problems.

Typical issues found at this stage are:

• RF Coverage Control requirements

o Low RSCP (i.e. coverage goals not achieved).

o Low CPICH_Ec/Io (when RSCP complies with coverage targets).

o Lack of Scrambling Code dominance

o Overshooting.

• High Active Set Size (i.e. RSCP and CPICH_Ec/Io comply with target but active set size >= 4 within a specified window of X dB from the best server)

• 3G and 2G neighbouring lists incomplete.

• Failures at the accessibility and retainability domains will be tracked and followed-up. UE and Network issues are to be identified and documented.

Figure 6 - Example of overshooting

Page 27: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 27/38

If it is necessary to change an antenna tilt or azimuth, the impact of the suggested change has to be analysed using with RF simulation tools (as in the RF design) and validated with the customer (cell planner responsible of the area).

Figure 7 - Analysis of the effects of tilting optimisation

Recommended physical changes will be included in the optimisation report even if they are not feasible within the timelines of the project. Some changes such as raising or lowering of antennas may not be feasible or cost-effective means of making the necessary changes to coverage. In such cases, the merits of less costly alternatives, such as reduction of pilot power, or antenna swap-outs must be assessed. In this case, deviations in performance shall be considered.

Inter-cluster optimisation can be carried out at this stage when working on clusters which neighbouring clusters have already been optimised (the drive tests routes can be extended to cover the inter-cluster areas). This is particularly necessary when the acceptance of the optimisation service is done at cluster level/

If neighbouring clusters are not yet accepted, the acceptance may be defined to be performed at area or region level, gathering more that one cluster, and implying to pass through the Network Optimisation phase.

TEST DRIVES

Iterations of the drive tests have to be planned to improve the network; these iterations are necessary mainly due to the dynamic aspect of the WCDMA technology. Cluster optimisation therefore involves performing different test drives.

The optimisation engineers shall use their judgment in deciding whether or not all test drives are required and how often and in what order each test drive needs to be performed. In the same spirit, several hereafter proposed drive tests can be grouped in the same run.

The services tested with the mobile during the tests are to be defined taking into account the performance objectives. CS and PS domain calls can be done simultaneously during each one of the drives using two mobiles in parallel.

Page 28: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 28/38

In order to focus the analysis on RF issues and simplify the operational process, it is recommended to limit the number of services tested during the first drives to only two (CS voice and PS FTP for example).

If the acceptance is done at Cluster Level, all the services defined in the contract have to be tested in the final drive in order to be sure that the cluster is ready for acceptance. If the acceptance is done at network (area or region) level, the last drive can be either bypassed or simplified (use just two services) as the final check will be done during the Network Optimisation stage.

In the same spirit (focus on RF control), it is recommended to deactivate features that can impact the collection of performance data (IRM scheduling, traffic segmentation…) specially at the first stages of the project. Other services tests and parameter fine-tuning of complex features are to be done in the Golden Clusters.

In any case, coherence has to exist between the contractual requirements in terms of optimisation and what is possible to achieve in a dynamic environment as WCDMA. The work involved and the test conditions that need to be guaranteed have to be well understood during the definition of the scope, budget and schedule of the optimisation project.

Drive tests may be done under loaded and unloaded conditions4. Indoor conditions can be simulated using attenuation boxes during the drive test.

The data to be collected is given below for information. RNC logging (Call Tracing) must be set up for all drives, except when only using the scanner.

Pilot Optimisation

Drive

Routes: Optimization routes. Purpose: Determine the actual pilot coverage for each cluster and solve the main RF propagation issues (pilot shoot-up, pilot pollution, scrambling code overlap...) Equipment: Pilot scanner. Data collected: SC, Per-PCPICH coverage; Best PCPICH coverage; 2nd, 3rd, 4th CPICH coverage; Number of PCPICH over a given EC/N0, 2G data..

Radio Optimisation

Drive

Routes: Optimisation routes. Purpose: Ensure the RF coverage control and RF optimisation (antenna azimuths, tilts, power settings, neighbour list tuning). Mobile mode: Connected, long duration calls originated from test mobiles. Data collected: EC/N0, Mobile transmitted power, average number of radio links, number of dropped calls, throughput, setup access rate and time ...

Fine Tuning Drive

Routes: Optimisation routes. Purpose: Check and fine-tune the optimisation results after modifications. Mobile mode: Connected, long duration call originated from test mobiles. Data collected: EC/N0, Mobile transmitted power, average number of radio links, number of dropped calls, throughput, setup access rate and time ...

4 DL load can be simulated using Nortel’s OCNS feature. UL load can be simulated adding extra attenuation on the transmission path of the handset.

Page 29: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 29/38

Final Cluster Check Drive

Routes: Control routes. Purpose: Do the final check and collect acceptance measurement for this cluster. Mobile mode: Connected, long and short duration call originated from test mobiles. Data collected: Acceptance performance metrics.

EXIT CRITERIA

If the acceptance of the optimisation service is done at cluster level, the exit criteria of this phase can only be the achievement of the contractual performance targets.

If some optimisation actions are still pending on the cluster, it can be agreed to perform the acceptance tests at a larger area scale (group of clusters) up to a maximum of around 100 sites per area.

If the acceptance at a larger scale has been decided, the calculated system performance metrics at the cluster must be close enough to the agreed thresholds in order to exit this stage.

6.3. NETWORK OPTIMISATION

When the acceptance is performed at area or region level, the objective of this step is to finalise the optimisation of the sum of all clusters covering an entire region, specially the inter-cluster areas which have remained without proper analysis and areas where new sites have been added after the cluster optimisation phase.

The network optimisation starts with two optimised clusters and ends with all the clusters in the region. The entire region is fine-tuned with remaining and new issues resolved.

Action plans for future work are defined.

ENTRANCE CRITERIA

All clusters to be optimised must have met the cluster exit criteria with mutually agreed issue list.

TASKS

Network optimisation is typically performed on the control routes. However, additional optimisation drive test routes may be defined for diagnostic testing of new problematic areas identified as a result of new sites being switched on.

Drive tests are primarily focused on the verification of end-to-end and acceptance metrics. They should serve to perform the final fine-tuning of the network settings and to collect statistics for the final acceptance report

Page 30: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 30/38

As in the precedent phase, Network optimisation typically involves performing several test drives. The optimisation engineers shall use their judgement in deciding how often and in what order each test drive needs to be performed (the same set of drives described in the Cluster Optimisation phase, page 27, can be re-used here). In the same spirit, several hereafter proposed drive tests can be grouped in the same run. CS and PS domain calls can be done simultaneously during each one of the drives.

Drive tests may be done under loaded and unloaded conditions5. Indoor conditions can be simulated using attenuation boxes during the drive test.

RNC logging (Call Tracing) must be set up for all drives, except when only using the scanner.

Since the Network Optimisation is based on a network composed of already tuned clusters, most of the parameters and aerials should already be correctly optimised. Due to the cross-effects between clusters, handoff parameters, neighbour list contents and neighbour prioritisation might need changes at borders between clusters. This is also a time that can be used to finish up the tuning of difficult spots.

EXIT CRITERIA

In order to exit each region, the system performance metrics must meet the threshold requirements.

6.4. FINAL PERFORMANCE ACCEPTANCE

At the end of the Cluster Optimization phase, or Network Optimisation (depending on the acceptance is made by cluster or at region level):

• The optimisation team has delivered the best network in terms of service performance and RF control.

• The team has verified that the contractual target indicators have been met in the conditions requested by the customer.

• The team has produced all the contractual deliverables and made available all the progress reports.

• The final recommendations and issue list, with follow-up plan, has been communicated.

At this stage, the customer can request a verification of the work done and the results obtained before triggering the invoicing and signing off of the service. This last verification can be done during the Final Performance Acceptance stage which should be planned accordingly.

5 DL load can be simulated using Nortel’s OCNS feature. UL load can be simulated adding extra attenuation on the transmission path of the handset.

Page 31: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 31/38

Final drive tests are performed, within the control routes, in order to collect performance acceptance metrics. Those results will be used as reference for the creation of the final performance status report of the network.

The results of those tests should pass the performance targets. Otherwise, further optimisation actions can be requested and financial penalties could be triggered.

7. NETWORK EXTENSION OPTIMISATION

In the Network Extension scenario some of the clusters to be optimised are adjacent to clusters belonging to the live network (carrying traffic):

• Cells carrying live traffic cover an important area of the new cluster as they were isolated and no RF control activity was performed.

• New sites can interfere areas carrying live traffic if no RF control is done.

Therefore, the optimisation activities have to minimise the impact to the live network (subscriber’s quality of service) in the border areas. This means that where the cluster to optimise interacts with the live area:

• Simulated load (OCNS) should not be applied.

• Special care has to be put in the optimisation choices as the real traffic load has to be considered.

• Operations have to be executed with special cleanness and speed. It is likely that some operations in particular sites will only be allowed during “low traffic” hours (night, week-ends…) identified by the operator.

The sites at the border are therefore treated in the same way as the ones deployed in the “Network Densification” scenario. The sites that are not in the border of the cluster and those that belong to clusters without boundaries with the live network are treated as the ones deployed in the “Greenfield Network” scenario.

Generally, the network “boundaries” carry low traffic and the interaction with new areas is low but that verification needs to be done.

The new sites can be optimised with the cells “barred” (only allowed traffic is the operator’s one) and, when possible, working in a frequency different to the one of the live traffic.

If sites carrying live traffic need to be optimised, the operation needs to be planned carefully and the monitoring teams informed as the traffic profiles of the site will probably be modified after the change.

Acceptance of the new sites would be based on drive test KPIs. However, it is usual to define counter-based performance indicators that need to be maintained in the live sites of the boundary areas. This can be discussed during the Monitoring Workshops

Page 32: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 32/38

in the preparation phase (cf. chapter 5.3). The objective is to demonstrate that no or little impact has been produced in those areas following the integration of the new cluster. Do not forget to take into account the changes in the RF profile of the area: new sites, new coverage areas, corrected/degraded areas …

8. NETWORK DENSIFICATION OPTIMISATION

In this scenario, the cluster is outlined around the new site. It will be defined by the influence area of the just-deployed site and considering the neighbour live sites service areas. This “Site-Cluster” must include the first tier of sites around the new one, and eventually other existing sites which influence area is potentially impacted by those new sites.

Important: If several new sites are close enough, the optimisation cluster should cover an extended area including all of those recent sites and their influence areas. Indeed, if the sites are close enough, the optimisation actions in one site will impact the radio profile on the other one. The whole area is to be optimised. Even if the shakedown tests and the radial routes to assess the site coverage are done in a site per site basis (for the new sites), the optimisation decisions have to follow a geographical coherence.

The optimisation activities have to minimise the impact of the integration of the new site in the current subscriber’s quality of service. This means that:

• Simulated load (OCNS) should not be applied.

• Special care has to be put in the optimisation choices as the real traffic load has to be considered.

• Operations have to be executed with special cleanness and speed. It is likely that some operations in particular sites will only be allowed during “low traffic” hours (night, week-ends…) identified by the operator.

Some particularities of the optimisation process need to be taken into consideration in this scenario:

• Site is delivered to the optimisation team with all cells locked, then unlocked just before the site shakedown start. The cells should also be “barred” (only allowed traffic is the operator’s one).

• Site shakedown is performed at a time window where the traffic is low (usually from late in the evening until early in the morning). First site checks are performed on the spot and green light for first optimisation run is given. If faults are detected during shakedown, the site should be locked back immediately as it will likely degrade the subscribers’ quality of service.

• First drive test run is performed just after green light is given (could be performed in the same night just after a successful shakedown). Drive test routes should be designed with the help of simulation tools and should allow to assess how far the site coverage goes (radial routes to identify

Page 33: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 33/38

overshooting areas with the scanner). Cells are locked again immediately after drive test is performed.

• Once hardware and software changes are implemented following the analysis, radio coverage should be controlled after those changes. Site should be then unlocked and “unbarred”. New drive test runs are performed to verify the optimisation done and measure the performance indicators.

• If the observed performance is satisfactory the site is ready for the acceptance tests.

The above recommendations consider that only one WCDMA frequency is available in the area. If the integration and optimisation teams can use a dedicated frequency (different from the one used by live traffic), the site integration and the initial optimisation activities can be carried out on it. In this way, those activities will not impact the current subscribers and the current network and could then be scheduled during the day. An special care has to be put in choosing the adequate cell selection and reselection parameters. It is recommended to use this dedicated frequency but be careful if the area to densify is already using two frequencies for traffic.

If sites carrying live traffic need to be optimised, the operation needs to be planned carefully and the monitoring teams informed as the traffic profiles of the site will probably be modified after the change.

Acceptance of the new sites would be based on drive test KPIs. However, it is usual to define counter-based performance indicators that need to be maintained in the live sites surrounding the new integrated sites. This can be discussed during the Monitoring Workshops in the preparation phase (cf. chapter 5.3). The objective is to demonstrate that no or little impact has been produced in those areas following the integration of new sites. Do not forget to take into account the changes in the RF profile of the area: new sites, new coverage areas, corrected/degraded areas …

9. OPTIMISATION RESOURCES

9.1. TOOLS

A set of tools are needed to carry out the optimisation objectives:

• Simulation Tool for RF design: Nortel generally uses Iplanner (Atoll based tool with additional algorithms). Used for aerial changes validation and RF analysis. There must be consistency with the methods used by the customer so it is possible to use their solution if it hast been validated by Nortel teams.

• Data Acquisition Platform (DAP): currently Couei (XCAL-W)

• Tests Mobiles: typically Qualcomm TM6250, Nokia 6650, Samsung Z500

Page 34: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 34/38

• WCDMA Scanner: used for precise coverage control. The recommended scanner is Anritsu ML8720B (capabilities to measure 2 simultaneous FDD carrier and 2G bandwidth, compatible with Couei’s DAP).

• Post processing platform (PPP): XCAP-W from Couei, complemented with internal tools, which allow automatic and customised KPI generation, built-in failure characterisation functionalities, as well as UE and Call Trace synchronization capabilities (for a deeper and accurate analysis).

• For enhanced troubleshooting, the usage of a protocol analyser (Nethawk) may be required.

• For RF pre-optimisation purposes: an advanced optimisation and network planning software like Arieso’s, currently being used by Nortel.

• Project Database: as described in chapter 5.5.

9.2. TEAM SKILLS

The goal of this chapter is to describe the requested skills for key positions on large scale optimisation projects.

RF Optimisation Leader

• RF Engineering experienced, includes consulting, designing and training.

• Extensive experience in design and optimisation of GSM/UMTS networks, including Nortel’s equipment.

• Extensive experience in continuous monitoring and improving an existing network performance.

• Experienced training junior RF engineers on design and optimisation techniques.

RF Optimisation Engineer

• RF Engineering experienced, includes consulting in both RF design and optimisation of UMTS and GSM plus training.

• Experienced in network optimisation: site verification and cluster optimisation; drive tests of live UMTS network; call troubleshooting analysis; drive surveys analysis; pilot channel RSCP level and interference analysis.

• Knowledge of UMTS standards.

Page 35: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 35/38

9.3. TEAM ORGANISATION

In large optimisation projects, the optimisation team is organised in a national or central structure and several regional or local ones. The final team structure depends on the project constraints (size, time, geography…) and the own organisation of the customer.

The central group assures the coordination, the project management and be the privileged interface with the customer. The main interface between the project team and Nortel’s Core UMTS organisations will be the Optimisation Manager and the RF and Design Authorities. A pool of End to End experts, linked to the central group, will be also available in order to assure the targets defined in the acceptance document.

At regional level, a team of experts is deployed to follow up the activity locally and act as UMTS advisors on any detected issue. They will also ensure the knowledge transfer to the customer regional engineers. The Cell Planning expert will validate together with the customer’s delegate any change on the RF configuration of the site.

The typical accountabilities for each one of the project roles in the regional team are briefly described below:

Optimisation Expert

• Top optimisation project representative in the region. Responsible for the regional optimisation service.

• Project Manager of the regional activity. Reports progress to the customer and the central teams.

• Accountable for the implementation of the optimisation processes and quality standards.

• Manages the relationship with local subcontractors.

• Deals with optimisation complex issues and provides advice.

RF Cell Planning Expert

• Responsible for the RF audit of the regional sites. Provides advice and guidelines during the definition of the optimisation clusters and routes.

• Validates the optimisation choices in terms of aerial tuning. Coordinates the operational process associated to this activity.

• Follows up the availability of the sites and reports to roll out teams critical planning deviations.

• Deals with RF optimisation complex issues and provides advice.

Page 36: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 36/38

Datafill Expert

• Implements and coordinates system parameter changes. Interacts when necessary with Core Network experts.

• Advices on the choice of the right settings, cross-feature impacts and software limitations.

OAM (Network Operation Center)

• A NOC resource must be dedicated to the optimisation activity: is the main contact for the optimisation drive test teams to verify sites availability.

• Assures the supervision of the sites being optimised. Surveys alarms and assures troubleshooting follow up.

• Collects RNC traces and counters.

City Optimisation Leader

• Accountable for the achievement of the performance targets in the city/area.

• Organises and manages the optimisation teams deployed in the area in order to respect the project plan. Gives the date for the final acceptance tests.

• Accountable for the for the implementation of the optimisation processes and quality standards in the area.

• Manages the Golden Cluster activities.

Aerial Tuning Coordinator

• Coordinates the implementation of the aerial tuning changes.

• Assures the access to the sites when necessary in coordination with the customer.

• Follows-up the SLA with the subcontractors and controls the budget associated to this activity.

Optimisation Engineer

• Responsible of achieving the performance targets in the cluster under his responsibility.

• Plans the drive testing activities (with the Drive Test Coordinator if there is one) and interacts with the Aerial Tuning Coordinator.

• Defines the optimisation routes conjointly with the customer and following project directives.

• Reports optimisation progress and performance indicators. Assures the optimisation data management.

Page 37: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 37/38

Drive Test teams

• Collect and manage the drive test measurements.

• Responsible for the maintenance of the measurement equipment including calibration.

• Report immediately site issues to the NOC and the optimisation engineer.

It is common to have a Drive Test Coordinator in projects with large numbers of drive test teams. Her main role would be to distribute the workload of the drive test teams among all the optimisation engineers.

The following chart describes the functional structure deployed in a typical large UMTS optimisation project (UR = UMTS Region):

Loca

l offi

ceR

egio

nal o

ffice

NN OptimisationProject

OptimisationManagerCore Eng’g

Regional Eng’gRegion1N Cities

Region2N Cities

Region NN Cities

RF Design Authority

OAM Supervisor

Datafill Expert

Optimisation Expert

Optimisation Leader OptimisationEngineers

DT teams

RF Cell Plan Expert

E2E expert

RF Meas. expert

Aerial Tuning Tech.

Loca

l offi

ce

Optimisation Leader OptimisationEngineers

DT teamsAerial Tuning Tech.

R&D

1rst level support

Page 38: UTRAN Optimisation Process v01%2E01

UTRAN Optimisation Process

Nortel confidential

UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006 Page 38/38

END OF DOCUMENT