UTRAN Optimisation Process When Introducing HSDPA v01.01

UTRAN Optimisation Process when Introducing HSDPA
Document number: Document issue: Document status: Date: UMT/IRC/APP/019971 01.01 / EN Draft 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.
PUBLICATION HISTORY
18/JUL/2006
Issue 01.01 / EN, Draft Creation
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 2/25
CONTENTS
1. INTRODUCTION .........................................................................................................................3 1.1. 1.2. 1.3. 2. OBJECT .................................................................................................................................3 SCOPE OF THIS DOCUMENT .....................................................................................................3 AUDIENCE FOR THIS DOCUMENT ..............................................................................................3
RELATED DOCUMENTS............................................................................................................3 2.1. 2.2. APPLICABLE DOCUMENTS ........................................................................................................3 REFERENCE DOCUMENTS........................................................................................................3
3.
OVERVIEW .................................................................................................................................3 3.1. QUALITY BENCHMARK.............................................................................................................3
4.
PROJECT PREPARATION.........................................................................................................3 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. RF DESIGN AUDIT WORKSHOPS AND STUDIES...........................................................................3 FEATURES AND PARAMETER ALIGNMENT WORKSHOPS .............................................................3 MONITORING WORKSHOPS .....................................................................................................3 PROJECT PROCESSES ............................................................................................................3 PROJECT DATABASE ..............................................................................................................3 MEASUREMENT AND ACCEPTANCE PROCESS ...........................................................................3
4.6.1 Deviations and Exclusions ............................................................................................3 4.7. PROJECT PLAN .......................................................................................................................3 5. 6. PILOT PHASE.............................................................................................................................3 OPTIMISATION PROCESS ........................................................................................................3 6.1. 6.2. 6.3. 6.4. 7. HSDPA CAPACITY AND RF QUALITY ASSESSMENT...................................................................3 RF OPTIMISATION ..................................................................................................................3 HSDPA TROUBLE SHOOTING AND LOCAL OPTIMISATION ..........................................................3 PERFORMANCE BENCHMARKS .................................................................................................3
PLANNING..................................................................................................................................3
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 3/25
1.
1.1.
INTRODUCTION
OBJECT
This document aims at describing the engineering tasks that are executed before and after the introduction of the HSDPA functionality in a live UMTS network. The optimisation intends to limit or eliminate the impact that the activation of such feature can have on the existing network. The goal is to end up with an UMTS network ready to absorb the future HSDPA traffic controlling the interferences that a WCDMA system working close to a radio load of 100% will generate. As the activity is carried out in a live network, it is assumed that the network to be upgraded has already been optimised and therefore the call performance and the radio coverage and interference are at correct levels. Otherwise, a deeper optimisation activity will need to be scheduled.
1.2.
SCOPE OF THIS DOCUMENT

This document gives a project level view of the different optimisation tasks and provides some examples of the performance indicators that have been used during these activities. As any process, the optimisation one has to be adapted to the requirements imposed by the customer and the different constraints to be managed (environment, budget, resources, time, tools). Thus, this document intends to recommend a way to achieve the best results but it needs to be adapted accordingly specially when the customer impose specific metrics to monitor or report. The intention of this document is not to describe in detail the RF Optimisation process to be applied locally when necessary (as described in chapter 6.2 RF Optimisation). Refer to [A1] for more details on this specific step. The following document concerns sites with outdoor coverage but it could be adapted to the indoor one taking into account some specific 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.
1.3.
AUDIENCE FOR THIS DOCUMENT

