UTRAN Optimisation Process for Swapped Networks v01%2E01

UTRAN Optimisation Process for Swapped Networks

Document number: UMT/IRC/APP/019970 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.


Nortel confidential

UMT/IRC/APP/019970 01.01 / EN Draft 18/Jul/2006 /26

PUBLICATION HISTORY

18/JUL/2006

Issue 01.01 / EN, Draft

Creation.


Nortel confidential


CONTENTS

1. INTRODUCTION .........................................................................................................................3 1.1. OBJECT.................................................................................................................................3 1.2. SCOPE OF THIS DOCUMENT .....................................................................................................3 1.3. AUDIENCE FOR THIS DOCUMENT ..............................................................................................3

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

3. PROCESS OVERVIEW...............................................................................................................3

4. PROJECT PREPARATION.........................................................................................................3 4.1. RF DESIGN AUDIT WORKSHOPS AND STUDIES...........................................................................3 4.2. FEATURES AND PARAMETER ALIGNMENT WORKSHOPS .............................................................3 4.3. MONITORING WORKSHOPS .....................................................................................................3 4.4. PROJECT PROCESSES ............................................................................................................3 4.5. PROJECT DATABASE ..............................................................................................................3 4.6. MEASUREMENT AND ACCEPTANCE PROCESS ...........................................................................3

4.6.1 Deviations and Exclusions ............................................................................................3 4.7. PROJECT PLAN.......................................................................................................................3

5. PILOT PHASE.............................................................................................................................3

6. HSDPA........................................................................................................................................3

7. SWAP QOS VERIFICATION PROCESS ....................................................................................3 7.1. STEP 0 – INITIAL QUALITY BENCHMARK ..................................................................................3 7.2. STEP 1 – SITE VERIFICATION .................................................................................................3 7.3. STEP 2 – CLUSTER VERIFICATION ..........................................................................................3 7.4. STEP 3 – CLUSTER/AREA/CITY QOS VERIFICATION.................................................................3 7.5. STEP 4 – FINAL QUALITY BENCHMARK....................................................................................3

8. PLANNING..................................................................................................................................3


Nortel confidential


1. INTRODUCTION

1.1. OBJECT

This document aims at describing the engineering tasks that are executed in order to guarantee that the Quality of Service is at least maintained and potentially improved, after the hardware swap of UMTS sites.

1.2. SCOPE OF THIS DOCUMENT

This document concerns the SWAP of the complete UTRAN: NodeB + RNC.

In the case of a RNC-Only swap, while most of the procedures can be applied, others are not applicable or necessary as the RF profile of the network is not supposed to be modified. Moreover, there is no need to survey every single NodeB site.

1.3. AUDIENCE FOR THIS DOCUMENT

Optimisation Teams and Project Managers involved in swap activities.

2. RELATED DOCUMENTS

2.1. APPLICABLE DOCUMENTS

[A1] UMT/IRC/APP/019972 UTRAN Optimisation Process

2.2. REFERENCE DOCUMENTS

[R1] UMT/IRC/DD/0011 UTRAN Parameters User Guide, V08.03, UA4.2.


Nortel confidential


3. PROCESS OVERVIEW

The goal of the optimisation is to guarantee that the Quality of Service is at least maintained and potentially improved, after the hardware swap of UMTS sites (RNC, NodeB…).

The optimisation process to respect has to be adapted to the SWAP requirements in terms of:

• Scope (RNC Only, RNC+NodeB, RNC+NodeB+Antenna)

• Schedule (Milestones)

• Budget (range of testing)

• Quality (counters’ performance, outage period allowed, drive testing KPIs)

This process is applied in a in-service network: OCNS will not be used.

In order to guarantee the same user perception before and after the swap, it is important that the coverage and interference levels are maintained or improved. The swap performance verification (this process) does not intend to optimise the aerial configuration, therefore, it is very important to obtain good conversion rules between the other vendor’s and Nortel’s parameters. An special attention must be put on the power settings (including TMA and CCCH configuration) as to guarantee that the RSCP levels (and SHO areas) do not change after the swap. That needs to carefully be studied during the preparation phase and tested in the Pilot zone.

