gsm ran service specification

GSM RAN Optimisation Service Specification

GSM RAN Optimisation Service Specification

GSM RAN Optimisation Service SpecificationMotorola Internal Use OnlyVersion R00.00.073rd November 2003Copyright Motorola 2003Revision HistoryThis document follows the Common Process software version numbering standard to identify the document version. This standard uses the form abb.cc.dd where a is an alpha character and is typically D for a draft release (not to leave Motorola) or R for a released version (reviewed; can be given to the customer). The other fields (bb, cc, and dd) are two digit numeric sequences that indicate the major, minor, and maintenance release numbers respectively. The first R release is always R01.00.00.

VersionDateAuthorComments

D00.00.0119th March 2003Ian EvansInitial draft document

D00.00.0211th April 2003Ian Evans, Moez QayyumRevised after comments from Mark James and Keith Essam

D00.00.0311th June 2003Ian Evans, Moez QayyumNew overview diagram included

D00.00.041st July 2003Ian Evans, Moez QayyumUpdated after first review

D00.00.0531st July 2003Ian Evans, Moez Qayyum, Keith EssamUpdated after second review

R00.00.0622nd AugustKeith EssamInclusion of Frequency planning, Layer management and update of handover section.

R00.00.076th November 2003Tunde WilliamsInclusion of data collection procedures. Updated power control and hardware fault clearance sections based on BPL IDT.

Repository Information

Compass Location http://compass.mot.com/go/132521798 References

[1] Simon Brusch, Kirsty Watts, MV-IOS V1.0 Manual Configuration Parameter Loading, http://compass.mot.com/go/126168666[2] Gavin Simpson, Tubagus Rizal, Motorola GSM Circuit Switched Network Performance Key Metrics, SD/1998/076/NOS, Version 5.4

Table of Contents1Introduction12GSM RAN Optimisation Service Overview22.1Project set-up22.2Network benchmarking32.3Intelligent hardware fault clearance32.4Power control optimisation32.5Intelligent Coverage Optimisation32.6Intelligent neighbour optimisation42.7Layer management optimisation42.8Intelligent frequency planning43Customer Benefits54Delivery Mechanism74.1Delivery Team74.1.1Regional Delivery Team74.1.2Local Delivery Team74.1.3Customer74.2Resource Requirements84.3Multivendor matrix84.4Service Enablers84.5Service Deliverables105Service Phases115.1Pre-service delivery115.1.1Customer Communications115.2Data Collection Procedures155.3Network Benchmarking245.4Intelligent hardware fault clearance255.4.1Statistics/Events/Alarms255.4.2Measurement reports285.5Power control optimisation365.5.1Downlink Power Control Level365.5.2Downlink Power Control Quality375.5.3Uplink Power Control Level385.5.4Uplink power control quality395.6Intelligent Coverage Optimisation405.6.1Unique Cell Coverage Report425.7Intelligent neighbour optimisation15.7.1Neighbour Addition and Deletion15.8Layer management optimisation45.9Intelligent Frequency Planning15.9.1Conventional Uniform Frequency Planning15.9.2Non-uniform Frequency Planning15.9.3Frequency Planning25.9.4Summary36Annexe A16.1.1Handovers1

1. IntroductionGSM network operators have a number of difficult challenges in the current economic climate to ensure continued/increased profitability, e.g. increase revenue per user, and competitive tariff plans. Yet despite these economic conditions operators must continue to strive to achieve best-in-class levels of network performance and Quality of Service (QoS).After the initial network design and deployment which must be carefully undertaken to ensure overall performance and reliability, as the network evolves, it will require constant attention focussed on daily management and operations to keep the many elements involved functioning at optimal levels.Motorola has proved that significant gains can be realised in network quality by moving to direct network measurement based optimisation techniques. Motorolas GSM RAN Optimisation Service uses advanced techniques to harvest measurement reports from actual mobile traffic. Applied statistical techniques provide fast and accurate recommendations to allow adjustment of the important areas of frequency planning, neighbour topology and antenna set-up. Figure 1 shows the improvement possible after 2 cycles of GSM RAN Optimisation Service.It is important that the customer and their engineers are involved in the GSM Optimisation process and understand the technical issues relating to the service (e.g. method of producing the frequency plan and non-uniform frequency plan).

Frequency plan deployedCycle 1Cycle 2Figure 1: Drop call rate improvement after 2 cycles of the GSM RAN Optimisation Service (Total improvement 32%)1 GSM RAN Optimisation Service Overview

Motorola has identified the following optimisation steps that when implemented will lead to a best-in-class network. All steps should be performed although some can be performed more than once.

7 Step ModelIntelligent Neighbour OptimisationIntelligent Frequency PlanningPower Control OptimisationIntelligent Hardware Fault ClearanceLayer Management OptimisationIntelligent Coverage OptimisationNetwork Benchmarking

Figure 2: Seven Steps to GSM RAN Optimisation

It must be noted that all procedures and file formats stipulated in this document pertain to MVIOS version 2.Project set-upBefore the service delivery is commenced the project must be formally set-up. The following must be agreed between Motorola and the customer: The overall objective of the project. The scope of the project, including: Area (BSCs) to be included in the service and the additional area in which changes can be made to improve the service area. Layers and bands. Detailed network information supplied by the customer to Motorola. Customers key performance metrics/success criteria, including values and formulae. High-level list of project deliverables. High-level Gantt chart of project tasks. Key timescales. Key contact/interface people and their responsibilities. Reporting/coordination meetings. Copy of the customers working practices.In addition, the following internal Motorola documents should be produced: Project requirements document. Work breakdown structure. Cost estimate. Schedule. Risk plan. Change management plan. Communication plan reporting and coordination meetings.Network benchmarkingAn experienced Motorola engineer will benchmark the network to gain an understanding of the network. This step should be performed at the start of the service delivery.Network benchmarking is snapshot of network performance based on an examination of statistics, measurements and configuration data collected from the network OMC-Rs, test and measurement equipment and, where appropriate, drive-testing of commercially sensitive cells within the network over a period of approximately one week. Global benchmarking of the network against other, anonymous, recently reviewed networks is also performed.A two-way workshop will be held between Motorola and the customer; the objectives of which will be to: Gain an understanding of the current issues the customer is experiencing. Present the analysis Motorola has produced based on the benchmarking. Agree the working relationships between Motorola and the customer.Intelligent hardware fault clearanceEquipment with hardware problems normally accounts for a significant proportion of the total number of dropped calls/call set-up failures on a network. During this step Motorola will use a combination of software and analytical techniques to identify hardware problems within the network. Replacement of faulty hardware can be undertaken either by existing customer procedures or by Motorola engineers at the customers request.This process will continue (when freeze constraints permit) throughout GSM RAN Optimisation Service.Power control optimisationA Motorola expert will review the power control strategy with the customers experts using the GSM Recommendations 05-08 as a baseline. The parameters will also be reviewed to ensure they are consistently implemented. Measurement report data will also be used to analyse the power control strategy.Motorola will present the results of the review and provide consultancy or implementation support during the changes to the deployed parameters.Intelligent Coverage OptimisationMotorola will analyse data from the network to generate recommendations of cells that would benefit from having antenna tilt or azimuth changes. This will either improve the performance of the cell directly or improve the performance of the surrounding cells. The key activities that will be undertaken are:1. Collection and processing of the measurement reports.1. Analysis and post-processing of measurement report data to produce timing advance data for each cell within the network.1. Analysis and post-processing of measurement report data to produce a list of the worst overlapping coverage cells within the network.1. Analysis and post-processing of measurement report data to produce a list of the cells having the most unique coverage within the network.1. Reviewing the list of cells with experts with local knowledge1. Make a prioritised list of recommendations for antenna tilt and azimuth changes.1. Implementing the recommendations.1. Benchmarking the performance changes both before and after any antenna changes. If antenna changes have taken place, additional neighbour optimisation should take place whether by means of a new neighbour add task or using the data from an intelligent frequency plan collection. The full affects of the antenna changes will not be achieved until a new frequency plan has been deployed. A benchmarking period should follow the completion of the antenna changes so the effect of the changes can be measured.Intelligent neighbour optimisationThe intelligent neighbour optimisation step provides a unique housekeeping service, which will reduce the time and costs involved with traditional processes for neighbour management. The intelligent neighbour optimisation step involves two separate collections of measurement report data, each taking several days. Once the data from the first collection is analysed, the second collection and analysis is conducted. Neighbour deletes The first collection of measurement reports is performed and the data analysed to identify neighbour relationships that are never used or rarely seen by mobiles. These are then recommended for deletion. Neighbour adds A second collection is performed which includes the creation of test neighbours. The data is analysed to identify cells that are reported by a mobile that is not a current neighbour relationship. These are then recommended for addition to the neighbour lists.Using the large dataset generated by the data collections will provide confidence in the recommendations produced by the analysis. In addition, the process can also identify sector problems.The neighbours add analysis task can also be performed using data collected by the intelligent frequency-planning step.Layer management optimisationWhere a network has multiple layers (e.g. GSM900/1800 and/or macro/micro) it is important that the utilisation of all the resources is maximised. A Motorola expert will review the current levels of traffic and the current traffic levelling strategy (e.g. single BCCH for GSM900/1800 networks).A workshop will be held between Motorola and the customer to discuss the current strategy and agree any changes. Intelligent frequency planningMotorola will optimise the frequency plan of the radio network to achieve the maximum improvement in performance. The key activities that will be undertaken are:1. Collection and processing of the subscriber measurement reports.1. Analysis of measurement reports to produce a traffic-weighted carrier to interference matrix. 1. Production of a network frequency plan based upon the traffic-weighted carrier to interference matrixThe benefit of intelligent frequency planning using an accurately measured carrier to interference matrix will significantly increase the network quality and performance.

