Professional Documents
Culture Documents
Document number: Document issue: Document status: Date: UMT/IRC/APP/019972 01.01 / EN Draft 18/Jul/2006
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/019972
01.01 / EN
Draft
18/Jul/2006
Page 2/38
CONTENTS
1. INTRODUCTION .........................................................................................................................4 1.1. 1.2. 1.3. 2. OBJECT .................................................................................................................................4 SCOPE OF THIS DOCUMENT .....................................................................................................4 AUDIENCE FOR THIS DOCUMENT ..............................................................................................4
3.
INTRODUCTION TO THE 3G OPTIMISATION SERVICE ..........................................................5 3.1. 3.2. ROLL OUT SCENARIOS ............................................................................................................6 SERVICE DELIVERABLES .........................................................................................................7
4. 5.
OPTIMISATION PROCESS OVERVIEW ....................................................................................8 PROJECT PREPARATION.......................................................................................................11 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. RF DESIGN AUDIT WORKSHOPS AND STUDIES.........................................................................11 FEATURES AND PARAMETER ALIGNMENT WORKSHOPS ...........................................................15 MONITORING WORKSHOPS ...................................................................................................15 PROJECT PROCESSES ..........................................................................................................16 PROJECT DATABASE ............................................................................................................18 MEASUREMENT AND ACCEPTANCE PROCESS .........................................................................18
5.6.1 Deviations and Exclusions ..........................................................................................21 5.7. PROJECT PLAN .....................................................................................................................22 6. 3G INITIAL OPTIMISATION PROCESS ...................................................................................23 6.1. 6.2. 6.3. 6.4. 7. 8. 9. SITE SHAKEDOWN ................................................................................................................24 CLUSTER OPTIMISATION .......................................................................................................25 NETWORK OPTIMISATION ......................................................................................................29 FINAL PERFORMANCE ACCEPTANCE ......................................................................................30
NETWORK EXTENSION OPTIMISATION ................................................................................31 NETWORK DENSIFICATION OPTIMISATION.........................................................................32 OPTIMISATION RESOURCES .................................................................................................33 9.1. 9.2. 9.3. TOOLS.................................................................................................................................33 TEAM SKILLS .......................................................................................................................34 TEAM ORGANISATION ...........................................................................................................35
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 3/38
1.
1.1.
INTRODUCTION
OBJECT
This document describes the procedures that are recommended to follow during the optimisation of a rolled-out UMTS network. The RF Optimisation Service is described from an operational point of view giving extensive hints on the project management main challenges. The contents of this document is derived from the experience of Nortels Core and Regional Engineering teams in large optimisation projects in EMEA.
1.2.
1.3.
2.
2.1.
RELATED DOCUMENTS
APPLICABLE DOCUMENTS
[A1] [A2] [A3] UMT/IRC/APP/019970 UTRAN Optimisation Process for Swapped Networks UMT/IRC/APP/019971 UTRAN Optimisation Process when Introducing HSDPA UMT/IRC/APP/XXXXX Indoor Optimisation and Acceptance Guidelines
2.2.
REFERENCE DOCUMENTS
[R1] UMT/IRC/DD/0011 UTRAN Parameters User Guide
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 4/38
3.
This point is important as the cost and duration of the optimisation activity depends on the number of verifications to be made. For example, the higher the number of services to tests, the higher the number of drive tests to be done.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 5/38
The success of an efficient optimisation process relies on a strong mutual cooperation between multiple parties, ruled by comprehensive SLA (Service Level Agreement). Amongst all of them, the key ones we can list are: As a preliminary step as well as to ensure a proper continuity between the RF Design done by the operator and the optimisation done by Nortel, it is fundamental to have an extensive exchange of information on the different hypothesis and objectives during what we call the Preliminary RF Design Review. This is required as the optimisation contract usually includes performance targets to achieve with penalties associated. Homogeneous delivery of sites within a cluster (standard is that 90% of sites have to be integrated before the optimisation starts). All the sites using WCDMA technology share the same frequency. It is not possible to assess realistically the levels of interference and coverage in a cluster if there are missing sites (delayed sites). Fast implementation of antenna changes (even more critical when RETA system is not available), typically within 2-3 working days. Fast implementation of parameter changes (neighbours ), typically within the day which implies having a specific resource integrated within the optimisation team.
3.1.
Network Extension and Network Densification optimisation scenarios can be considered as special cases of a generic Greenfield Network optimisation process. This document will illustrate the latest and will specify the Extension and Densification process particularities wherever required.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 6/38
3.2.
SERVICE DELIVERABLES
Nortel can propose two options for the RF Optimisation of UMTS networks with two different sets of protocol tests and associated KPIs: Optimisation Level 1: o o RF Optimisation report Three protocol tests with 6 KPIs : minimise tests & speedup network rollout.
Optimisation level 2: o o RF Optimisation report Seven protocol tests with 15 KPIs : strategic areas or important cities.
In the Network Extension scenario, the sites were being added in an area where there is no traffic (coverage).
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 7/38
Optimisation deliverables RF Optimisation report with Drive test coverage maps including Radio quality measurements Ec/Io & RSCP Quality of Services - KPIs PROTOCOL TEST KPIs Associated Test area success rate Retainability CS long call voice BLER DL & UL CS/PS short call success rate Accessibility success rate CS HHO HHO 3G-2G Mobility success rate PS HHO Service video success rate CSD (video call) call BLER DL & UL success rate PS 128 or 384 UL Service PS UL Throughput success rate PS 384 DL Service PS DL Throughput Throughput - function of CQI HSDPA DL Service HSDPA success rate Optimisation Report
Optimisation Level 1
4.
UMT/IRC/APP/019972
Optimisation Level 2
01.01 / EN
Draft
18/Jul/2006
Page 8/38
In this phase, specially important is to perform a detailed and comprehensive audit of the radio design: chapter 5.1 RF Design Audit workshops and studies.
SITE SHAKEDOWN
Before the performance optimisation process can actually begin, network testing at node level and inter-working with Core network must have progressed to the point that basic call routing (voice and data) has been validated (i.e. local calls can be completed). Shakedown tests are done to verify the basic functionality of the RNS, rather than performance. Transmit power, scrambling code allocation and basic call processing functions are tested on a per-sector basis. Shakedown tests are completed when correct codes are set up, power levels are measured, basic call setup and softer handoffs are successfully executed during drive tests around the site. Once all the sites belonging to the cluster have passed the shakedown test, the RF optimisation can begin. Note that in some cases, all or some the tests associated with the shakedown can be done by the I&C teams during the site commissioning and integration.
CLUSTER OPTIMISATION
Cluster optimisation provides the first pass of optimisation and will adjust settings for parameters, antenna tilts and antenna orientations where required. The recommended cluster size is around 20 up to 40 sites to make faster the optimisation with regards to the roll-out activities. The system performance metrics are calculated for the cluster when basing the acceptance at Cluster network level, in this case the Network Optimisation phase would not occur. Simulated load (OCNS) can be used during some phases of the optimisation process to assess the RF conditions that the user will observe when the network carries traffic.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 9/38
NETWORK OPTIMISATION
The objective of Network optimisation is to optimise the sum of all neighbour clusters (inter-cluster areas would be optimised at this stage) covering an entire region of just deployed and optimised clusters but not yet accepted. This phase can starts with two optimised clusters and ends with all the clusters in the region optimised. This stage could be required when basing the acceptance at an area level instead of cluster level. The entire region is fine-tuned with remaining and new issues resolved. In addition, action plans for future work are defined. The system performance metrics are calculated for the entire region to base network acceptance
NETWORK ACCEPTANCE
Phase dictated for Acceptance data reporting purposes and cluster/area acceptance meetings with the customer. The contractual requirements are verified, the deliverables transferred and the acceptance certificate signed-off (invoicing launched). As we are considering that the operations are done in an area without UMTS subscribers, the optimisation objectives in terms of performance are measured with drive-test-based indicators (KPIs). In the case of an Extension some counter-based objectives can be added in the boundary zone. The scope of the acceptance phase can be limited to the cluster or to a larger area. Refer to chapter 5.6 Measurement and Acceptance Process for more details on this step.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 10/38
5.
PROJECT PREPARATION
As in any complex project, the preparation phase is key for the success and the efficiency of the work to be done by the on-the-field teams. The following chapter aims at describing some important steps that need to be addressed in order to prepare the optimization activity. Obviously, the extent and contents of each of the following workshops and project processes will depend on the customer quality requirements and the operational tasks that need to be executed. Indeed, if the process only requires performance monitoring at counter level or if there is no budgeted antenna optimisation, there is no need to define the drive testing processes or the protocol to deal with antenna sub-contractors. Each one of the outcomes, processes and agreements that follow each any workshop and preparation work must be correctly documented. The following workshops need to be held before starting any operational activity. These steps should be part of the overall project plan and be planned appropriately in advance of the operational activities. This phase of the project will help in creating the project processes (aligning them with the customer needs and constraints) and in defining the detailed project plan. The ultimate objective is to diminish the project risks.
5.1.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 11/38
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/019972
01.01 / EN
Draft
18/Jul/2006
Page 12/38
CLUSTER DEFINITION
The cluster definition rules are specific for each one of the network deployment scenarios. The definitions of the cluster borders will be done based on cluster predictions applying design thresholds, topology information and customer feedback. A cluster has to be coherent from a RF coverage point of view. The drive test routes for performance acceptance will be defined inside each one of the cluster when the acceptance is done at cluster level. Network Rollout Cluster Geographical area covering not-optimised sites without any radio interactions or dependencies with other live clusters (carrying live traffic). A cluster has a reference number of 20 to 40 sites, customisable on cluster specificities. Network Extension Cluster Geographical area covering not-optimised sites with radio interactions or dependencies with live clusters (carrying live traffic). It must include the first tier of sites around the new sites, and eventually other existing sites which influence area is potentially impacted by the new sites. Network Densification Cluster Or Site-Cluster is to be defined by the influence area of the new site/s to be deployed, and considering the neighbour live sites service areas. It must include the first tier of sites around the new sites, and eventually other existing sites which influence area is potentially impacted by the new sites.
DRIVE ROUTES
The optimisation routes for drive testing intend to cover a representative section of the cluster and include: main thoroughfares: primary and secondary roads areas of particular interest: hot spots all areas of overlap between all inward-facing sectors in the cluster if the acceptance is done at cluster level, the routes shall include the overlap areas with already-optimised and accepted clusters.
Bad covered areas should be excluded from the drive routes. Some exceptions can be accepted if it is requested to validate 3G-2G continuity but, in general, it is preferable to dedicate specific tests to 3G-2G and focus the teams in maximising 3G-only coverage.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 13/38
Acceptance or control routes will be used for demonstrating system performance on an individual cluster basis and on a system wide basis. These routes are used, primarily for performance progress monitoring and should reflect typical network performance, and finally for cluster acceptance purposes. The control routes should be a subset of the optimisation routes and should require no more than 3 hours of driving for a 20 site cluster. When possible, control routes should be chosen to be contiguous with those from neighbouring clusters. Control routes are extended as each cluster is exited.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 14/38
5.2.
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.
5.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. Recommend reporting and supervision methodology during the hours that follow the integration of each site (worst-cell list). Specially in the Densification and Extension scenarios. Define carefully the metrics used during the quality benchmarks including the averaging procedures and the minimum sample size to make them significant. Call Tracing capabilities must be fully dedicated to the optimisation team. The limitations of that feature must be known and respected. Alarm management and troubleshooting must be guaranteed during the optimisation process. Access to cell Performance Management server has to be guaranteed during the whole duration of the project. Determine the hand-over of the supervision responsibility between Nortel and the operator once each site has been swapped / integrated / optimised / accepted.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 15/38
5.4.
PROJECT PROCESSES
The processes associated with the optimisation project need to be agreed by all stakeholders: customer, engineering, partners, project management. They need to be clearly defined and accepted before starting any operation in the network once the contract has been granted. The process description should include: working templates, accountabilities (escalation / approval), service levels to be respected, reporting metrics (both internal to the project and external to the customer) and the description of the contractual deliverables. If confidential information is exchanged with the customer and between partners and subcontractors, it is mandatory to sign Non Disclosure Agreements (NDA) with all the involved parties. The sign-off reports (deliverables) for each step of the project phases need to contain enough relevant information without impacting the project progress. The 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/019972
01.01 / EN
Draft
18/Jul/2006
Page 16/38
Optimisation Equipment Management Process (and related database specification). Optimisation Training and Quality Process (of the team involved in the optimisation project). Measurement and Acceptance Process (cf. chapter 5.6 below for details).
The optimisation teams need to be aware and eventually provide feedback on the site Integration and Commissioning (I&C) Process. The nature and results of the tests performed by the commissioners are of vital importance to assess the readiness of the site to become part of an to-optimise-ready cluster. In addition, the management of the RF configuration parameters at the NOC (Network Operations Center), when the site is brought into the live network, is vital to feed the optimisation databases and plan the steps that precede the live testing: neighbouring relationships, frequencies in use, service templates, alarm status It is advisable to think in the office constraints the project team will require: office footprint, desks, PCs, networking, IT support Indeed, big optimisation projects can need a large headcount which needs to be served accordingly. Finally, it is likely that, by the final phases of the optimisation project, the customer requires knowledge transfer sessions (KTS) including formal or informal (on-the-job) training (OJT). That training can cover both technical and procedural topics. Therefore, it is important to plan those activities accordingly and agree on their scope and duration in advance.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 17/38
5.5.
PROJECT DATABASE
It is mandatory for a correct follow up of all the operations to have a common and unique project information system (Project Database) which should include, among other information: Site configuration. Site issues. Updated operations plan. Implemented/Planed Changes. Metrics: performance KPI, downtimes, workload, delays, escalated issues Work Orders and implementation delays. Reporting templates. Equipment tracking.
5.6.
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 18/38
In order to better control the tests conditions, it is desirable to perform all the drive tests (during optimisation and acceptance phases) being the new sites barred for operator use (the optimisation team will use specific SIM cards). The acceptance methodology is a key document that needs to be studied carefully and that will define the final contractual deliverable and influence the whole optimisation and verification steps. The exit criteria has to be defined properly and in very detailed manner including all the exclusions allowed. The number of test protocols and services to report may be different depending on the verifications needed before a commercial launch and/or on the level of optimisation detail that the operator wants to achieve (fine tuning of complex features). However, the goodness of a radio optimisation work can be demonstrated with a reduced set of reported Key Performance Indicators (KPI). Indeed, when the goodness of the RF layer (interference control, coverage enhancement, neighbouring plan) is demonstrated with one service (and eventually a WCDMA scanner) and the feature parameter tuning has been properly studied in a golden cluster, chances are that any additional service to test will pass the performance criteria. It is important to find the good trade off between optimisation effectiveness, cost and customer satisfaction (assuring him that the optimisation done is the best we could deliver). The scope of the acceptance phase can be limited to the cluster or to a larger area: Acceptance at Cluster Level: As soon as a cluster is optimised, passing through site shakedown and cluster optimisation phases (considering the areas of inter-cluster borders and the clearance of major issues) triggers the acceptance phase for the cluster. The number of samples collected during the cluster optimisation (last drive on the acceptance routes) needs to be statistically relevant for acceptance purposes. Acceptance at an Area or Region Level: Within an area or region covering more than one cluster without any live neighbour cluster (carrying traffic), as soon the Network Optimisation phase has been completed, it will be available for acceptance purposes. The recommend maximum number of sites to be accepted simultaneously is 100 sites (area with 4 to 5 typical clusters), mainly due to possible time constraints limitations.
Economies can be achieved if the driving routes (acceptance routes) cover several clusters (typical cluster size equals 20 to 40 sites). That is, if 100 calls is the minimum statistically valid sample size to calculate one KPI, and if we need to benchmark each one of the clusters, we will need to generate 100 calls per cluster. If we group 4 clusters for acceptance, we would need to generate 100 calls in the whole area, instead of 400. Concerning the target KPIs, when the acceptance tests are performed in larger areas, the effects of poor performance in some places due to design constraints is balanced with excellent performance in other areas. The average value of the performance indicator is compensated. That is not possible when the acceptance is to be done in
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 19/38
The acceptance methodology will probably need to include ways to manage the acceptance of a not fully optimised cluster (exclusions to be defined during the benchmark) and the acceptance of a late-site (need of a light procedure). The KPI measurement methodology has to be very clearly described: The KPIs need to be calculated using the information available in the collected traces: use only objective formulas and avoid difficult post-processing. Determine the minimum number of samples (minimum number of hours driven and calls performed) and how the averaging must be performed (at cluster and city levels). The results need to have enough statistical value. Bound the accountability to the areas of the network controlled by Nortel. Include exception management when the team faces issues with the mobiles or the Core Network. Clearly take into account the coverage-related exclusion zones and define the methods to not count the samples recorded in those zones.
If testing under simulated load or simulated indoor conditions is requested, it would be necessary to determine the precise configuration of the whole measurement chain (including attenuators). If the data collection activity is outsourced, it is important to be able to recover the reports and traces and be able to post-process them with Nortel tools. It is important to verify the format needs both of the optimisation teams and the support teams (GPS). If any comparative performance benchmark is necessary during the optimisation process (feature analysis, equipment upgrade, equipment swap), in order to fairly compare results, it is mandatory to perform all the measurement campaigns on the same routes, with the same equipment (mobile, car, antenna, radio chain, server) and the same post-processing tools. In order to be able to compare correctly the performance within each one of the optimisation phases, it is assumed that no change occurs in the core network, transmission network or services platform. Should the customer decide to perform any changes or modifications on those nodes, Nortel would expect to be made aware and commonly re-examine with her the potential impacts on the overall methodology and targets.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 20/38
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.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 21/38
5.7.
PROJECT PLAN
Preliminary project plan will be finalised once all the processes, KPI definitions, exit criteria and communication channels have been discussed and agreed. The following aspects should be covered: Phases Activities Timelines Interdependencies
The project plan has to include details on the resource plan (headcount, skills) and indicate when those resources are available to the project. All the necessary software (tools, databases,) and hardware (mobiles, scanners, PCs, cars, desks ) elements that are needed by the optimisation team must be identified and available before starting the optimisation phases. The logistics has to be managed. All the resources, both human and material, must be on site at the planned moment. The following figure shows a typical optimisation planning for a city of 180 sites based on a several project assumptions (which may largely differ between different projects):
Co mmisionned sites Cu mul of sites avail able Local preparation 10 10 10 20 5 25 5 30 20 50 20 70 20 10 15 15 15 15 10 10 10 90 100 115 13 0 1 45 160 170 180 190 190 190 190 190 190 Cell shakedown System optim + Radi o performance
Cluste r # optim
Cl uster # optim Cl uster # optim Cluster # opti m C l uster # optim Cluster # optim Cluster # op tim Cluster # optim Cluster # o ptim Clu ster # optim
1 1
1 1
2 2
2 1 3
1 2 1 5
2 3 1 8
2 3 1 8
2 3 1 8
3 4 1 11
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
4 5 1 14
2 4 1 9
2 3 1 8
2 2 1 7
2 2 1 7
2 2 6
1 1 3
1 1 3
The following chart shows the ramp-up and ramp-down in a monthly scale of the headcount of a large optimization project (per type of resource):
120
100
80
Head Count
60
40
20
0 1 2 3 4 5 6 Mont h 7 8 9 10 11
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 22/38
6.
Configuration Audit : Entrance Criteria Predicted RF coverage area Noise Floor Measurements Antenna Sweeps Site parameters (carrier(s), codes, configuration ... full datafill) Complete Integration
Configuration Audit : Exit Criteria Set of documents containing results of all preset actions. Set of documents giving the final state (configuration, parameter set, parameter values)
Shakedown : Exit Criteria Sector tests completed (could include calls and handoffs) Carrier(s) checked Codes checked Power levels checked
Cluster Optimization : Exit Criteria Provide report on control route complying with agreed metrics. ( upon customer request) Provide issue list
Network System Optimization Optimization : Entrance Criteria Each cluster must exit cluster optimization
: System Optimization Network Optimization Complete drive-tests Collect system-wide metrics and statistics Address issues in the issue list
System Optimization Network Optimization : Exit Criteria Provide report on control route complying with agreed metrics Provide optional reports on optimization. ( upon customer request)
System Acceptance Network Acceptance The client and Nortel Networks sign off on the acceptance of the system
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 23/38
6.1.
SITE SHAKEDOWN
The shakedown is the last check after integration and prior to optimisation to detect any residual issues such as cross feeder or errors in the site. It is performed on site by site basis and any issues shall be corrected. Note that in some cases, the site shakedown is performed during the integration of the site by I&C teams. Whenever possible, and in order to better isolate the site from the neighbouring ones, it is recommended to perform the Shakedown in a dedicated frequency (the I&C one for example) and with only the intra-site neighbours in the list (to avoid Soft HO with other sites).
ENTRANCE CRITERIA
Integration tests must be passed and accepted. Integration tests are used to show construction completion and basic network readiness.
TASKS
The transmission and reception cabling have to be double-checked based on the drive tests data: UE transmitted power is analysed to check possible reception cabling problems. Ec/Io and RSCP are analysed to check possible transmission cabling problems. Scrambling Codes are analysed to determine if all antennas are pointing to the right directions and that there is no cross-feeder.
If an antenna is found to be incorrectly installed, then a work order will have to be issued as soon as possible to fix the problem. The RF Design audit performed during the project preparation phase can be used as an input to determine specific routes or highlight special constraints in the shakedown report. Drive tests must be performed by driving in circular routes around the base station. These drive routes for shakedowns are defined as circles around the cell at approximately 30 percent of the expected cell coverage area. In addition, the drive tests test the call setup of CS and PS services in each cell and the goodness of the handoffs (softer) between cells in the site. During this phase, a specific configuration audit at site level can be done in order to verify specific node-B level parameters: feeder loss, initial neighbouring
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 24/38
EXIT CRITERIA
Site testing is completed when correct code and reasonable power levels are measured and softer handoffs are successfully executed. Calls on both domains (Circuit Switched and Packet Switched) must have been completed successfully on the site. There should be no issue list after shakedown tests. If issues are remaining, the warranty area might be revised before starting the next phase. Agreed deliverables and reporting finished.
6.2.
CLUSTER OPTIMISATION
The objectives of the cluster optimisation are: Perform RF design verification, Identify, categorise and correct RF control, network or coverage issues. Optimise for best performance according to the acceptance criteria, Serve as a first pass of problem resolution.
During the last stages of the cluster optimisation, samples of the acceptance performance data have to be collected in order to verify the readiness of the cluster for the network optimisation phase (if existing more than one cluster) and final performance acceptance data collection stages. Areas not meeting targeted performance must be included in the issue list.
ENTRANCE CRITERIA
Each of the following criteria must be met prior to starting optimisation on each cluster: Shakedown tests must have been successfully completed on all cell sites in the cluster. The sites not available (not yet deployed or without I&C) at the cluster optimisation phase will not be considered for optimisation and acceptance purposes. This occurrence would trigger an exclusion within the acceptance process. These sites (Late arrival sites) will be managed (optimised) later following the Network Densification process. However, the RF footprint of the missing site has to be taken into account when deciding to optimise the aerial configuration in the area supposedly covered by that site. That is why it is better to get the highest amount of sites integrated before starting the cluster optimisation. Ideally, the cluster must not have any UMTS mobiles operating other than those by the team performing the optimisation (i.e. controlled environment). The Network Extension and Network Densification processes will differ on this.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 25/38
TASKS
The optimisation process is divided in a set of iterative drive tests which will produce inputs for the following analysis: RF Coverage Control, primarily based on Scanner traces Neighbour list tuning (3G to 3G and 3G to 2G) Performance assessments
Raw data files from the drive tests shall be brought back to a central location for processing and analysis by the optimisation engineers. Drive test data may also be merged with UMTS RNC diagnostic call trace logs for further analyses. The optimisation engineers will identify areas where optimisation goals are not met, produce and submit recommendations for changes and classify and analyse the observed problems. Typical issues found at this stage are: RF Coverage Control requirements o o o o Low RSCP (i.e. coverage goals not achieved). Low CPICH_Ec/Io (when RSCP complies with coverage targets). Lack of Scrambling Code dominance Overshooting.
High Active Set Size (i.e. RSCP and CPICH_Ec/Io comply with target but active set size >= 4 within a specified window of X dB from the best server) 3G and 2G neighbouring lists incomplete. Failures at the accessibility and retainability domains will be tracked and followed-up. UE and Network issues are to be identified and documented.
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 26/38
If it is necessary to change an antenna tilt or azimuth, the impact of the suggested change has to be analysed using with RF simulation tools (as in the RF design) and validated with the customer (cell planner responsible of the area).
Recommended physical changes will be included in the optimisation report even if they are not feasible within the timelines of the project. Some changes such as raising or lowering of antennas may not be feasible or cost-effective means of making the necessary changes to coverage. In such cases, the merits of less costly alternatives, such as reduction of pilot power, or antenna swap-outs must be assessed. In this case, deviations in performance shall be considered. Inter-cluster optimisation can be carried out at this stage when working on clusters which neighbouring clusters have already been optimised (the drive tests routes can be extended to cover the inter-cluster areas). This is particularly necessary when the acceptance of the optimisation service is done at cluster level/ If neighbouring clusters are not yet accepted, the acceptance may be defined to be performed at area or region level, gathering more that one cluster, and implying to pass through the Network Optimisation phase.
TEST DRIVES
Iterations of the drive tests have to be planned to improve the network; these iterations are necessary mainly due to the dynamic aspect of the WCDMA technology. Cluster optimisation therefore involves performing different test drives. The optimisation engineers shall use their judgment in deciding whether or not all test drives are required and how often and in what order each test drive needs to be performed. In the same spirit, several hereafter proposed drive tests can be grouped in the same run. The services tested with the mobile during the tests are to be defined taking into account the performance objectives. CS and PS domain calls can be done simultaneously during each one of the drives using two mobiles in parallel.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 27/38
Routes: Optimization routes. Purpose: Determine the actual pilot coverage for each cluster and solve the main RF propagation issues (pilot shoot-up, pilot pollution, scrambling Pilot code overlap...) Optimisation Equipment: Pilot scanner. Drive Data collected: SC, Per-PCPICH coverage; Best PCPICH coverage; 2nd, rd th 3 , 4 CPICH coverage; Number of PCPICH over a given EC/N0, 2G data.. Routes: Optimisation routes. Purpose: Ensure the RF coverage control and RF optimisation (antenna Radio azimuths, tilts, power settings, neighbour list tuning). Optimisation Mobile mode: Connected, long duration calls originated from test mobiles. Drive Data collected: EC/N0, Mobile transmitted power, average number of radio links, number of dropped calls, throughput, setup access rate and time ... Routes: Optimisation routes. Purpose: Check and fine-tune the optimisation results after modifications. Fine Tuning Mobile mode: Connected, long duration call originated from test mobiles. Drive Data collected: EC/N0, Mobile transmitted power, average number of radio links, number of dropped calls, throughput, setup access rate and time ...
DL load can be simulated using Nortels OCNS feature. UL load can be simulated adding extra attenuation on the transmission path of the handset.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 28/38
Routes: Control routes. Purpose: Do the final check and collect acceptance measurement for this Final Cluster cluster. Check Drive Mobile mode: Connected, long and short duration call originated from test mobiles. Data collected: Acceptance performance metrics.
EXIT CRITERIA
If the acceptance of the optimisation service is done at cluster level, the exit criteria of this phase can only be the achievement of the contractual performance targets. If some optimisation actions are still pending on the cluster, it can be agreed to perform the acceptance tests at a larger area scale (group of clusters) up to a maximum of around 100 sites per area. If the acceptance at a larger scale has been decided, the calculated system performance metrics at the cluster must be close enough to the agreed thresholds in order to exit this stage.
6.3.
NETWORK OPTIMISATION
When the acceptance is performed at area or region level, the objective of this step is to finalise the optimisation of the sum of all clusters covering an entire region, specially the inter-cluster areas which have remained without proper analysis and areas where new sites have been added after the cluster optimisation phase. The network optimisation starts with two optimised clusters and ends with all the clusters in the region. The entire region is fine-tuned with remaining and new issues resolved. Action plans for future work are defined.
ENTRANCE CRITERIA
All clusters to be optimised must have met the cluster exit criteria with mutually agreed issue list.
TASKS
Network optimisation is typically performed on the control routes. However, additional optimisation drive test routes may be defined for diagnostic testing of new problematic areas identified as a result of new sites being switched on. Drive tests are primarily focused on the verification of end-to-end and acceptance metrics. They should serve to perform the final fine-tuning of the network settings and to collect statistics for the final acceptance report
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 29/38
EXIT CRITERIA
In order to exit each region, the system performance metrics must meet the threshold requirements.
6.4.
At this stage, the customer can request a verification of the work done and the results obtained before triggering the invoicing and signing off of the service. This last verification can be done during the Final Performance Acceptance stage which should be planned accordingly.
DL load can be simulated using Nortels OCNS feature. UL load can be simulated adding extra attenuation on the transmission path of the handset.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 30/38
7.
Therefore, the optimisation activities have to minimise the impact to the live network (subscribers quality of service) in the border areas. This means that where the cluster to optimise interacts with the live area: Simulated load (OCNS) should not be applied. Special care has to be put in the optimisation choices as the real traffic load has to be considered. Operations have to be executed with special cleanness and speed. It is likely that some operations in particular sites will only be allowed during low traffic hours (night, week-ends) identified by the operator.
The sites at the border are therefore treated in the same way as the ones deployed in the Network Densification scenario. The sites that are not in the border of the cluster and those that belong to clusters without boundaries with the live network are treated as the ones deployed in the Greenfield Network scenario. Generally, the network boundaries carry low traffic and the interaction with new areas is low but that verification needs to be done. The new sites can be optimised with the cells barred (only allowed traffic is the operators one) and, when possible, working in a frequency different to the one of the live traffic. If sites carrying live traffic need to be optimised, the operation needs to be planned carefully and the monitoring teams informed as the traffic profiles of the site will probably be modified after the change. Acceptance of the new sites would be based on drive test KPIs. However, it is usual to define counter-based performance indicators that need to be maintained in the live sites of the boundary areas. This can be discussed during the Monitoring Workshops
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 31/38
8.
Some particularities of the optimisation process need to be taken into consideration in this scenario: Site is delivered to the optimisation team with all cells locked, then unlocked just before the site shakedown start. The cells should also be barred (only allowed traffic is the operators one). Site shakedown is performed at a time window where the traffic is low (usually from late in the evening until early in the morning). First site checks are performed on the spot and green light for first optimisation run is given. If faults are detected during shakedown, the site should be locked back immediately as it will likely degrade the subscribers quality of service. First drive test run is performed just after green light is given (could be performed in the same night just after a successful shakedown). Drive test routes should be designed with the help of simulation tools and should allow to assess how far the site coverage goes (radial routes to identify
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 32/38
The above recommendations consider that only one WCDMA frequency is available in the area. If the integration and optimisation teams can use a dedicated frequency (different from the one used by live traffic), the site integration and the initial optimisation activities can be carried out on it. In this way, those activities will not impact the current subscribers and the current network and could then be scheduled during the day. An special care has to be put in choosing the adequate cell selection and reselection parameters. It is recommended to use this dedicated frequency but be careful if the area to densify is already using two frequencies for traffic. If sites carrying live traffic need to be optimised, the operation needs to be planned carefully and the monitoring teams informed as the traffic profiles of the site will probably be modified after the change. Acceptance of the new sites would be based on drive test KPIs. However, it is usual to define counter-based performance indicators that need to be maintained in the live sites surrounding the new integrated sites. This can be discussed during the Monitoring Workshops in the preparation phase (cf. chapter 5.3). The objective is to demonstrate that no or little impact has been produced in those areas following the integration of new sites. Do not forget to take into account the changes in the RF profile of the area: new sites, new coverage areas, corrected/degraded areas
9.
9.1.
OPTIMISATION RESOURCES
TOOLS
A set of tools are needed to carry out the optimisation objectives: Simulation Tool for RF design: Nortel generally uses Iplanner (Atoll based tool with additional algorithms). Used for aerial changes validation and RF analysis. There must be consistency with the methods used by the customer so it is possible to use their solution if it hast been validated by Nortel teams. Data Acquisition Platform (DAP): currently Couei (XCAL-W) Tests Mobiles: typically Qualcomm TM6250, Nokia 6650, Samsung Z500
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 33/38
9.2.
TEAM SKILLS
The goal of this chapter is to describe the requested skills for key positions on large scale optimisation projects.
RF Optimisation Leader RF Engineering experienced, includes consulting, designing and training. Extensive experience in design and optimisation of GSM/UMTS networks, including Nortels equipment. Extensive experience in continuous monitoring and improving an existing network performance. Experienced training junior RF engineers on design and optimisation techniques.
RF Optimisation Engineer RF Engineering experienced, includes consulting in both RF design and optimisation of UMTS and GSM plus training. Experienced in network optimisation: site verification and cluster optimisation; drive tests of live UMTS network; call troubleshooting analysis; drive surveys analysis; pilot channel RSCP level and interference analysis. Knowledge of UMTS standards.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 34/38
9.3.
TEAM ORGANISATION
In large optimisation projects, the optimisation team is organised in a national or central structure and several regional or local ones. The final team structure depends on the project constraints (size, time, geography) and the own organisation of the customer. The central group assures the coordination, the project management and be the privileged interface with the customer. The main interface between the project team and Nortels Core UMTS organisations will be the Optimisation Manager and the RF and Design Authorities. A pool of End to End experts, linked to the central group, will be also available in order to assure the targets defined in the acceptance document. At regional level, a team of experts is deployed to follow up the activity locally and act as UMTS advisors on any detected issue. They will also ensure the knowledge transfer to the customer regional engineers. The Cell Planning expert will validate together with the customers delegate any change on the RF configuration of the site. The typical accountabilities for each one of the project roles in the regional team are briefly described below:
Optimisation Expert Top optimisation project representative in the region. Responsible for the regional optimisation service. Project Manager of the regional activity. Reports progress to the customer and the central teams. Accountable for the implementation of the optimisation processes and quality standards. Manages the relationship with local subcontractors. Deals with optimisation complex issues and provides advice.
RF Cell Planning Expert Responsible for the RF audit of the regional sites. Provides advice and guidelines during the definition of the optimisation clusters and routes. Validates the optimisation choices in terms of aerial tuning. Coordinates the operational process associated to this activity. Follows up the availability of the sites and reports to roll out teams critical planning deviations. Deals with RF optimisation complex issues and provides advice.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 35/38
OAM (Network Operation Center) A NOC resource must be dedicated to the optimisation activity: is the main contact for the optimisation drive test teams to verify sites availability. Assures the supervision of the sites being optimised. Surveys alarms and assures troubleshooting follow up. Collects RNC traces and counters.
City Optimisation Leader Accountable for the achievement of the performance targets in the city/area. Organises and manages the optimisation teams deployed in the area in order to respect the project plan. Gives the date for the final acceptance tests. Accountable for the for the implementation of the optimisation processes and quality standards in the area. Manages the Golden Cluster activities.
Aerial Tuning Coordinator Coordinates the implementation of the aerial tuning changes. Assures the access to the sites when necessary in coordination with the customer. Follows-up the SLA with the subcontractors and controls the budget associated to this activity.
Optimisation Engineer Responsible of achieving the performance targets in the cluster under his responsibility. Plans the drive testing activities (with the Drive Test Coordinator if there is one) and interacts with the Aerial Tuning Coordinator. Defines the optimisation routes conjointly with the customer and following project directives. Reports optimisation progress and performance indicators. Assures the optimisation data management.
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 36/38
It is common to have a Drive Test Coordinator in projects with large numbers of drive test teams. Her main role would be to distribute the workload of the drive test teams among all the optimisation engineers. The following chart describes the functional structure deployed in a typical large UMTS optimisation project (UR = UMTS Region):
NN
Optimisation Project
R&D
Core Engg E2E expert RF Meas. expert Regional Engg 1rst level support
Region1 N Cities
Region2 N Cities
Region N N Cities
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 37/38
END OF DOCUMENT
Nortel confidential
UMT/IRC/APP/019972
01.01 / EN
Draft
18/Jul/2006
Page 38/38