It is assumed that the network to be swapped has already been optimised and therefore the call performance and the radio coverage and interference are at correct levels. Poorly optimised networks will increase the workload during the swap and add risk and pressure during the quality benchmark as radio measurement chains can behave differently at poor radio conditions and more time is needed for deep analysis of the issues. During the performance checks, the RF quality will be verified and optimisation recommendations given but the duration of the project can be impacted if an important number of sites need aerial optimisation.

Generally speaking, the optimisation process after a SWAP follows the next steps:

1. Verification of the correct integration of the swapped site/equipment into the existing network.

2. Verification/Improvement of the Quality of Service at cluster level that guarantees the continuity of service.

3. Verification of the Quality of Service at City/Area level to demonstrate contractual commitments.


Nortel confidential


The following document concerns sites with outdoor coverage. When indoor sites are involved during the swap, the process will need to be adapted due to the different constraints:

• Tracing capabilities inside a building.

• Time necessary to perform the checks (reduced mobility and speed).

• Potentially higher impact of the load in the performance.

PREPARATION

The Preparation Phase is of major importance as it serves to:

• test the SWAP operational procedures,

• work on the equivalence between the previous parameter settings and Nortel’s ones,

• define and test the performance verification procedures (counters equivalence, tools…),

• verify, in a controlled environment, how Nortel’s equipment can effectively offer the same performance as the swapped one, and, eventually,

• demonstrate Nortel’s system quality to the customer (if the customer does not know Nortel’s system). This period can serve as a training one.

A detailed section of this document is dedicated to the Preparation Phase (cf. chapters “ 4 Project Preparation” and “ 5 Pilot Phase”).

STEP 1

During the STEP 1, there is little room to the real optimisation. The main objective is to check that all the I+C operations have been done satisfactorily and that the site is behaving correctly (the performance might be improved later through optimisation). The issue list in STEP 1 will contain the sites/equipment where the user performance is highly impacted by problems related to erroneous hardware installation, cabling, mistakes in the parameter implementation, transmission issues…

The network performance verification after a SWAP is, obviously, always required in operations of this type. The operator desires that its customers suffer of no performance degradation (the outage period is not taken into account) after the operation. Therefore there are performance indicators to monitor before the swap takes place and after the operation: a before/after swap performance check.

Depending on the contract requirements, the performance indicators to monitor are either counter-based or drive-test-based. Many times, it is required to report a combination of both.


Nortel confidential


Sometimes, due to differences in the way Nortel’s performance monitoring system works compared with the other party one (different counters pegs), some margins are allowed in the target metric values.

If the swap is accompanied by the activation of some Nortel specific features and/or new services (like HSDPA), some specific tests (and optimisation) can be required. As there is no initial performance reference for these new features and/or services, their indicators will not be specifically monitored during STEP 1. However, it must be understood the impact of the activation of those features and/or services in the existing ones as the comparative indicators that have to be monitored can be impacted.

As there are contractual commitments and penalties associated to the “before/after” swap performance check, it is recommended to activate any new feature or service in the network after SETP 1, that is, after it has been verified that Nortel equipment has not degraded the performance of the existing services or features.

STEP 2

Once the operation is completed and all the hardware issues are cleared, the observed performance can still be below the targets.

Once the whole cluster has been swapped, STEP 2 allows the engineering team to verify RF quality and performance achieved inside the cluster. The inter-cluster verification will be done during this phase.

It is expected to perform RF optimisation and parameter tuning in order to achieve the desired performance targets.

If only the RNC has been swapped and the initial network was previously RF optimised, there should not be a need to RF optimise again. The parameter fine tuning will be mostly at RNC level (provided that the RNC interacts well with the third party NodeBs).

STEP 3

During STEP 3, the engineering team prepares the final acceptance and performs the final verifications and control. This phase includes the preparation of the deliverables and the achievement of the project’s exit criteria.

In order to ease the process and be able to correctly compare the performance before and after the swap, the benchmarks need to be done under the same conditions. Therefore, it is important to avoid any refresh, densification or major hardware upgrade in any cluster that is being swapped and which has not been accepted by the customer (exit performance benchmark). This is to allow to work on the open performance issues. The assignment of priorities to the clusters during the roll out can include considerations on how urgent is to add new sites an area.