Customer BenefitsPoor system performance is one of the main reasons why subscribers change networks. Figure 3 illustrates results obtained by Telephia that show that 25% of subscribers cited network performance as the main reason for changing networks.

21%19%11%8%6%6%6%23%Better service prices or phone priceBetter service quality/quality of carriers networkTo get additional product features or servicesTo take advantage of a promotion or saleBetter local calling area coverageThey had particular brand or type of phone I wantedBetter customer serviceOther25% of current customers who changed providersreport switching due to network performance factorsNetwork Performance Factors = 25%

Figure 3: 25% of customer churn is due to network quality/performanceComparing the lost revenue from each ex-customer with the expenditure required to entice and acquire new subscribers, there is a deficit, so that dropped calls and access failures have a direct and negative impact on the finances of the network operator. Booz-Allen & Hamilton have stated in Winning the Customer Churn Battle in the Wireless Industry that a network with 5 million customers will lose $870m a year in revenue.In addition to churn, networks also need to consider: OPEX To ensure that a network is performing to a high standard, thousands of people could be employed to find and correct the faults, etc. If this were the case, expenditure would exceed revenue and eventually the network would go bankrupt.A typical network (2,000 sites) will produce over 27 million statistic values and 60,000 alarms/events every day. These require analysis and the correct adjustments made to the network. Sending an engineer to a site when a site reset would have sufficed is an example of a potential cost saving.Information should be centrally available to allow the efficient analysis of a problem without an analyst having to go to several sources to obtain data.To ensure costs are kept under control efficient processes are required to ensure the network does not use more people than is necessary to keep the network performing. ARPU - The ARPU for a network can be increased with the advent of new services but the perceived failure of services like WAP and GPRS has shown that users do not always take-up what is offered to them.ARPU can also be improved by managing the network correctly. For example: Areas of high revenue can be closely monitored and when a slight drop in call handling performance is detected the root cause may be quickly identified and an adjustment implemented. For areas where the call set-up success rate is poor, if these are identified and corrected the operator should see an increase in traffic/revenue. Identifying and correcting problems should also result in an improvement in the traffic channel mean holding times with a concomitant increase in revenue.Ensuring that users can make calls when they want will see an increase in ARPU. CAPEX With many networks having to add new UMTS infrastructure and expanding beyond their domestic markets, the amount of money available to invest in the existing network is minimal. To maximise the return on this expenditure: Ensure redundant equipment is relocated to sites where it will be used. Ensure overloaded sites are kept to a minimum. Maximise equipment usage whilst avoiding high levels of call failures due to non-availability of call traffic channels.Effective analysis of the network is required to ensure: OPEX is kept low. ARPU is kept high. CHURN is kept low. CAPEX is kept low.The GSM RAN Optimisation Service enables networks to achieve these goals using Motorola services, tools and consultants.

Delivery MechanismAn individual team member may be a member of one or more teams.Delivery TeamThe delivery of the GSM RAN Optimisation Service will be a combined project including the regional delivery team, the local delivery team and the customer.Regional Delivery TeamThe regional delivery team is responsible for: The project management of the service delivery for the first time the service is delivered to a customer. Developing competency in the service. Training local office engineers in the delivery of the service. Providing consultancy to the local office team for subsequent deliveries to the customer. Having the appropriate skill level for each procedural step and knowledge of the equipment involved. Educating the customer about the GSM RAN Optimisation Service method of optimisation and the reasons for network freezes. A defined point of contact for issues.Local Delivery TeamThe local delivery team is responsible for: Acquiring sufficient skills to perform subsequent deliveries of the service Project managing subsequent deliveries of the service. Obtaining the required skill level to perform the service delivery. Interfacing with the customer. Providing local knowledge of the network and environment. Obtaining all data required to run the service delivery successfully. Maintaining a log of additional potential service opportunities identified during the service delivery and promoting these to the customer. Ensuring O&M support is available to collect the required data and implement the recommended/agreed changes. Coordinating the implementation of changes into the customer network. A defined point of contact for issues.CustomerThe customer is responsible for: Reviewing and approving Motorola deliverables in a timely manner. Providing information requested by Motorola in a timely manner. Providing accommodation and utilities for service enabling platforms. Providing network LAN and other appropriate connections. Implementing changes in their network. Providing a copy of their working practices/procedures. A defined point of contact for issues.

Resource RequirementsThis service is a combination of other existing services. The resource requirements are detailed in the respective service specification.Multivendor matrixStepTaskMotorola networkNon-Motorola network

Network benchmarking Network benchmarking

Workshop

Intelligent hardware fault clearanceStatistics/events/alarmsAs available

Measurements reports

Power control optimisationReviewAs available

Workshop

Intelligent Coverage OptimisationOptimising the antennas

Intelligent neighbour optimisationNeighbour delete

Neighbour add

Layer management optimisationReviewAs available

Workshop

Intelligent frequency planningRF planning

Service EnablersThe following services/tools are required as enablers to deliver this service:

StepServices/tools requiredMotorola networkNon-Motorola network