Project and Account Teams. Optimisation and Engineering Teams.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 4/25
2.
2.1.
RELATED DOCUMENTS
APPLICABLE DOCUMENTS
[A1] [A2] [A3] UMT/IRC/APP/019972 UMT/IRC/APP/018901 UMT/IRC/APP/018947 UTRAN Optimisation Process HSDPA Introduction Methodology User Guide HSDPA Engineering Handbook
2.2.
REFERENCE DOCUMENTS
[R1] [R2]
UMT/IRC/DD/0011 UMT/IRC/APP/014654
UTRAN Parameters User Guide HSDPA Engineering Guide
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 5/25
3.
OVERVIEW
The objective of the RF optimisation is to control the coverage of the existing cells and reduce the overlaps guaranteeing the service levels and offering a good quality of service for all the users, both R99 and HSDPA. The process is applied in a cluster per cluster basis following the availability of the HSDPA sites after the I&C operation sometimes called HSDPA refresh. This process is applied in a in-service network: OCNS will not be used. The proposed process consists in: 1. Assessment of the impact of the HSDPA activation considering the current and future load and traffic in each cell. 2. Optimisation of the RF coverage of any cell that could interfere once HSDPA is activated. 3. HSDPA activation once the optimisation is finished using the parameter settings driven from the experimentation in the Golden Cluster. 4. Troubleshooting and fine-tuning of any remaining issue at the cluster.
Depending on the project scope, the RF optimisation levels of the network, the HSDPA deployment strategy (shared/dedicated1 frequency) and the customer requirements (set of target KPIs), some of the steps above can be skipped, with the consequent risk associated: HSDPA assessment, can be obviated if the capacity needs related to the activation of HSDPA have already been addressed by the customer and that there is enough confidence on the current RF profile of the network (network well RF optimised). If the network has already correct levels of RF control to deal with HSDPA, the activation of HSDPA will not degrade the R99 users. Therefore, it can be possible to obviate the first steps and go directly to the last one. If there is a requirement to fully drive test the area before the activation of HSDPA (expensive option), it is not necessary to assess the network radio conditions during the HSDPA assessment. Finally, the HSDPA assessment methodology uses data provided by Nortels CTg (Call Tracing). In case of equipment swaps, those data cannot be available except in the case the former supplier had an equivalent feature (Nortels tools might be adapted to other data formats).
If HSDPA traffic is separated from R99 traffic, the HSDPA activation will have little impact on current R99 users. The RF optimisation, while still needed, can have a different priority with regards to the frequency shared scenario.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 6/25

The impact assessment of the introduction of HSDPA is fully described in HSDPA Introduction Methodology User Guide [A2]. This document only provides a highlevel description of this important step and includes it in the overall optimisation project. The assessment can also be proposed as an independent service if no optimisation or benchmarking is required. It is proposed to optimise and determine the HSDPA generic parameters in a Golden Cluster through extensive testing. Those settings are then to be propagated to the entire network. Nortels experience in HSDPA fine tuning in different trial networks will help in determining quickly the good setting for the customer clients (cf. [R1]). The HSDPA Engineering Handbook [A3] provides the necessary keys for the study, the deployment, the optimization, and the monitoring of HSDPA including useful guidelines on parameter tuning. It is assumed that the network to be upgraded to HSDPA 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 project and add risk and pressure during any quality benchmark. The duration of the project can be impacted if an important number of sites need aerial optimisation because a poor RF optimisation.
3.1.
QUALITY BENCHMARK
If the operator intends to verify the quality of the achieved optimisation by comparing the performance obtained by the R99 users before and after the HSDPA refresh, a benchmark campaign can be proposed. The first benchmark (before) is to be done before the start of the RF optimisation (06.2). The second benchmark (after) will be done after the fine tuning of the cluster. In order to ease the process and be able to correctly compare the performance before and after the refresh, the benchmarks need to be done under the same conditions. Therefore, it is important to avoid any site densification or major hardware upgrade in any cluster that is being refreshed 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. The performance assessment before and after the HSDPA introduction or refresh is done through monitored metrics (counter-based and/or drive-test-based) at cell and cluster levels. In some cases, the operator can request Nortel to monitor the refreshed site just after the installation of the new HSDPA hardware (even if HSDPA is not activated just afterwards). The goal is to be sure that the I&C operation has not impacted the UMTS service on the NodeB.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 7/25
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 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 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 confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 8/25

Other items to consider are: Review Nortels HSDPA design assumptions and contrasted them with the customers ones in order to fix a baseline for the RF design review activity. Review the RF design in each region (type of service per area, traffic per service and per area, clutter documentation and definition). 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 Nortels 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. Determine the optimisation clusters and the routes for the optimisation and acceptance drive tests2. 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 operators 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.
Acceptance routes are generally a subset of the optimisation ones. The optimisation routes pretend to cover comprehensively the cluster area.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 9/25
4.2.
FEATURES AND PARAMETER ALIGNMENT WORKSHOPS