Nortel confidential


4. 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 swap 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 workshop and preparation phase 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 final objective is to diminish the project risks.

4.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 …

Other items to consider are:

• Review the RF design and assumptions (type of service per area, traffic per service and per area, clutter documentation and definition) in each region. Explain Nortel’s Link Budget and design assumptions. It has to be contrasted with the customer assumptions in order to fix a baseline for the RF design review activity.

• Access to cell planning tools and databases (DTMs, propagation models…) has to be guaranteed during the whole duration of the project. It is


Nortel confidential


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…).

• 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 tests1. 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.

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

• Analyse whether the radio quality of service could be improved taking into account the benefits of Nortel equipment with regards to the other supplier ones: PA capabilities, better sensibility… Determine its impact on the swap process and the optimisation requirements associated.

• Check TMA constraints. The removal or update of the existing TMAs will impact the I&C process but also the RF profile of the network. Therefore, special care has to be taken during the preparation phase (parameter setting, RF simulations) and during the performance benchmarking (constraints, exclusion zones, KPIs margins …).

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


Nortel confidential


• If required, demonstrate, through RF tools, that the same service level as existing one is granted with Nortel’s equipment. Show that the areas where users are served do not change.

• 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.

4.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).

• Collect the relevant configuration from the existing network as a working baseline and reference for the definition of Nortel’s templates.

• Try to match the features and settings of the swapped vendor with the ones available in Nortel’s software. Try to find settings which would obtain the same performance. Respect the IOT constraints if any.

• Document precisely the conversion rules and the available templates for each environment and hardware configuration.

• Study the HSDPA implementation and configuration if sites with HSDPA already enabled are within the scope of the swap activity.

• Demonstrate, if required, Nortel software performance and the goodness of the parameter setting in the Golden Cluster (which could be the same which is used during the Pilot phase). The extent of these tests will depend on the actual experience of the customer teams with Nortel system.

• 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.


Nortel confidential


4.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.

• 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.

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

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

• Recommend reporting and supervision methodology during the whole swap period and during the hours that follow the swap of each site (“worst-cell list”).

4.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.


Nortel confidential


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.

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.


Nortel confidential


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 4.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.

The need of an specific “Site Shakedown” activity will depend on the extent and scope of those tests (during the Site Shakedown, cross-feeders, TX power and Intra-site SHO are checked).

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.

4.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:


Nortel confidential


• 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.

4.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.

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.

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

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 (features to be activated or not, changes in traffic conditions…) have to be well understood during the definition of the scope, budget and schedule of the optimisation project.

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.


Nortel confidential


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 before and after, it is assumed that, during that period, 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.

4.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…


Nortel confidential


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.

4.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.


Nortel confidential


5. PILOT PHASE

The Pilot or Golden Cluster help in defining the general recommended parameter settings and to show the good performance obtained with them in a controlled, well known and optimised environment. It is recommended to define more than one Golden Cluster in the network (but not too many) if several, very different between them, radio environments need deep testing.

If the customer has no experience with Nortel equipment, an specific phase, not within this document’s scope, could be required to qualify Nortel’s product before any swap activity.

During the Pilot phase the following is validated:

• IOT constraints.

• I&C process.

• Optimisation Swap Process.

• Quality of Coverage after swap (validation of the RF planning hypothesis).

• Monitoring Process.

Objectives:

• Demonstrate to the customer that the quality of coverage (outdoor and indoor) is guaranteed when using Nortel’s equipment (no aerial is modified except, probably, the TMA).

• Demonstrate that the conversion and new configuration setting for CCCH and output power is valid.

• Tune / Improve / Simplify the operational processes.

The Pilot size has to be comparable to the typical cluster size: 20 to 40 sites.

During the preparation workshops and the Pilot phase, it is needed to demonstrate that the quality of the coverage and the interference levels are maintained after the swap. That is, the conversion rules and parameter settings have been carefully defined and assure the same level of service for the network users.

As the aerial configuration remain untouched, the above implies that any existing weak-covered area will remain after the swap (unless a specific optimisation activity is performed) and that any new weak-covered area has been probably be created by a hardware issue or configuration mistake to be solved.

