Project Report: 4.1 To Calculate Prediction For Overlapping Zones
Project Report: 4.1 To Calculate Prediction For Overlapping Zones
PROJECT REPORT
4.1 To calculate prediction for overlapping zones
After the coverage prediction of the sites, the next step is to calculate he prediction for the overlapping zones. We have checked the prediction by the coverage signal level, now we will check the prediction by the new parameter which is the OVERLAPPING ZONES. The steps are as follows:
Go to prediction->New
OPTIMISATION PROCEDURE
The optimization process starts immediately the network is brought into operational service or an enhancement takes place on the network. During times of little change to the network Performance Engineering monitor the quality of the network and will seek assistance from Optimization Engineers if the quality of the network begins to fall.
The following figure shows the PLANNED COVERAGE AND FIELD DATA
The procedure below is the basic method for Optimizing a system and can be modified to each operator to maximize results.
Before Optimization starts all of the pre-requisites must have been done or be in place. There must be a change control procedure in place with the operator that Motorola are familiar with, the RF design and Database parameters must be presented to the Optimisation control manager. All drive test teams must have test mobiles and SIM cards provided by the operator. Note - The Optimisation control personnel are usually situated with the OMC personel for maximum effieciency as OMC and Optimisation control are continually passing information between each other.
The drive test routes must be agreed with the operator and a priority set on the routes for testing.
The drive test teams make test calls on the network of 2 minute duration with a 15 second break between calls to the MSC test number with the Test Mobile equipment (TEMS) and all data is
logged to the computer, location information is also taken using a GPS reciever to provide location information.
The drive test routes are usually 3 - 4 hours in duration so that the data collected can be managed.
During or after completion of the drive test route analysis of the data collected is done to find areas of dropped or noisy calls. This can either be done on the RF planning tool or using the GIMS software in the field
The results of the drive test, including analysis is passed to Optimisation Control for performance logging of the route.
Should the analysis of the route indicate problems of either dropped or noisy calls , with the aid of the RF design and Database parameters an assesment is made to identify the possible source of interference causing the noisy or dropped call. If a call is dropped and no interference is present a retest is made in the same area, if the scenario of the dropped call can be repeated, information of the problem cell should be obtained, this will then be escalated to Optimisation control to seek assistance from the BSS maintenance engineers to investigate the cell dropping calls.
Note - To assist in confirming possible sources of interference there may be a requirement to remove the suspected interfering channel. This would be done via the optimisation control engineers . The suspected interfering carrier would be removed temporarily from service and test calls made again in the problem area, this would show if the interference had been removed. The process for temporarily removing carriers would have to be agreed with the operator, this usually varies as to the importance of the cell as to what time of day it can be taken out of service.
After conformation as to what is causing the problem with the drive test route, the drive test engineer will attempt to find a solution to the problem. This can be one of a number of possibilities i.e Power Change to BTS, Frequency Plan change, Neighbor addition required etc.
Note - In the case of a frequency plan problem, this is usually escalated through Optimisation Control to the RF design engineer to find a solution to the problem. The RF designer and Optimiser for an area are usually the same engineer in Motorola, this has continually proven to be
the most efficient method of improving the quality of the network with respect to problems with the frequency plan of the network.
Once a possible solution to the problem has been found it may be possible in some circumstances to immediatly attempt the solution via the OMC, this usually relates to minor database changes and adding neighbors. The solution is implemented and proven immediately. If the problem is rectified the change remains in place and a change request is raised for the solution for the purpose of keeping records of all changes in the network. If the solution requires a major database change or antennae work a change request must be raised via the Optimisation Control Engineers. After the solution is implemented a retest of the problem area is carried out to confirm the problem has been solved.
In the event of the problem not being solved alternative solutions may be attempted, this process continues until it becomes immpossible to find a solution. At this point the problem is discussed with the operator as to the reasons that the problem cannot be solved for example the solution may require a new cell to be built, clearly this is beyond the scope of optimisation. If the operator is in agreement this particular problem will be removed from the drive tests until such time a solution is implemented.
Steps 3 to 10 are repeated throughout the system until such time that all routes meet the required metrics or no further improvement can be made due to circumstances outside the control of Motorola.
DRIVE TESTING
It is a method that is adopted to optimized GSM network. Once a GSM network is rolled out based on network planning tool prediction. The nature of network hardly ressembles with the prediction so that the operator or the service provider tasks is to bring the network back as nearest as possible towards the prediction.
Through the systematic process of collecting the air interface data from the already built network status of existing network get recorded. The collected data is processed offline to know the deviation from the prediction as per the interpretation of thepre processing result configuration changes are performed on the network. Then further DRIVE TEST is performed to check the modified status .after a few changes the network is brought very near to the prediction then the network is set to optimized
1)EXTENSIVEFOR SHORT CALLS The various parameters checked in this are like SSR , Handover Failure , Handover Success , FER , BER , RX Level .In this time is fixed of 60 sec for 100 calls.After 60 sec all the calls will be repeated.
2)INTENSIVEFOR LONG CALLS The various parameters checked in this are like C/A , C/I , BER , FER , ACCESS DELAY (which is time between channel request (RACH) And call alert (AGCH)).in this time is increased.After 120 sec all the calls will be repeated.
PERSONEL REQUIREMENTS The intention here is to show the engineers required in the optimisation process and not the amount of engineers. The amount of engineers will depend on the size of the network, the amount of area to be covered and the roll out schedule.
Once the above information is known a more precise proposal can be done detailing specific numbers of people required.
Drive Test Engineers Performance Engineer BSS Mtce Engineer Antennae Riggers Optimisation Control
Drive Testing, Performance evaluation, Antennae and database Changes. OMC Statistical Analysis, Quality Metric figures. Fault Identification and Clearance Antennae Azimuth and downtilt changes Management responsibilities of all staff, Presentation of Quality Metrics, Technical Guidance to Engineers, Change control Management.
Tems Tems is the drive test mobile and software from Erisoft. The kit consists of a laptop P.C, an Ericsson GH688 test mobile and a GPS reciever for positioning information.
Mapinfo Mapinfo is a GIS software tool, it is used to display drive test data for analysis and to produce Optimisation reports in a clear and easy manner.
Test Mobiles Test mobiles are an invaluable source of information, all field engineers should be equipped with a test mobile to identify problem areas.The test mobile should be capable of giving the recieved signal level, RXQual value, Cell I.D and six neighbors with rxlevels.
From A Document Template: You can create a new Atoll document from a template. Atoll is
delivered with a template for each technology you will be planning for. You can also create your own template by basing it on an existing document that you have already customised with, for example, certain geo data or antennas.
From An Existing Database: When you create a new Atoll document from a database, the database
you connect to has been created with the technology and data you need. Working with a database allows several users to share the same data while at the same time managing data consistency. The exact procedure for creating a new Atoll document from a database differs, depending on the database containing the data. Atoll can work with several common databases.
Geographic data used in dimensioning: - Traffic maps Geographic data used in statistics: - Population maps
- Custom maps
Clutter Classes
The clutter class geo data file describes land cover or land use. Each pixel of a clutter class file contains a code (from a maximum of 256 possible classes) which corresponds to a clutter class, or in other words to a certain type of ground use or cover. The height per class can be defined as part of the clutter class, however this height is only an average per class. A clutter height map can represent height much more accurately because it allows a different height to be assigned for each bin of the map.
Clutter Heights
Clutter height maps describe the altitude of clutter over the DTM. Clutter height files allow for a higher degree of accuracy because they allow more than one height per clutter class. In a clutter height file, a height is given for each point on the map. If you define clutter height as a property of clutter classes, the height is given as an average per clutter class.
Once you have created a network, you can make predictions. There are two types of predictions:
Point predictions using the Point Analysis tool: The Point Analysis tool allows you to predict, at
any point on the map, the profile between a reference transmitter and a receiver, the value of the signal levels of the surrounding transmitters, an active set analysis for UMTS, CDMA2000, and TD-SCDMA projects and an interference analysis for GSM/GPRS/EDGE projects.
Coverage predictions: You can calculate standard coverage predictions, coverage by transmitter,
coverage by signal level and overlapping zones, and specific coverage studies such as interference studies for GSM/GPRS/EDGE projects or handover, service availability, etc. for UMTS, CDMA2000 and TDSCDMA projects. Many customisation features on coverage studies are available in order to make their analysis easier. Atoll facilitates the calculation of coverage predictions with support for multithreading and distributed calculating. The progress of the calculations can be displayed either in the Event Viewer window or in a log file. Atoll also allows you to use polygonal zones to limit the amount of resources and time used for calculations. The polygonal zones, such as the filtering zone and the computation zone, help you to restrict calculations to a defined set of transmitters, and to limit calculations and coverage predictions. Depending on the type of project you are working on, you can choose between the propagation models available in Atoll
Coverage by overlapping zones. Atoll also offers technology-specific coverage predictions, described in the technology-specific chapters, for example: Interference studies in GSM/GPRS/EDGE projects Coding scheme and throughput studies for GPRS/EDGE UMTS or CDMA2000 coverage predictions. Atoll gives you a large flexibility over how the results of your coverage prediction are displayed. You can select which attributes should be displayed on the map and how they are displayed. As well, you can define information to be displayed in the legend, in the label, or in tooltips. Furthermore, Atoll also allows you to filter, sort, or group results before displaying them.