Describe Nortels UTRAN features and associated recommended values. Analyse the chosen settings. parameters and
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 operators process in terms of network design and configuration (validation of the changes, publication of the changes, reporting ). Align and homogenise (Configuration Audit). the parameter setting within the network
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.
4.3.
MONITORING WORKSHOPS
Explain Nortels 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 refresh period and during the hours that follow the refresh of each site (worst-cell list).
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 10/25
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 reports 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-thefield 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 operators 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.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 11/25

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 specification). Data Management process (and related database
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. 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.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 12/25
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: 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
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 13/25

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
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 14/25

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
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 15/25
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. During this phase the following is validated: I&C process. HSDPA Optimisation Process. Monitoring Process.
The main objectives of this phase are: Assess the impact of HSDPA introduction with the current network settings Analyse the operators strategy and the capacity bottlenecks. Recommend generic parameter changes on already activated features. Recommend the activation of new features. Optimise and fine tune generic HSDPA parameters to be applied network wide. Identify those parameters that potentially need local optimisation and recommend methodology to get the optimal value. Use the cluster for any advance study during the project. Tune/Improve/Simplify the operational processes. Validate the acceptance protocol and the list of metrics (counter-based and/or drive-test-based) Define a test plan for further testing.
The Pilot size has to be comparable to the typical cluster size used during the HSDPA refresh project. The analysis for the HSDPA assessment includes data coming from: Performance monitoring: CS/PS traffic split, sectors per user, ASET update rate, resources usage (CEM, Code, Power, E1) RF quality (Call Trace): distribution of CPICH Ec/No, RSCP, DL Transmitted Code Power BTS Hardware: sectors, PAs, carriers, E1s, CEMs mix Environment factors: indoor/outdoor coverage, cluster characteristics Parameters audit: CCCH power settings, RRM thresholds and timers, features enabled, power settings, quality target, SHO thresholds
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 16/25

Operators strategy: priorities, resource reservation, mobility strategy (interfreq, 3G2G), features activation plan, mobile mix, HSDPA service definition and applications
6.
OPTIMISATION 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.
6.1.
HSDPA CAPACITY AND RF QUALITY ASSESSMENT

PREREQUISITES
All the preparation steps need to have been completed: processes definition, measurement methodology agreed, RF optimisation process defined, acceptance protocol agreed Clusters have been defined. The HSDPA Introduction assessment is only applicable in areas with enough R99 traffic. Due to the CTg limitations, it is recommended that when working on 2 clusters in parallel, each one belong to a different RNC. CTg and OAM limitations need to be respected. Generic HSDPA parameters will be optimised during at least 5 weeks in a Golden Cluster (at least 1 per region).
OBJECTIVES
The objective of this phase is to estimate the impact of the activation of HSDPA capability in the selected cluster. The characteristics of this functionality make the required analysis to be two-fold:
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 17/25

Assessment of the need to increase the capacity of the BTS to accommodate the HSDPA traffic. Assessment of the impact in terms of radio interference of the users that, by using HSDPA channels, increase the radio load of the cell up to 100%.
Both assessments are needed to grant the successful activation of the HSDPA functionalities network wide. In order to address this important objective, common to all operators, Nortel has developed and built a complete methodology (HSDPA Introduction Methodology User Guide [A2]). This methodology has already been applied in live HSDPA trials. The complete methodology will be explained during the workshops that will precede the operational activities of the HSDPA refresh.
TASKS
Collection of performance and capacity counters (sites of the cluster) Identification of the sites with highest PS traffic and those potentially more impacted by the HSDPA activation. Launch of Call Trace (CTg) on the selected sites in order to collect detailed information regarding the radio performance of the real users on the area. Determine the capacity bottlenecks and areas which need RF Optimisation (polluted or weak covered areas).
Typical recommended cluster size is of around 80 sites. CTg analysis is to be performed in 40-50 sites belonging to each cluster in order to get enough samples and not delay the overall process. Indeed, to have enough statistically significant data, it is recommended to collect at least 6 busy hours do Call Trace per site. IMPORTANT: if the collection of a representative amount of CTg data is not possible (recently swapped UTRAN, Event-Triggering functionality activated ), it is recommended to launch a drive test campaign in order to assess the RF quality of the network. The methodology and results remain the same but the input data is coming from other, more expensive, sources.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 18/25

The overall procedures are shown in the following picture:
Network Data Collection

Parameters Perf monitoring Call Profile RF Quality Features
Current Analysis Codes Power RF Simus CEM Iub RF Quality
Re-Engineering Activities - New Freq - PA addition - Design
R99 & HSDPA Network Optimization
Customer Strategy Call profile Data Subs Forecast services
Forecasted Analysis Codes Power RF Simus UTRAN Dim CEM Iub RF
Re-Optimization Activities - Codes - Power - Neighbours
HSDPA Implementation
The analysis phase, partly executed during the preparation and pilot phases, includes data coming from: Performance monitoring: CS/PS traffic split, sectors per user, ASET update rate, resources usage (CEM, Code, Power, E1) RF quality (Call Trace): distribution of CPICH Ec/No, RSCP, DL Transmitted Code Power BTS Hardware: sectors, PAs, carriers, E1s, CEMs mix Environment factors: indoor/outdoor coverage, cluster characteristics Parameters audit: CCCH power settings, RRM thresholds and timers, features enabled, power settings, quality target, SHO thresholds Operators strategy: priorities, resource reservation, mobility strategy (interfreq, 3G2G), features activation plan, mobile mix, HSDPA service definition and applications
OUTPUTS
List of areas that require RF Optimisation. List of cells that require a specific parameter setting. Recommendations on hardware upgrades considering the current and future HSDPA and R99 traffic.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 19/25
6.2.
RF OPTIMISATION
PREREQUISITES
The areas to optimise have been identified. RF Optimisation process (subset of the generic one provided for roll-out) has been defined.
OBJECTIVES
Thanks to the previous step in the process, it is not necessary to drive and test the whole cluster. Only the areas identified as problematic will be optimised. Otherwise a complete RF survey through drive testing might be necessary. It is necessary to improve the radio coverage of the problematic area as the activation of the HSDPA functionality will increase the radio load of each site. Interference will increase and therefore the performance can be degraded. The objective of the RF optimisation will be to limit the overlap or SHO areas, increase the dominance of single SC and reduce the SPU. This step in the process is specially important and its potential impact higher, when the carrier (frequency) is shared between R99 and HSDPA users. It will be necessary to reach agreements on trade offs associated with this optimisation phase, specially in areas where is required high indoor penetration and the design options are limited.
TASKS
Data for the optimisation decisions will be collected through several runs of drive tests using WDCMA scanners and UMTS mobiles. Aerial optimisation decisions will be backed by simulation studies and agreed with the customer. Call performance will be checked before and after the implementation of the suggested changes. The Nortel standard process for RF optimisation are to be used. The services to be tested will be bound to two.
OUTPUTS
List of changes. Performance report.
Note that all the RF optimisation activities have to have finished before going to the next step in the process. As the next step is the activation of the HSDPA functionality,
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 20/25

if that is done and areas with high interference remain, the performance and quality on those areas will be highly degraded once HSDPA users start using this functionality.
6.3.
HSDPA TROUBLE SHOOTING AND LOCAL OPTIMISATION

PREREQUISITES
RF Optimisation of the cluster is finished The parameter settings, including the HSDPA ones, tested and optimised in the Golden Clusters have been applied. HSDPA is enabled in the cells of the cluster. Note that the order of the above pre-requisites have to be respected.
OBJECTIVES
Once the cluster has been optimised and HSDPA activated, a second round of optimisation is launched in order to: Check the impact of HSDPA users in the areas optimised in the previous step. Check the HSDPA parameters implemented and tune them locally if necessary in order to increase the performance. Detect new weak areas not detected before.
UMTS and HSDPA parameters can be tuned locally at this stage in order to boost the user performance in the area. Any optimisation decision can launch a more detailed study in the Golden Cluster if the potential gain is thought to be important and applicable to the whole network.
TASKS
The HSDPA Engineering Handbook [A3] provides the necessary keys for the study, the deployment, the optimization, and the monitoring of HSDPA including useful guidelines on parameter tuning. Data for the optimisation decisions will be collected through several runs of tests, most of them in static mode, using WDCMA scanners and UMTS and HSDPA mobiles. The focus will be given to the parameter optimisation tasks. However, some aerial optimisation can still be necessary at this stage.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 21/25
OUTPUTS
List of parameters optimised. Update of optimised sites. Performance report.
6.4.
PERFORMANCE BENCHMARKS
PREREQUISITES
The areas to monitor has gone through the previous steps. Stability of the monitored area is granted. Metric formulas and averaging windows have been agreed. It is necessary to assure a permanent access to the Performance Monitoring platforms during all the project.
OBJECTIVES
The monitoring benchmarks are used to compare key metrics before and after the HSDPA refresh in order to be sure that the performances of the current users have been not affected by the activation of that functionality. The impact of HSDPA is higher in single carrier configurations (HSDPA and R99 in a shared frequency) than in dual carrier configurations (except if the network was not enough optimised before the refresh and an important aerial modification campaign was necessary). Aerial changes impact both carriers. The objective of the optimisation campaign is to deliver the best possible network for all the users. Therefore, once the optimisation process is finished, it is expected to improve, in average (at network level), all the metrics. If there is any local degradation of any metric, the performance and optimisation reports will be used to support the decisions made.
TASKS
In order to collect a significant amount of statistics, it is suggested to have a window of two weeks of monitoring before starting the aerial optimisation (step 2 of this process) and after the troubleshooting period (step 3 of this process). A detailed schedule is in chapter 7 Planning. The monitoring metrics to monitor can be counter-based, drive-test-based or a combination of both.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 22/25

It must be noted during the comparison exercise that: The footprint of the cells will change significantly after a RF optimisation campaign that tries to reduce at its minimum the interference levels (traffic will be distributed differently after the optimisation). The mobility parameters could be modified in order to reduce changes of the primary cell. Traffic can be low at certain cells (few samples to monitor). Traffic patterns will be modified with HSDPA or new R99 users.
The above makes specially difficult to compare monitoring metrics at cell level and some margins on the target values must be allowed.
OUTPUTS
Performance report. Further optimisation recommendations.
7.
PLANNING
The following figure provides a typical timeframe of the described activities for a cluster of 80 sites (recommended cluster size). CTg analysis to be performed in 40-50 sites and must respect the CTg and OAM limitations.
1 HSDPA Capacity and Radio Assessment Analysis of Performance Indicators (counters) Identification of High Traffic Areas (Top 40/50 sites) CT Data Collection Post-Processing and Analysis Identification of poorly RF-covered areas > R99 Performance Benchmark #1 (Optional) RF Optimisation (Aerial Tuning) HSDPA ACTIVATION HSDPA Local Optimisation / Troubleshooting > R99 Performance Benchmark #2 (Optional) Reporting
10
11
12
13
14
The process for a single cluster (80 sites) is composed by : 4 weeks of capacity and RF quality assessment 5 weeks of RF optim. We take into account that the first analysis show that between 20 and 50% of the sites need re-optimisation. 2-3 weeks of trouble shooting A final phase of acceptance or benchmark.
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 23/25

The HSDPA Introduction Methodology is only applicable in areas with enough R99 traffic. Generic HSDPA parameters are optimised during at least 5 weeks in a Golden Cluster (at least 1 per region).
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 24/25
END OF DOCUMENT
Nortel confidential
UMT/IRC/APP/019971
01.01 / EN
Draft
18/Jul/2006
Page 25/25

UTRAN Optimisation Process When Introducing HSDPA v01.01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UTRAN Optimisation Process When Introducing HSDPA v01.01

Uploaded by

Copyright:

Available Formats

UTRAN Optimisation Process when Introducing HSDPA

Confidential document - Not to be circulated outside Nortel