Any test involving the attenuation box to simulate the indoor penetration will be performed during the Pilot (or Golden Cluster) phase. Once it has been shown that the signal levels are maintained or improved in that cluster, Nortel considers that it is not necessary to verify them for the remaining clusters. This process considers then that no indoor tests (using drive tests and attenuators) will be done outside the Pilot.


Nortel confidential


Once all the above is demonstrated in this initial phase, Nortel will concentrate the project teams effort in verifying the service continuity, that is, improving the network performance if possible, monitoring the performance metrics and detecting and solving issues.

6. HSDPA

The following procedure can be applied when a “HSDPA” site is within the scope of the swap.

If any site has the HSDPA channels enabled before the swap, the initial quality benchmark will be impacted consequently. It is proposed to swap that site and get it HSDPA ready immediately in order to be able to compare in the same conditions the quality obtained after the swap.

It must be taken into account any possible difference between the HSDPA implementation of the other vendor and Nortel. Those differences need to be studied during the preparation phase and taken into account when comparing the performance before and after the swap (documented in the measurement methodology).

Any site that is NOT HSDPA ready before the swap will be maintained in the same condition after the swap. Again, the objective is be able to compare the quality before and after the operation. The HSDPA refresh should be planned after the swap has been taken place and the site accepted.

7. SWAP QOS VERIFICATION PROCESS

The verification or optimisation process can be based on just drive-test-based performance indicators or on both counter-based and drive-test-based indicators. Even if the counter monitoring is a key part of the process, some performance indicators and specific optimisation studies can only be obtained with drive tests.

It is necessary then to adapt the process to the acceptance requirements keeping in mind that the drive test option is expensive but their results are better controlled and can be better analysed.

This chapter describes the recommended procedure for collecting drive-test data and be able to optimise the RF profile of the network through antenna system optimisation.

A counter-based monitoring system has to be implemented in parallel in order to follow the evolution of the optimisation actions and the swap operation. The monitoring is mandatory if there are counter-based metrics in the acceptance procedure.


Nortel confidential


7.1. STEP 0 – INITIAL QUALITY BENCHMARK

PREREQUISITES:

All the preparation steps need to have been completed: processes definition, measurement methodology agreed, acceptance protocol agreed …

Clusters and the control routes have been defined.

OBJECTIVES:

The objective of the initial benchmark is to have the quality reference of the initial network, before any swap activity has occurred. The objective of the subsequent verifications will be to match or overpass that quality reference.

The benchmark can include counter-based and drive-test-based indicators.

In the case of drive test procedures, it is mandatory that the initial benchmark, the final one and all the intermediate verifications are done in the same routes, with the same equipment (mobile, car, antenna, radio chain, server…) and the same post-processing tools.

The performance report has to be available at cluster level and use the same formulas and exclusions as specified in the exit criteria.

In this document, we assume that the acceptance is done at cluster level. That means that the number of samples collected during the cluster verification needs to be statistically relevant. This has an impact on the duration of the benchmark for the whole area or city. Also, the volume of the data collected will impact the post-processing capabilities2.

Economies can be achieved if the driving 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 cluster for acceptance, we would need to generate 100 calls in the whole area, instead of 400.

The traces must be available to Nortel teams for analysis and study.

This activity can be outsourced if required by the customer.

TASKS:

All the contractual performance indicators have to be measured (drive test) or monitored (counters). The list is the one required by the customer. The drive tests configuration and the services tested will be organised accordingly.

During the optimisation phase, in order to streamline the procedures, the number of monitored metrics can be reduced as the quality of the RF optimisation can be

2 The performance comparison before and after the swap is done exclusively using drive tests.


Nortel confidential


demonstrated with just few services. End to end optimisation of the system parameters associated with complex services is likely to be done in specific clusters (Golden Clusters) or during the Pilot Phase.

Any issue related with the UTRAN configuration or the core network should be detected previously during the Pilot phase.

Typically, the following services are to be tested:

• Scanner 3G/2G

• AMR (Voice) Call

• CSD (Video) Call

• PS Call – FTP (both Uplink and Downlink)