Network benchmarkingMotorola Drive Test Tool (MDTT) (http://www.ecid.cig.mot.com/NSSG/ASA/products/mdtt/mdttnew.htm)

MARS (http://www.ecid.cig.mot.com/NSSG/ASA/products/mars/marsnew.htm)

Metrica or equivalent (http://www.adc.com/software/serviceassurance/portfolio/metricanpr)

Network Performance Review http://compass.mot.com/doc/96230862/Network_Performance_Review_Description.doc

Ascom Qvoice http://www.ascom.com/ecore/WebObjects/ecore.woa/de/showNode/siteNodeID_21191_contentID_-1_languageID_1.html

Intelligent hardware fault clearanceNetwork Health Analyst (NHA) (http://www.cork.cig.mot.com/ia)



Availability Collection Tool (ACT) (http://www.cork.gtss.mot.com/omctst/new_web/ACT/ACT.html)

Cell Optimisation Tool (COP) (http://www.ecid.cig.mot.com/NSSG/ASA/products/cop/copnew.htm)

MV-IOS

CTP-NT

Power control optimisationBSS review (http://compass.mot.com/doc/97484867/BSS_Review_Service_Description.doc)

Datagen

OMC-R

MV-IOS



Intelligent Coverage OptimisationMV-IOS



Intelligent neighbour optimisationMV-IOS



Layer management optimisationASTAT (http://www.ecid.cig.mot.com/NSSG/ASA/products/astat/astatnew.htm)

MV-IOS



Intelligent frequency planningDatagen



MV-IOS

MVIOS AFP procedure (http://compass.mot.com/go/117597056)

Service DeliverablesStepDelivered to the customerInternal Motorola deliverable

Network benchmarking High level BSS benchmarking report Minutes, conclusions and agreements from the workshop Report listing potential sales opportunities identified by the consultants. This document is primarily for the account manager so they can obtain more revenue from the customer. Lessons learnt from implementing step.

Intelligent hardware fault clearance Report of hardware issues identified on the network Minutes, conclusions and agreements from the workshopLessons learnt from implementing step.

Power control optimisation A series of recommended additions/changes to current feature set Minutes, conclusions and agreements from the workshop

Lessons learnt from implementing step.

Intelligent Coverage Optimisation A series of recommendations for changing the set-up of the antennas Minutes, conclusions and agreements from the workshopLessons learnt from implementing step.

Intelligent neighbour list optimisation A series of recommendations for neighbour relationships to be deleted in the network A series of recommendations for neighbour relationships to be added in the networkLessons learnt from implementing step.

Layer management optimisation A series of recommendations for changing parameter to improve traffic management Minutes, conclusions and agreements from the workshopLessons learnt from implementing step.

Intelligent frequency planning A non-uniform frequency plan based on measurement reports Impact of the non-uniform frequency plan on the networkLessons learnt from implementing step.

The customer and Motorola will formally sign off each step once the deliverables have been reviewed, accepted and implemented. On completion of the project Motorola will produce a report detailing the tasks performed and the impact on the network.

Service PhasesPre-service deliveryThe following must be identified and agreed between Motorola and the customer before the service is started: The overall objective of the project. The scope of the project, including: Area (BSCs) to be included in the service and the additional area in which changes can be made to improve the service area. Layers and bands. Detailed network information supplied by the customer to Motorola. Customers key performance metrics/success criteria, including values and formulae. High-level list of tasks. High-level list of project deliverables. High-level Gantt chart of project tasks. Key timescales. Key contact people. Reporting/coordination meetings. Copy of the customers working practices.In addition, the following internal Motorola documents should be produced: Project requirements document. Work breakdown structure. Cost estimate. Schedule. Risk plan. Change management plan. Communication plan reporting and coordination meetings.Customer Communications Prior to the service delivery, the Motorola service delivery team must negotiate with the customer the form and regularity by which critical network configuration will be provided. In order to execute the service, the service delivery team must work with the customer so as to provide the following sets of files:

1. Configuration Files Cell file the format and contents of this file are specified in [1]. This file is commonly named config_cell.csv. Neighbour file the format contents of this file are specified in [1]. This file is commonly named config_neighbour.csv. BA-SACCH file the format and contents of this file are specified in [1]. This file is commonly named config_sacch.csv. Carrier file the format and contents of this file are specified in [1]. This file is commonly named config_carrier.csv.

The above files must be provided at least 24 hours prior to the start of a collection and immediately following the implementation of new test neighbours. The procedure for test neighbour rotation is described in the next section.

2. Site Information Files Site_locations.csv the format and contents of this file are illustrated below.

Example:# Cell ID,BCCH,BSIC,Bore angle,longitude,latitude234-10-5060-10205,51,48,60,-3.609999645,50.44527383234-10-5060-3360,105,27,0,-3.84349784,50.863399

Site Configuration Information.txt - this file simply lists the carriers in each cell that are connected to TMAs or LNAs and also which carriers are connected to combiners. The format of this file is to be defined jointly between the customer and the service delivery team.

The above files must be provided by the customer and the start of the service engagement. 3. Frequency Planning Supplementary Files

Outage.csv this file identifies sites in which . The format and contents of this file are illustrated below.

Example:# BSC,BTS Name,Out of Service Time,Back in Service Time,Duration Borivali_BSC,BHAYENDER,28 Sep 2003 09:18:00,28 Sep 2003 09:30:00,720Thane_BSC,CHARAI,1 Oct 2003 14:15:00,1 Oct 14:35:00,1200

Planning_Cells.txt this file list the cells for which new frequency allocations are required. The format and contents of this file are illustrated below.

Example:# GSM Cell Id234-10-5060-10205234-10-5060-3360

Expansion_Carriers.txt this file provides information relating to the nature of carrier expansions in specific cells. The format and contents of this file are illustrated below. This example shows that one 900 MHz band voice carrier and one 1800 MHz voice carrier will be added to cell 234-10-5060-1025.

Figure 4, Format of the carrier expansion file.

List_of_Cells_with_Cavity_Combiners.txt - The frequency planning tool (CellOpt AFP) must be provided with the list of cells using cavity combiners. In future, it will be possible to specify a list of cells with cavity combiners in a separate file which is then loaded into IOS-NT Analysis. However, until this is implemented, it will be necessary to specify which cells use cavity combiners using the CellOpt user interface. Information about cells with cavity combiners is necessary in order for the CellOpt AFP to produce the correct channel separations.

The above files are only required during the frequency planning phase of the service delivery.

A summary of the external file requirements is provided in Figure 5 below. As the flowchart shows, the external file requirements are very much dependent on the particular phase of the service. For example since Hardware Fault Clearance is a continuous activity throughout the service delivery, there will be a requirement to provide the relevant support files on a daily basis. The specific requirements for each service delivery phase are described in later sections.

Coupled with the network configuration data provided in the 4 pre-requisite CSV files, the customer must provide performance management data on a daily basis. This data will allow the service delivery team to monitor the state of the network and also to identify potential hardware issues. Such hardware issues need to be promptly identified to ensure that the network performs optimally following the introduction of a new frequency plan.

All key performance indicators (KPI) must be obtained at the cell, BSC and network level and on a daily basis. The following KPIs, all of which are stipulated in [2], must be obtained from the customer:

[1] Call Setup Success Rate this is defined as the proportion of mobiles which successfully access a TCH, having requested an appropriate service on accessing the SDCCH.[2] Dropped Call Rate this is defined as the proportion of mobiles which, having successfully accessed the TCH, subsequently suffer an abnormal release, caused by loss of the radio link. This figure is comprised of RF Losses on the TCH plus losses during handover. As mentioned in [2], it must be noted that the calculation at BSC level will only be accurate if MSC supported (i.e. external) directed retry or multiband handovers do not occur. [3] Call Success Rate this is defined as the proportion of calls that set-up successfully and do not suffer an RF loss before user termination or successful hand out. This can be derived directly from the dropped call rate and call success rate e.g. [4] Mean Time Between Drops this is defined as the mean time between dropped calls due to loss of the radio link.[5] Call Volume this is defined as the number of call originations which successfully access a TCH.[6] TCH Traffic Carried this is defined as the traffic carried in Erlangs.[7] TCH Blocking Rate this is defined as proportion of all requests for TCH resources (originations and hand-ins) which fail due to no available TCH resources.[8] SDCCH Blocking Rate this is defined as the proportion of all requests for SDCCH resources (originations and hand-ins) which fail due to no available SDCCH resources.[9] SDCCH Access Success Rate this is defined as the proportion of SDCCH activations which result in a successful mobile access.[10] Incoming Inter-cell Handover Success Rate this is defined the proportion of attempted incoming inter cell handovers (intra BSS and inter BSS) that result in the mobile successfully accessing the target channel.[11] Handover Cause Statistics these should include the proportion of handovers due to all possible handover causes. These should include but not be limited to the following causes:i. Downlink/Uplink Quality ii. Downlink/Uplink Leveliii. Distanceiv. Uplink/Downlink interferencev. Congestion.

Figure 5, External files required for the GSM RAN Optimisation service delivery.

Data Collection Procedures

It is envisaged that user manuals for driving the MVIOS will be available for use by the service delivery team. These manuals will details the procedures for performing measurement report data collections required by the IOS algorithms on which the optimisation service is based. Until these manuals are available, the procedures stipulated in the following sections should be used for performing data collections.

The flowchart, shown in Figure 6, illustrates the process for implementing test neighbour rotations. These rotations are required for the coverage optimisation, neighbour list optimisation and frequency planning phases of the service delivery.

Figure 6, Test neighbour rotation procedure.Generating the XML file

Figure 7 below shows a screenshot of the tool for generating the config.xml file. The tool is provided in the executable, CsvToXml.exe[footnoteRef:1], and is required by the MVIOS system for starting an MR collection. Once this file has been generated it must be stored for use in the subsequent IOS Analysis database loading phase. The loading of the IOS Analysis database is performed automatically via the MVIOS GUI. [1: This executable will be available in the MVIOS version 2 build CD.]

Figure 7, Tool for generating the Config.xml file from the 4 pre-requisite CSV files.

It is important to note that as many config.xml files as collection days must be stored in a known directory. These config.xml files are required by the IOS algorithms and as such must reflect the configuration of the network on the days with which they are associated.

Generating Test Neighbours

With GSM vendors such as Nokia, a maximum of 32 neighbour cells can be supported by each serving cell. Thus, where the BA_SACCH list does not encompass the full range of BCCH frequencies, it will be necessary to include the remaining frequencies as test neighbours. Unlike Motorola equipment, certain vendors do not have explicit mechanisms for configuring test neighbours. For such vendors, a work-around method for including test neighbours is to declare external neighbours with unknown BSICs, unknown cellids and an unknown LACs[footnoteRef:2]. For example, in a recent engagement involving Nokia BSS equipment, test neighbours were assigned 999 for the LAC, and the ARFCN of the BCCH carrier was used as a dummy cellid. In the same engagement, test neighbours were assigned BSIC values which were outside the operators allocated range. [2: Unknown refers to a range which is not used by the operator. For example an unknown BSIC may be within the valid GSM range but not in the range of BSICs used by the operator.]

The tool provided in the executableTestNbrRotation.exe [footnoteRef:3]and depicted in Figure 8, should be used for generating the required vendor specific scripts for adding and removing test neighbours. Specifically, the TestNbrRotation.exe tool provides two separate files which specify the required test neighbour additions and test neighbour deletions for each cell. The format of the files that provide the required information for test neighbour additions and deletions is shown in Figure 10. [3: This executable will be available on the MV-IOS version 2 build CD.]

Figure 8, Screenshot of the test neighbour rotation tool.

Detailed in a separate log file is information relating to the rotation. An example output is shown below.

Figure 9, An example of a log file produced by the test neighbour rotation tool.Importantly, the log file includes information as to which cells were not able to rotate through the necessary test frequencies within the specified collection period. As the flowchart in Figure 6 indicates, the test neighbour rotation tool must be provided with an up-to-date configuration file (config.xml) in order to generate the list of test neighbour additions and deletions required for a subsequent test frequency rotation.

Figure 10, Format for the test neighbour additions and deletions output files.

Loading Collection Data into the IOS Analysis Database

In order to execute the IOS algorithms, MR data and correct configuration information about the network must be loaded into the IOS Analysis database. This section describes the process for loading configuration data into the IOS Analysis database which must be carried out prior to loading the MR data. Figure 11 below, presents a screenshot of the MVIOS user interface which is used to create, start, terminate and load data collections.

Figure 11, MVIOS graphical user interface.

In order to perform a data collection, the service delivery team must first create a collection entity using the MVIOS UI. The process for creating and starting a data collection is depicted in the flowchart show in Figure 12.

A data collection should only be performed during a network freeze since this reduces the likelihood of configuration changes invalidating the recommendations of the service delivery team. Once the duration of the collection has elapsed, the collection must be stopped and collected data loaded into the relevant IOS Analysis database.

There are two aspects to loading collection data: loading configuration data and loading measurement report data. In the proposed collection procedure, configuration data pertaining to each collection day must be loaded into the IOS Analysis database as separate xml files. The procedure for loading these configuration files is illustrated in Figure 13.

Figure 12, Procedure for starting a collection on MVIOS.

Figure 13, Loading configuration data into the IOS Analysis database.

Since the instantaneous configuration of the network during the time that test neighbours are being added or deleted is uncertain, measurement report data extracted during that time period must be discarded by MVIOS. In order to perform this MR discard operation, MVIOS must be provided with the times for which individual configuration xml files are valid. Accordingly, the service delivery team must request from the customer the times in which test neighbours modifications commenced and terminated. The process of modifying configuration end times based on information provided by the customer is illustrated in the Figure below.

Figure 14, Modifying collection end times for a five day collection.

In order to modify the configuration start and end times based on the change times provided by the customer, a series of SQL statements must be executed. Figure 15 below shows an example of the SQL statements that were used for the 5-day collection illustrated in Figure 14. As Figure 15 shows, MVIOS automatically assumes that the end time for the configuration xml file pertaining to the previous day, terminates 1s prior to the start time of subsequent days configuration file.

After the configuration files have been stored in the relevant databases successfully, the MR data can then be loaded. This is performed by simply selecting Load Collected Data which is available as a right-click drop down menu item.

Figure 15, Changing configuration end times using SQL.

Generating Outage Information

MVIOS must be provided with site outage information in order to allow its algorithms to compute the correct penalty values. Specifically, outage information must be obtained in order to execute the coverage overlap and carrier-to-carrier C/I algorithms.

Since Motorolas IOS platform identifies outages at the site level, it may be necessary to associate specific events with site outages in order to generate the required CSV file. It will therefore be necessary for the service delivery team to work closely with the customer in order to determine which alarms and events can be categorised as site outages. For example, in a recent customer engagement, the following events were classified as site outages.

site relocation microwave link toggle microwave failure power fail hard reset RSL toggling soft reset alignment of microwave link LAP-D protocol error

Once the relevant events that refer to site outages have been identified, it is recommended that a script is written to convert an operator generated vendor-specific outage report into an MVIOS compatible site outage report. The format of the outage information is specified in the Customer Communications section of this document.

Network Benchmarking

An experienced Motorola engineer will benchmark the network to gain an understanding of the network. This step should be performed at the start of the service delivery.Network benchmarking is snapshot of network performance based on examination of statistical, and measurement data collected from the network. Where appropriate, additional drive testing of the commercially sensitive cells within the network over a period of approximately one week may be necessary. Global benchmarking of the network against other, anonymous, recently reviewed networks is performed.In order to benchmark the network, the KPIs noted in 5.1.1 should be used. However these may vary depending on the statistics available. It is therefore imperative that a two-way workshop is held between Motorola and the customer; the objectives of which will be to: Gain an understanding of the current issues the customer is experiencing. Present the analysis Motorola has produced based on the benchmarking. Agree the working relationships between Motorola and the customer.

Intelligent hardware fault clearanceHardware optimisation of the network is highly dependent on the network equipment supplier but intelligent hardware fault clearance should be an on-going activity throughout the whole service delivery when conditions permit. There are two main aspects to this specific step: On-going analysis of statistics/events/alarms. Analysis using measurement reports.The following descriptions are generic wherever possible in order to encompass all vendors equipment, but are based on those for Motorola equipment.Statistics/Events/AlarmsA step degradation in a cells KPIs is often symptomatic of a hardware fault. For example, the Figure below shows an example of a sharp degradation in a cells dropped call rate and the effect of replacing jumper cables at the cell site.

Figure 16, Step change in the dropped call rate statistic due to a hardware fault.

The customers key performance indicators should also be analysed, e.g., Dropped call rate. Handover success rate. Mean time between dropped calls, etc.Any step degradations in the KPIs should be investigated and corrected.

If available from the customer, the following should be also be analysed using statistics/events/alarms for each day that the network is monitored: Alarms and events. Carrier level path balance anomalies. Cells with imbalances when comparing individual timeslots. Anomalous changes in traffic levels.

Alarms and EventsDevices with the following characteristics should be identified, the root cause(s) diagnosed and corrective action taken: Alarms generated by degradation in the performance of the device. Repeated minor alarms generated for a particular device Repeated state change events.Path balance Anomalies

Path Balance = uplink path loss downlink path loss + 110Where: Uplink path loss = actual MS Txpower Rxlev_ul (BTS)Downlink path loss = actual BTS Txpower Rxlev_dl (MS)The analysis of carrier-level path balance anomalies requires vendor specific techniques due to the different implementations; therefore the following description may be particular to Motorola equipment. Path balance is calculated from the transmit (Tx) and receive (Rx) levels, using the formula:Figure 17: Formula to calculate the Path Balance

Allowing for normal variations, a properly balanced cell should have a path balance value of ~110 +/- 10, though this figure will need to be adjusted depending on the specific site configuration. Table 51 below provides rule-of-thumb (derived from BPL IDT experience) figures for the path balance offsets introduced by specific site configurations.

Site ConfigurationPath Balance OffsetTarget Path Balance

Single Hybrid Combiner-3dB-3dB

Uplink diversity-3dB-3dB

Tower Mounted Amplifier (TMA)/ Low Noise Amplifier (LNA)-13dB-13dB

Single Hybrid Combiner plus TMA/LNA -16dB-16dB

Uplink diversity with Single Hybrid Combiner plus TMA/LNA-19dB-19dB

Table 51, Typical path balance offsets for different site configurations

An indication of a path balance imbalance is when the value is outside this range, indicating a problem with the power levels. For our purposes it is reasonable to assume that the mobiles are likely to be not responsible, which would leave the BTS Tx power and RxLev requiring investigation.It should be noted that a large differential in mean path balance between different carriers may also be indicative of a hardware problem. As a result of this, the carrier-level path balance statistic for different carriers should be checked for large differentials.Low volumes of traffic can adversely affect the path balance distributions; therefore low traffic periods should be ignored as they could give a misleading indication. Path balance problems are typically caused by hardware issues, i.e., hardware faults or site configuration problems, e.g., obstructed antennae, or incorrectly staged external hybrid combining.External hybrid combining is used in cells requiring more than 6 carriers. Typically Motorola and indeed most if not all other vendors manufacture cabinets that support a maximum of 6 carriers per cell. However, some operators occasionally use up to 8 carriers per cell. To get around the equipment limitation, two cabinets may be aggregate together, but if this is done incorrectly, it may lead to problems with the path balance. Carriers with imbalances when comparing individual timeslotsThis also requires vendor specific analysis; therefore the following applies to how to analyse Motorola equipment only.Timeslot imbalances can be identified by the following statistics: Dropped calls. Bit error rate. Frame erasure rate. Interference on idle.Timeslot imbalance problems could be due to radio equipment issues, poor quality cabling and connections, together with radio interference issues following the introduction of GPRS.TCH RF loss imbalancesTCH RF losses manifest themselves as dropped calls and by comparing the dropped calls on each timeslot for a particular carrier; it is possible to draw inferences regarding possible hardware issues. If a particular timeslot or group of timeslots are prone to significant dropped calls this would be indicative of a radio problem. Any faulty radio equipment that is identified will need to be replaced.Downlink quality (Bit error rate) imbalancesDownlink quality imbalances are manifested in poor audio quality during calls on some or all of the timeslots, and may be identified by a high bit error rate. Improperly functioning timeslots would signify a hardware problem, and the radio equipment would need to be replaced. Uplink quality (Frame erasure rate) imbalancesUplink quality imbalances are manifested by poor audio quality on calls for some or all of the timeslots in a cell. If the problem is identified as a hardware issue, the radio equipment will need to be replaced.Interference on idleWhen a BTS receiver is in an idle state, it will passively listen to and monitor the background noise-level. There are several known IOI-related issues such as: Poor quality RF cabling and connections to the antennae. Poor quality splitters or combining devices. Frequency planning issues, both inter- and intra-network in origin.They manifest themselves with a high level of interference and dropped calls. IOI detected problems are likely to require the radio equipment being recalibrated or even replaced.Abnormal changes in traffic levelsSome hardware problems do not immediately manifest themselves in the form of alarms or event notifications; indeed, there are occasions when the key performance metrics will continue to appear normal. In such cases, unusual changes in the traffic level of a cell from that observed under normal operation may be the only indication of an occurrence: Lightning strike on the antenna causing damage to the antenna and radio equipment. Criminal damage to the site equipment, connectors and/or antenna orientation. Re-orientation of the antenna. General RF maintenance/repair work.Although a direct lightning strike or vandalism may damage the antenna, radio and/or connectors, such an occurrence may not be sufficient to take the site out of service. Instead, the power levels and consequent antenna range may be reduced; and with it the size and traffic of the cell. Re-orientation of the antenna can have the same effect, by changing the footprint traffic characteristics of the cell; the operator may do this deliberately, in which case the changes in traffic levels will be wholly expected. However, if the change results from vandalism or a mistake during routine maintenance, it could go unnoticed. The mean and standard deviation for traffic carried for the day under review for the previous 10 weeks for that day of the week should be calculated for each cell. If the day under review deviates by more than 3 times the standard deviation then a problem should be raised. Further investigations can then be undertaken to identify the root cause and corrective actions carried out.Statistical data interval detectionEach cell should be monitored throughout the day against the customers key performance indicators. This collection interval is necessary to ensure there is sufficient data for the analysis. For instance, analysing just one interval might identify a large number of phantom problems, especially during low traffic periods. Measurement reportsThe following descriptions are generic for all vendors equipment.An intelligent hardware fault clearance data collection should be performed for at least 4 days and the data analysed.The hardware fault analysis produces a set of radio link parameter distributions that are generated from the measurement report information. The resulting distributions may be analysed in one of two ways: Manually reviewed. Automatically by means of ranking and filtering algorithms. The intention of both approaches is the same, i.e., to locate cells that have unusual, skewed, or asymmetric distributions. The latter approach is preferred because of the sheer volume of data that must be analysed.These are then analysed further and a set of possible causes and corrective actions are recommended to the customer. Typical problems that can be identified include poor connections, faulty antennae, unbalanced antenna apertures and incorrect down tilts.Measurement report distributionsThe system generates these reports, which enable the calls from a site, cell, cluster, BSC or OMC to be analysed using distribution analysis. The output is in graphical form, with the following metrics displayed in terms of the distribution of MRs (see Figure 5), with these metrics being grouped either by carrier or by cell.MS powerBTS powerRXLev Power Control (UL)RxLev PowerControl (DL)RxQual (UL)RxLev (DL) Timing advancePath balanceNeighbour marginRxLevNonPC (UL)RxLevNonPC (DL)

Figure 18: Distributions availableMR distributions: Path balanceThe path balance is the difference between the uplink and downlink path losses, and when this is imbalanced, i.e., where there is a significant deviation between these factors, this will manifest itself in the path balance distribution. Imbalance is typically caused by the hardware: Hardware faults and site configuration problems. BTS receive and transmit cable losses. Damaged antennae due to lightning strikes or vandalism. Poor radio calibration. Incorrectly configured external hybrid combining. Incorrectly configured cabinets and antennae following routine maintenance. Obstructed antennae. Hardware configurations Low noise amplifier (LNA) in use on the receive path. Combining on the transmit path. Reception diversity.

Path ImbalancePath imbalances may be the result of problems in the uplink or downlink radio paths. Imbalances are readily identified using the MVIOS systems MR Distributions module. Figure 19 below shows an example of 3 cells with zero path balance, positive path balance and negative path balance respectively.

Figure 19: MR distributions for different path balance issues

As Figure 19 indicates, a positive path balance is symptomatic of a problem in the uplink radio path at the BTS. Conversely, a negative path balance is indicative of a problem in the downlink radio path. As Table 51 indicates, however, particular site configurations may cause a path imbalance. Furthermore, a path imbalance may result in cells requiring more than 6 carriers since external hybrid combining is typically required for such configurations[footnoteRef:4]. Consequently, the particular site configurations must be verified with the customer prior to identifying cells with potential hardware issues. [4: Most vendors manufacture cabinets that support a maximum of 6 carriers per cell. However, some operators occasionally use up to 8 and even 12 carriers per cell. To get around the equipment limitation, two cabinets may be aggregated together, but if this is done incorrectly, it may lead to problems with the path balance. ]

Although a direct lightning strike or vandalism may damage an antenna, radio and/or connectors, such an event may not be sufficient to take the site completely out of service. Instead, the power levels and antenna range may be reduced. An operator may deliberately re-engineer an antenna, which can have the same effect, by changing the coverage of the cell. However, if the change results from vandalism or a mistake during routine maintenance, it could go unnoticed.

Offsets Carrier Path Balance DistributionsA wide differential in the mean path balance values for different carriers is also indicative of a hardware problem. Furthermore, even where the mean path balances for individual carriers is within the acceptable range detailed above, there may still be hardware issues if individual carrier show offset path balance distributions.Figure 21 below is an example of a cell with offset carrier path balance distributions. In this particular example, there is a larger path loss in the uplink direction. This problem was rectified by replacing a jumper cable affecting the uplink radio path.

It should be noted that small variations in mean path balances across different carriers may be unavoidable. This is especially the case with Nokia transceiver equipment which typically has self-calibration functionality.

In order to identify cells with multiple path balance peak path balance distributions, the carrier_level_pathbalance script, located at http://compass.mot.com/go/129216693, should be used. Contained within this script is the SQL stored procedure, sp_PathBalanceByCarrierWithMeanDiff, which computes the maximum difference between the path balance means of any two carriers in a cell. A sample report generated by this script is shown in Figure 20.As Figure 20 shows, the output of the carrier level path balance report is sorted by the maximum path balance difference in descending order. It has been found that path balance differences exceeding 4dB tend to be related to hardware faults. Consequently, it is useful to select those cells that exceed this threshold for further analysis.

Figure 20, Output of the carrier level path balance report.

Figure 21, A cell with offset path balance peaks.

Weak Receiver Issues

In conjunction with the path balance analysis, the network should be scanned for radios with weak receiver units. To identify weak receivers, a distribution of RxLevNonPC Uplink vs. Timing Advance should be generated. The required functionality for generating such a graph is available in the Combined Distributions option within the MR Distributions module of MVIOS. Further information on using combined distribution can be found in 5.4.2.4.

The Figures below provides an illustration of a cell suffering from a weak uplink path. As Figure 22 and Figure 23 show, despite having majority of low TA values there is a significantly high percentage of measurement reports registering a 0 Uplink RxLev value. This incidence of low RxLev at low TA values is indicative of a receiver issue.

Figure 22, RxLevNonPC Uplink for cell with weak uplink path.

Figure 23, TA distribution for a cell with a weak uplink path.

MR Distribution:Timing advanceThe timing advance information equates to a measure of the distance a mobile is from the BTS, which is then used to determine the propagation delay. Ideally, the timing advance distribution should be in line with the planned coverage area of the cell, but if there is splash coverage, i.e., the serving cell has a large number of MRs reporting large timing advances this could be due to a variety of issues: Poorly planned neighbour list Particular topological features, e.g., hills and/or valleys Interference inhibits handovers to neighbour candidates. Subscriber distribution.

Figure 24: Examples of timing advance MR distributions.Combined distributionsThese individual distributions can be further manipulated by combining the MR distributions of different metrics, which will reveal further details about the coverage and RF environment in the collection zone. Some examples of these combined MR distributions are given below: RxQual versus RxLev PCThis distribution will indicate the level of co-channel and adjacent interference. RxLevPC versus Timing AdvanceThis distribution can be used to identify if a BTS is transmitting at too great a range. If there are MRs are present with long timing advances, but the Rx level is low.RxQual versus Timing AdvanceCoverage limited quality with normal measurement report distribution distance may indicate frequency-planning issues. Optimisation reportsThese reports are initially used to identify potential problem cells, which can then be analysed in greater detail using the MR distributions, network configuration information, etc; by filtering the cells according to criteria defining what constitutes bad performance, or a possible problem with cells. To ensure that the underlying data is statistically significant, as well as defining the poor quality thresholds for each metric, a minimum threshold for the number of MRs that must be collected for each cell before it will be included in an optimisation report is also set.Optimisation report: Bad path balance reportIdeally the uplink and downlink path losses should be the same, i.e., mean path balance = 0; however this is rarely the case and there is always a slight bias even in the best cells. Therefore, to filter those cells where there is a distinct deviation, indicating a possible problem in the RF path between the mobiles and the BTS, for the example below, the filtering starts with those cells with a mean path balance > 10, or a standard deviation > 1. According to this configuration, only those cells for which there are at least 200 MRs will be considered for this report. The output in terms of serving cell ID, standard deviation, mean path balance or number of MRs, can then be sorted according to these criteria and prioritised.

Figure 25: Report Parameters for a Bad Path Balance Report

Optimisation report: Hopping, non-hopping reportThis report will collect a default number of MRs and if any indicate hopping, the cell is classified as being configured for hopping, otherwise if only BCCH MRs are collected the cell is recorded as non-hopping. Optimisation report: Large standard deviation in timing advance

The Timing Advance value shows the distance between a cell and the mobile. Large Timing Advance values suggest that the cell is handling calls from outside the expected region. This could indicate that a cell on the same frequency and closer to the mobile is failing to handle the call. The report lists only those cells where the standard deviation of the Timing Advance values exceeds the user specified value.

Figure 26: Report parameters for large standard deviation in timing advanceOptimisation report: Poor downlink and uplink coverageThese reports show cells that have more than the specified percentage of measurement reports where the downlink or uplink RxLev (without power control) is below the specified threshold. Only those cells for which there are more than the specified numbers of MRs will be included in the report.Optimisation report: Poor downlink and uplink qualityThese reports show cells that have more than the specified percentage of measurement reports where the downlink or uplink RxLev exceeds the specified threshold and the uplink or downlink RxQual is worse (greater) than the specified threshold. Only those cells for which there are more than the specified numbers of MRs will be included in the report.Optimisation reports: RF interference downlink and uplinkThese reports show cells that have more than the specified percentage of measurement reports where the downlink or uplink RxQual is worse (greater) than the specified threshold. Only those cells for which there are more than the specified numbers of MRs will be included in the report.

Figure 27: Report parameters for RF interference (downlink)

Power control optimisationThe power control optimisation step consists of two tasks: Review of the existing power control strategy by Motorola expert. Workshop with Motorola and customer experts to discuss the results of the review and to identify the changes to be implemented.In a multi-vendor environment, the extent to which the analysis and recommendations can be pursued is highly dependent on the network equipment supplier. With different equipment, nomenclature and implementation of parameters and features for other vendors, the recommendations will be limited to generic parameters and vendor independent features.Downlink Power Control LevelThe parameters responsible for the downlink power level are shown below.

GSM parameterMotorola specific parameterMotorolaMulti-vendorNokia

EN_BS_PCBts_power_control_allowed

P_CON_ACKbts_p_con_ack

P_CON_INTERVALbts_p_con_interval

POW_INC_STEP_SIZE_ULpow_inc_step_size_dl

POW_RED_STEP_SIZE_ULpow_red_step_size_dl

-dyn_step_adj

-dyn_step_adj_fmpr

HREQAVE[footnoteRef:5] [5: With Nokia, Hreqave may not be explicitly listed amongst the parameters. Instead, the parameter Averaging Window may be used.]

Hreqave

N1decision_1_n1

P1decision_1_p1

N2decision_1_n2

P2decision_1_p2

L_RXLEV_DL_Pl_rxlev_dl_p

U_RXLEV_DL_Pu_rxlev_dl_p

-frequency_type

Table 4. Downlink Power Control Level ParametersA general recommendation is that cells be configured to use dynamic Power Control; however depending on how it has been implemented, there may be an opportunity to configure power control to respond more aggressively and thereby bring high levels down more rapidly. This is achieved by changing the value of the parameter dyn_step_adj_fmpr, i.e., the magnitude of the dynamic power control step-size increment. Downlink power control has an upper (u_rxlev_dl_p) and lower threshold (l_rxlev_dl_p), referred to collectively as the power control window. As a general rule, a window size[footnoteRef:6] of 10dB should be used. Since maintaining a call in the best server is an important objective, it must be ensured that l_rxlev_dl_p is set to a value greater than the imperative level handover value l_rxlev_dl_h. [6: The window size is the difference u_rxlev_dl_p l_rxlev_dl_p]

If the majority of MRs are registering DL RxLev values towards the lower threshold, this is an indication of good quality on the downlink path and it may be an opportunity to lower the BTS power still further, in turn reducing the overall downlink interference still further. Dynamic power control only operates either side of the power control window and will attempt to bring the power level within this range, after which quality level mechanisms take over. When handovers and call set-ups occur, the power level is at its highest; however, little benefit will be obtained from dynamic power control if the upper threshold is set too high, therefore there is often scope for optimising this parameter. In bringing the power level within the power control window, the power control algorithm increments the power level in a series of steps, the magnitude of which are defined by pow_inc_step_dl and pow_red_step_size_dl, for the increase and decrease step sizes, respectively for the BTS to MS power. Once the BTS has adjusted to a new power level it returns an acknowledgement to the HDPC (Handover Power Control); the parameter bts_p_con_ack is the maximum time within which this acknowledgement can be returned. The dwell time of the BTS at the new power level is defined by bts_p_con_interval. Downlink Power Control QualityThe parameters for controlling downlink power by quality are shown below. GSM recommendationMotorola specific parameterMotorolaMulti-VendorNokia

EN_BS_PCbts_power_control_allowed

P_CON_ACKbts_p_con_ack

P_CON_INTERVALbts_p_con_interval

POW_INC_STEP_SIZE_ULpow_inc_step_size_dl

POW_RED_STEP_SIZE_ULpow_red_step_size_dl


Hreqave

N3decision_1_n3

P3decision_1_p3

N4decision_1_n4

P4decision_1_p4

L_RXQUAL_DL_Pl_rxqual_dl_p

-hop_qual_enabled

L_RXQUAL_DL_PL_rxqual_dl_p_hopping

U_RXQUAL_DL_Pu_rxqual_dl_p

-frequency_type

Table 5. Downlink Power Control Quality

As mentioned previously, once the power level has been brought into the range of the power control window, the dynamic power control mechanism effectively hands over responsibility for power control to the power control quality mechanism. The quality band values reported in the MRs are used to determine the power level, but in order to reduce excessive fluctuations in the power level that might result from acting on every MR, the quality mechanism takes an average over several MRs. If the quality is bad, the power level is stepped-up (typically by 4dB or 6dB per step and controlled via pow_inc_step_dl), until the quality re-enters the defined acceptable range. If the quality is good, the power level is reduced (typically in 2dB increments and controlled via pow_red_size_dl), until the average quality is no longer good.Experience from optimising GSM networks has shown that an upper quality threshold u_rxqual_dl_p of 1 and a lower quality threshold l_rxqual_dl_p of 4 produce satisfactory results. These settings allows the basestation to power down within the power window whilst maintaining adequate quality. It is important to note however, that since maintaining a call in the best server is an important objective, l_rxqual_dl_p should be set to a quality value that is better than the imperative quality handover value l_rxqual_dl_h.

Uplink Power Control LevelThe parameters for controlling uplink power by quality are shown below.

GSM recommendationMotorola specific parameterMotorolaMulti-VendorNokia

ms_power_control_allowed

ms_p_con_ack

P_CON_INTERVALms_p_con_interval

POW_INC_STEP_SIZE_ULpow_inc_step_size_ul

POW_RED_STEP_SIZE_ULpow_red_step_size_ul


hreqave

-dyn_step_adj

-dyn_step_adj_fmpr

N1decision_1_n1

P1decision_1_p1

N2decision_1_n2

P2decision_1_p2

L_RXLEV_UL_Pl_rxlev_ul_p

U_RXLEV_UL_Pu_rxlev_ul_p

-frequency_type

Table 6. Uplink Power Control Level

Uplink power control has an upper (u_rxlev_ul_p) and lower threshold (l_rxlev_ul_p), referred to collectively as the power control window. The quality power level mechanism will permit the RxLev to fall below the upper threshold of the uplink power control window, which can be taken as an indication of sufficiently good quality still possible at this level, and therefore the mobiles powering down accordingly. In such a case both the upper and lower power control window thresholds could be lowered further. As a general rule, a window size[footnoteRef:9] of 10dB should be used. Since maintaining a call in the best server is an important objective, it must be ensured that l_rxlev_ul_p is set to a value greater than the imperative level handover value l_rxlev_ul_h. [9: The window size is the difference u_rxlev_ul_p l_rxlev_ul_p]

Most networks tend to have fairly conservative settings for dynamic power control; but by combining the lowering of the power control window with more aggressive settings for the dyn_step_adj_fmpr, a larger stepped-increment for the dynamic power control would allow the mobiles to be able to power up or down more rapidly. A RxLev value below the lower power control window threshold may be an indication of two possibilities: The path loss is too great The ms_p_con_ack was not long enough to allow the current power change to be propagated and the acknowledgement to be returned to the HDPC. In the latter case, if the acknowledgement is not received in time, the quality power control mechanism will take precedence and continue to push down the power level as long as the quality allows. Increasing ms_p_con_ack will stop the uplink receive level dropping below the lower threshold, because the acknowledgement will be received prior to the next power change and if this were to take the power level below the lower threshold it will not be permitted.

Uplink power control qualityThe parameters controlling uplink power by quality are shown below.

GSM recommendationMotorola specific parameterMotorolaMulti-VendorNokia

-ms_power_control_allowed

ms_p_con_ack

P_CON_INTERVALms_p_con_interval

POW_INC_STEP_SIZE_ULpow_inc_step_size_ul

POW_RED_STEP_SIZE_ULpow_red_step_size_ul


Hreqave

N3decision_1_n3

P3decision_1_p3

N4decision_1_n4

P4decision_1_p4

L_RXQUAL_UL_Pl_rxqual_ul_p

-hop_qual_enabled

L_RXQUAL_UL_PL_rxqual_ul_p_hopping

U_RXQUAL_UL_Pu_rxqual_ul_p

-frequency_type

Table 6. Uplink Power Control Quality

Experience from optimising GSM networks has shown that an upper quality threshold u_rxqual_ul_p of 1 and a lower quality threshold l_rxqual_ul_p of 4 produce satisfactory results. These settings allow mobiles to power down within the power window whilst maintaining adequate quality. It is important to note however, that since maintaining a call in the best server is an important objective, l_rxqual_dl_p should be set to a quality value that is better than the imperative quality handover value l_rxqual_dl_h.

Intelligent Coverage OptimisationOverlapping cells is a natural consequence of the planning process, and in some respects offers positive benefits to the operator, i.e.,Introduces some resilience into the network in the event of hardware failureOverlapping coverage can offer an alternative for subscribers in coverage holes However, if the coverage of a cell is allowed to extend too far, with respect to the planned coverage, it could become a source of interference, especially with a tight frequency plan. To identify such cells, the collection area is subjected to coverage optimisation analysis. This uses the C/I matrix generated by the IOS and data collected during a neighbour add procedure and processed from the measurement reports to determine:Timing advance data for each cell within the network.The potential interference to traffic caused by a cellAggregated, i.e., total for all effected cellsPer cell, i.e., the extent of the interference on a per cell basisThe traffic carried by the interfering cell

Figure 11. Example of Intelligent cell overlap CalculationThe Overlap report provides seven outputs, which can then be used to rank the cells according to according to different criteria, e.g., cost-benefit analysis of the interference caused vs. traffic carried:Interfering cell IDTraffic carried by the Interfering cell Interference caused by the interfering cell (Aggregate or per cell)Interfered cell IDTraffic carried by the interfered cellNumber of interfered cellsNumber of interfered carriersFollowing this analysis, a list of the worst overlapping coverage cells can be identified and recommendations for both antenna tilt and azimuth changes within the network can be made.Reviewing the recommendations with experts who have local knowledge.Benchmarking the performance changes both before and after any antenna changes. In order to aid the analysis and recommendation process, the density of measurement reports and physical locations of the reporting cells can be represented pictorially (see figure 12), which will allow topological features to be considered. The benefit of the above will be to provide data and recommendations that ensure that the labour intensive tilt and azimuth change programme is effective, and yields an improvement in overall network quality. However, if antenna changes have taken place, it is highly recommended that a neighbour optimisation be undertaken, whether by means of a new neighbour add task (preferred) or using the data from an intelligent frequency plan collection.

Cell Overlap Report 1.Cell Overlap Report 2.Cell Overlap Report 3.In all three examples illustrated in Figure 12 above, the scale bar is 10km; the number and size of the red spots is indicative of the neighbours cells reporting the serving cell and the number of MRs reporting it from each cell. In all three cases, the antennae have a beam width of 85o. The first example is for a well-positioned and configured cell, with its coverage largely contained by the surrounding hills, even the farthest cells are relatively close. However, in intelligent cell overlap report 2 and 3, there are significant numbers of MRs from cells at considerable distances from the serving cells, coverage is irregular and the beam width is far greater than 85o. Major interfering cells are not only a problem for their neighbours but also for the wider network due to the restrictions they can impose on frequency re-use. Therefore, once identified the problems caused by these cells may be solved by implementing one or more of the following measures: down-tilting the antennae, reducing its height, changing its orientation (i.e., azimuth), or in extreme cases removing the site altogether.

Figure 12. Graphical Examples of Intelligent cell overlap ReportsUnique Cell Coverage ReportThis is a useful feature that enables the user to characterise the environment of all cells in terms of isolation from other cells. It will rank cells in their level of overlap with other cells.

Unique cell coverage = total SVR cell traffic (SVR cell traffic in NBR overlapping coverage)Where, SRV = Serving cellNBR = Neighbour cellIn a sense this report identifies the redundancy in cell coverage resulting from cell overlap, infers how much traffic will be lost if a serving cell goes out of service. MRs provide the data, and the algorithm calculates the following:

Cells can then be prioritised according to their traffic load and potential for traffic loss in the event of going out of service, and steps can be taken to protect these cells with additional RSL links, etc.

Figure 13. Unique Cell Coverage

GSM RAN Optimisation Service SpecificationMotorola Internal Use OnlyVersion R00.00.073rd Novemeber 2003Copyright Motorola 2003Page 2 of 3

Intelligent neighbour optimisationNeighbour Addition and DeletionThe neighbour lists maintained by the BSC database are used to define the list of potential cells to which a mobile can be handed-over to, if the signal strength in the serving cell falls below the handover threshold.However, given the dynamic nature of network operations and maintenance, changes to the network may not be reflected in the status of the in-use neighbour lists. In order to maintain the relevance of these lists, they must be periodically checked to identify possible candidate neighbours for addition to or removal from the lists. This involves two collections of measurement report data, each taking several days. Once the data from the first collection is analysed, the second collection and analysis is conducted. Neighbour delete After the first collection of measurement reports is performed, the data analysed to identify neighbour relationships that are never used or rarely seen by mobiles. These are then recommended for deletion. Neighbours add The second collection includes the creation of test neighbours using a frequency rotation method. The data is analysed to identify cells that are reported by mobiles in cells that do not currently have a neighbour relationship, these are then ranked and recommendations made for additions to the neighbour lists.Using the large dataset generated by the data collections will provide confidence in the recommendations produced by the analysis. In addition, the process can also identify sector problems. The neighbours add analysis task can also be performed using data collected by the intelligent frequency-planning step. This approach offers cost and time benefits over traditional neighbour management processes.Neighbour Delete ReportThe criteria for deciding whether a cell is suitable for deletion are as follows: No mobiles report the neighbour, i.e., neighbour not visible to the serving cell Very few MRs and power budget is very low, i.e., unlikely destination for a handover

Figure 11. Example of Neighbour Deletion AnalysisSelecting those neighbours for deletion, which are unseen is a straightforward decision, but deleting a poorly visible or weak configured neighbour requires some further analysis.

Figure 12. BSS Handover selection criteriaIf the number of MRs exceeding the power budget for handover is less than 0.01% of the total number of MRs reporting the configured neighbour, it will be indicated in the report as being suitable for deletion. In addition the report will give the number of additional MRs that would pass the HO margin if it were lowered by 10dB and 20dB.Neighbour Addition ReportThe same considerations that are used to identify configured neighbours for deletion are used to identify non-configured neighbours for addition. The report will ensure that: Potential neighbour cells are identified for addition to the list of the serving cell The list should be capable of supporting both power budget and imperative quality Handovers Cells with the same BCCH/BSIC as the serving cell are not added to the list Figure 13. Neighbour AdditionA neighbour cycling procedure is used to generate MRs from non-configured neighbours and when these are analysed the initial criteria for deciding whether a cell should be added to the serving cells neighbour list is determined by the percentage of MRs. Other criteria that should be taken into account include the imperative quality handover thresholds between serving cell and prospective neighbour. Layer management is to ensure that the maximum use is made of the available capacity whether this is GSM900/DCS1800 and/or macro/micro. Layer management needs to review the amount of traffic carried. This can be calculated using statistics (if available) or measurement reports.Once the traffic carried has been calculated it needs to be analysed in a number of ways: Ratio of the percentage of unused capacity between the different layers. Identify unused radio equipment, which could be redeployed to a site where extra capacity is required.Some of the recommended solutions could be: Modify the handover parameters to force more traffic on to the other layer. Enable features that can more traffic from one cell to another, e.g. Motorolas congestion relief feature.Once the analysis has been completed a workshop should be held between Motorola and the customers experts to discuss the current layer management strategy. Any agreed changes which be implemented in the network by the customer.

Layer management optimisationWhere a network has multiple layers (e.g. GSM900/1800 and/or macro/micro) it is important that the utilisation of all the resources is maximised. Motorola analysts will review the current levels of traffic and the current traffic levelling strategy (e.g. single BCCH for GSM900/1800 networks).

The objective of this process is to use Motorolas experience and best practices in reviewing the multi-layer traffic management. A comparison of the actual handover performance and traffic distribution against the overall network strategy is necessary, so that recommendations can be made to improve quality and maximise capacity for future growth.

The following areas will be considered in this review:

Handover performance

Traffic distribution

Congestion strategy

Spectrum availability

Layer density

It is essential that local anomalies and historical issues that drive particular traffic strategies be taken into account. The local system or optimisation engineers and planners generally hold this type of knowledge. It is recommended that the result of any analysis be discussed with them, in order to ensure that recommendations are compatible with existing and future plans for the network.

A workshop will be held between Motorola and the customer to discuss the current strategy and agree any changes.

Intelligent Frequency PlanningTraditional frequency planning is normally based on drive test data and local knowledge. This is not very accurate as the majority of calls are not made/received, e.g. in buildings, from the location where drive testing takes place, e.g. multi-lane roads. In addition, after a new frequency plan is deployed it takes a number of weeks to bring the quality of the network. With intelligent frequency planning the frequency plan is based on the actual measurement reports of phone calls and thus is a more accurate frequency plan that requires fewer changes after deployment.Conventional Uniform Frequency PlanningRegular SFH (synthesizer frequency hopping) relies on the distribution of interference over time and fractional occupation of frequencies to allow very tight or no re-use of the frequency spectrum. It is also designed for a network with equal distribution of cells with regular azimuths.

AdvantagesEase of deploymentEase of new site expansionEase of frequency plan managementDisadvantagesVery limited visibility of where interference originatesOffers excessive and unwanted interference into the networkWasteful in terms of spectrum utilisation

SFH 1 x 1 = no visibility

SFH 1 x 3 = source can be isolated by sector but relies on regular azimuths in same sector orientation.

Whatever type of regular SFH is applied there is no ability to selectively eliminate offered interference, in other words, one size fits all.Non-uniform Frequency PlanningNon-uniform hopping with a fractional load of 100% relies on a very accurate C/I matrix based on real subscriber data.Using a C/I matrix with high accuracy the AFP, (automatic frequency planner), can produce a different MAL, (mobile allocation length), for every sector in the planning area. The AFP tries to avoid co-channel or adjacent channel frequencies, within MALs of cells interfering with each other, based on the C/I matrix.From the planning point of view, the network is planned like a non-hoping network. A frequency is planned for each carrier such that the possible interference created is minimised.

In non-uniform SFH:Every sector uses a different MALHSN per Site (the same on each sector of the site)Maximum fractional load is 100% Minimum required Frequencies in the MAL = Number of hopping carriers on the site

Advantages of non-uniform hoppingCombines interference distribution and fractional occupancy with a frequency plan, which allocates a different group of frequencies to every cellInterference is avoided as well as distributedInterference offered to the network by individual cells is minimisedFlexibility to modify re-use on a cell-by-cell basisGreater scope for optimisationMore efficient utilization of the available frequency spectrumDisadvantages of non-uniform hoppingNew site deployment, as difficult as a fixed plan but the creation of spare frequencies, during the planning process, enables easier site deployment.

Frequency PlanningThe frequency plan produced by intelligent frequency planning uses non-uniform SFH techniques. This allows for every MAL to be unique and the same length as number of carriers. This is the equivalent to baseband hopping and uses the minimum number of physical frequencies.It is based on a collection of mobile measurement-report, data, within which, every available frequency will have been included on every carrier as either a test neighbour or a configured neighbour for at least 24 hours for each day of the week. This ensures that all interference is identified and the resulting C/I is weighted correctly, by traffic. The volume of data collected and used in this process gives a high degree of confidence in the final accuracy of the C/I.The resultant frequency plan needs verifying. Verifying the plan should include: Importing into a mapping tool and check for co-channel/adjacent channel neighbour sites. Ensure the customer engineers check the plan. Check the BSIC and HSN distribution.Once the new frequency plan has been deployed the network should be benchmarked for a period of 1 week using the statistics agreed between Motorola and the customer.

SummaryPlans produced by this Intelligent Frequency Planning process are of very high quality and as a result there will be an inevitable change in each cells effective coverage footprint. Any improvement in RF performance effectively provides the opportunity to significantly increase capacity and until previous quality levels are reached.

The increase in coverage due to the reduction in interference will impact the existing neighbour lists. It is recommended that an additional, short, collection be undertaken in order to correct any such issues.

Uniform SFH planning has been designed for uniform networks, where the cells are distributed in a regular pattern but where the source of interference is not known. It is easy to plan, but difficult to optimise.Non-uniform planning relies on an accurate interference matrix with the inherent knowledge of the source of any interference.Intelligent frequency planning delivers a very accurate C/I matrix based and weighted on measured subscriber data.The use of this accurate C/I with non-uniform SFH delivers:Best possible interference reductionAbility to eliminate specific localised interferenceMaximised efficiency of every radioMaximised network performance (QoS)A customised solution for the network where plan is based on the actual network conditions, independent from typical database inaccuracies, which are the inherent in traditional frequency planning.

Annexe A

This section describes the Motorola handover mechanisms with their associated timers. It can be used as a reference comparison with other vendors handovers features.HandoversThe purpose of handovers is to: Ensure that mobiles are served by the best available cell (highest quality, highest receive level (uplink/downlink), lowest transmit power (uplink/downlink), least interference) Off-load busy cell traffic in the event of cell congestionWhen the criteria are exceeded, one of several possible handover mechanisms will be invoked. In order to guard against temporary fade or other transient effects, which could lead to an oscillation between the cells or bands, these different mechanisms each use different algorithms and thresholds to determine whether and how the handover will take place.Power Budget HandoverThe power budget handover parameters are as follows:

ParametersMotorolaMulti-Vendor

adap_ho_pbgt

adap_trigger_pbgt

pbgt_alg_type

ho_margin_cell

pbgtsrcellhreqave

hreqave

useneipbgthreqave

rxlev_min_cell

cell freq_type

Nbr freq_type

Table 8. Power Budget Handover Parameters

Power budget handovers require two simultaneous events in order to be triggered: The neighbour must exceed the rxlev_access_min of the serving cell The power of the neighbour must exceed the combined power of the serving cell + the handover power offset (ho_margin_cell)The handover itself could be between cells in the same band or between bands, depending on the traffic and performance of the different bands.Typically, this mechanism should constitute at least 70% of all handovers in the network.Typically the 1800 band is preferred and if that is indeed the case, it is recommended that all the cells in the 1800 band should have the cell parameter band_preference_mode set. The actual setting will determine how aggressively, during call set-up and for normal handovers, mobiles will be assigned a TCH in the 1800 band, even when it does not have the strongest signal.

When the adaptive handover parameters are enabled for power budget handovers, i.e., adap_ho_pbgt and adap_trigger_pbgt. In addition the power budget algorithm must be selected from 7 possible choices and the ho_margin_cell must also be set.Similarly, the magnitude of the ho_margin_cell and rxlev_min_cell parameters can be specified to either encourage or discourage inter-band handovers between 900 and 1800 bands cells; but with the band preference set, power budget handovers are limited to intra-1800 band hopping, with the ho_margin_cell between the 1800 to 900 band is set sufficiently high to discourage inter-band handovers. Adaptive HandoversA cell will perform an adaptive handover depending on the rate at which the radio conditions are changing for the mobile, i.e., if the conditions are deteriorating rapidly, the handover will be triggered more quickly; and slowly if the radio conditions are degrading slowly. The criteria (i.e., a marginal need for a handover) for triggering the handover increment a cumulative counter, and when the threshold is reached, the handover is triggered.

The adaptive handover mechanism may be enabled for:Power Budget

gsm ran service specification

Documents

power control optimisation32

power control optimisation365

updated power control

uplink power control

service enablers84

frequency planning25

document version

review d00