Typical KPIs to report are:

• 3G AMR Call 2mn Success Rate

• 3G Video Call 2mn Success Rate

• UL FTP Successful Transfers

• DL FTP Successful Transfers

• Throughput FTP DL

• AMR % time spent on 3G

7.2. STEP 1 – SITE VERIFICATION

PREREQUISITES:

• STEP 0 has been completed and KPI report obtained at least for the cluster where the site is located.

• Drive test routes have been identified.

• Site integration has been completed and any remaining issue cleared.

• A contingency plan needs to be defined to cover the possibility of unexpected degradations of the quality around a site after its integration (i.e. has the site to be locked when important issues are discovered?).

• Site supervision ready during the hours that follow the swap (“worst-cell list”).

OBJECTIVES:

The objective of this step is to verify the service continuity around the site that has just been swapped.


Nortel confidential


It has to be decided whether the site is to be locked after integration and unlocked only when this verification is scheduled. The STEP 1 has to be planned to be executed as soon as the site has been integrated.

TASKS:

The following services are to be tested:

• Scanner 3G/2G

• AMR (Voice) Call – 1mn Mobile 3G/2G (CS Domain Test)

• PS Call – FTP (Download) – 5MB Mobile 3G Only (PS Domain Test)

The scanner helps in verifying the CPICH levels and Scrambling Codes. The 3G/2G mobile allows to check the 3G/2G mobility and the CS Domain path. The 3G only mobile allows to check the 3G SHO and the PS Domain path.

The drive route has to be long enough to verify the correct handover between the recently swapped site (including intra site SHO) and the close neighbours.

Performance issues need to be analysed.

OUTPUTS:

Site Verification register updated.

7.3. STEP 2 – CLUSTER VERIFICATION

PREREQUISITES:

• STEP 1 has been completed for all the sites within the cluster.

• All the issues opened after STEP 1 are cleared.

• Drive test routes have been identified. These routes are the same control routes of the benchmark. Enlarge the drive routes to include the inter-cluster ones when the cluster to be verified is neighbour of others that have been previously verified.

It is highly recommended to start this step when all the sites of the cluster have been swapped and verified. If for any reason the swap of some sites suffer a delay, it would be possible, in order to not delay the overall schedule, to start the STEP 2 in a cluster not fully swapped. This possibility needs to be carefully studied during the preparation phase depending on the IOT and inter-system constraints. It is advisable to set a minimum percentage of sites needed in order to launch STEP 2 in a cluster. It is recommended to have at least 90% of the sites available.


Nortel confidential


OBJECTIVES:

The objective of this step is to verify that the UMTS performance inside the cluster as a whole is the expected one and that no degradation is observed after the swap.

During this step, the parameter settings and aerials might be optimised to correct issues and improve the observed performance.

Once this phase is finished, the cluster might be ready to pass an acceptance test.

In order to detect and correct quickly any possible issue, only a subset of the proposed services will be initially tested. The acceptance metrics and KPIs will be measured during STEP 3.

TASKS:

The following services are to be tested:

• Scanner 3G/2G

• AMR (Voice) Call – 1mn Mobile 3G/2G (CS Domain Test)

• PS Call – FTP (Download) – 5MB Mobile 3G Only (PS Domain Test)

The scanner helps in verifying the CPICH levels. The 3G/2G mobile allows to check the 3G/2G mobility and the CS Domain path. The 3G only mobile allows to check the 3G SHO and the PS Domain path.

Depending on the detected issues and the optimisation decisions, several drive test runs can be scheduled during this step. If any aerial tuning is performed the engineering team might change any of the services above tested by a 3G Video Call or a HTTP test in order to prepare or advance the next step work.

The following has to be verified:

• Correct interference levels

• Neighbouring plan

• Performance issues need to be analysed.

OUTPUTS:

Optimisation recommendations if needed.

Assessment on the performance quality inside the cluster.


Nortel confidential


7.4. STEP 3 – CLUSTER/AREA/CITY QOS VERIFICATION

PREREQUISITES:

• STEP 2 has been completed for all the cluster involved in the acceptance perimeter.

• All the issues opened after STEP 2 are cleared.

• Drive test routes have been identified. These routes are the same control routes of the benchmark.

OBJECTIVES:

The objective of this step is internally measure the KPIs involved in the acceptance and determine if any further optimisation activity is needed. Once this phase is finished, the cluster has to be ready to pass an acceptance test.

If the obtained performance is aligned with the targets, the optimisation team will launch the acceptance procedure of the swapped cluster or area immediately after (STEP 4).

TASKS:

As in the case of STEP 0, all the contractual performance indicators have to be measured (drive test) or monitored (counters). The list is the one required by the customer. The drive tests configuration and the services tested will be organised accordingly.

Depending on the detected issues and the optimisation decisions, several drive test runs can be scheduled during this step.

Once the process has been proved and enough confidence has been gained on the optimisation decisions, it could be studied to reduce the number of tests during this phase in order to save time and resources. Indeed, the good results in one KPI can guarantee that a related one will be also good.

OUTPUTS:

The final report must show the obtained performance KPIs and give the final decision on whether the area is ready for acceptance.


Nortel confidential


7.5. STEP 4 – FINAL QUALITY BENCHMARK

PREREQUISITES:

STEP 3 has been completed for the area (can involve several clusters) involved in the benchmark.

OBJECTIVES:

The objective of the final benchmark is to compare the obtained KPIs once the swap and optimisation activity are finished against the initial quality reference (STEP 0).

The benchmark can include counter-based and drive-test-based indicators.

In the case of drive test procedures, it is mandatory that the initial benchmark, the final one and all the intermediate verifications are done in 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 before and after swap, it is assumed that, during the swap period, no change has occurred in the core network, transmission network or services platform.

The performance report has to be available at cluster level and use the same formulas and exclusions as specified in the exit criteria.

In this document, we assume that the acceptance is done at cluster level. That means that the number of samples collected during the cluster verification needs to be statistically relevant. This has an impact on the duration of the benchmark for the whole area or city. Also, the volume of the data collected will impact the post-processing capabilities3.

Economies can be achieved if the driving 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 cluster for acceptance, we would need to generate 100 calls in the whole area, instead of 400.

The traces must be available to Nortel teams for analysis and study.

This activity can be outsourced if required by the customer.

TASKS:

All the contractual performance indicators have to be measured (drive test) or monitored (counters). This STEP is the repetition of STEP 0 when all the optimisation tasks are over.

3 The performance comparison before and after the swap is done exclusively using drive tests.


Nortel confidential


8. PLANNING

The following figure provides a typical timeframe of the described activities for a cluster of 30 sites.

M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F

3 6 9 12 15 18 21 24 27 30

Reporting / Exit Meeting

WK # 8WK # 6

OPTIMISATION

30-Sites CLUSTER

HW & SW Changes Verification (if req)

STEP 4 - Final QoS BenchmarkDTRF & Performance Analysis

DTAnalysis & Troubleshooting

Report Generation

HW & SW Changes Implementation (if req)

HW & SW Changes Implementation (if req)HW & SW Changes Verification (if req)

STEP 3 - Cluster QoS Verification

STEP 2 - Cluster VerificationDTAnalysis & Troubleshooting

STEP 1 - Site VerificationDTAnalysis & Troubleshooting

RF & Performance AnalysisReporting

NodeB SWAP (3 per day)

STEP 0 - Initial QoS BenchmarkDT

WK # 5 WK # 7WK # 0 WK # 1 WK # 2 WK # 3 WK # 4

Summarising:

• 2 weeks for the initial quality benchmark (STEP 0).

• 2 weeks for the physical SWAP (3 sites per day).

• 2-3 weeks for STEP 1 – Site Verification

• 1-2 weeks for STEP 2 – Cluster Verification

• 2-3 weeks for STEP 3 – Cluster QoS Verification

• 2 weeks for the final quality benchmark (STEP 4).

Steps 0, 3 and 4 can be shared by several clusters if the acceptance perimeter covers several clusters instead of just one.


Nortel confidential


END OF DOCUMENT

UTRAN Optimisation Process for Swapped Networks v01%2E01

Documents

Transcript of UTRAN Optimisation Process for Swapped Networks v01%2E01