AWS Optimization Guidelines Rev 4 Mar 15 2002

8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002

1/33


2/33

PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4

2 (33)

Network Planning/NET Mar 15, 2002

2

TABLE OF CONTENT

1. PURPOSE.........................................................................................................................................4

2. SCOPE ..............................................................................................................................................4

3. RESOURCES ...................................................................................................................................4

3.1 Network Planning Manager........................................................................................................4

3.2 RF Technology Consulting.........................................................................................................4

3.3 Regional Network Planning Manager ........................................................................................4

3.4 Network Planning Market Manager ...........................................................................................4

3.5 NOKIA Optimization Consultant ................................................................................................5

3.6 Partner Optimization Lead .........................................................................................................5

3.7 Optimization Engineer Cluster Owner ....................................................................................5

3.8 Drive Tester ................................................................................................................................6

3.9 Implementation Coordinator.......................................................................................................6

3.10 Transmission Planning Support .............................................................................................6

3.11 NMS Support ..........................................................................................................................6

3.12 AWS Local Market and Corporate ......................................................................................7

4. Schedule ...........................................................................................................................................7

5. Process Flow.....................................................................................................................................7

6. General ............................................................................................................................................107. Pre-conditions For Optimization .....................................................................................................10

7.1 Priliminary checks ....................................................................................................................10

7.2 On air verification .....................................................................................................................11

7.3 Manually locking onto a frequency Channel:...........................................................................12

7.4 Cluster Definition And Naming.................................................................................................12

8. Drive Test Process..........................................................................................................................13

8.1 Preprocess ...............................................................................................................................13

8.2 Drive Test .................................................................................................................................14

8.3 Post Processing .......................................................................................................................159. Cluster Analysis ..............................................................................................................................15

9.1 Analysis Process......................................................................................................................15

9.2 Modifications ............................................................................................................................16

9.3 Intercluster Verification .............................................................................................................16

9.4 Network Doctor Reporting ........................................................................................................16

10. Quality Of Service Criteria, KPI factors ...................................................................................17

10.1 Retainability (Call Success Rate, 1-TCH Drop Call Ratio) (%) ..........................................17


3/33


3 (33)


3

10.2 Downlink Quality (%) ............................................................................................................17

10.3 Accessibility or Call Setup Success Ratio............................................................................1710.4 Coverage (% of time), Down link Level .................................................................................17

10.5 Handover Success Ratio......................................................................................................18

11. DOCUMENT DELIVERY..........................................................................................................18

12. DEFINITIONS...........................................................................................................................18

13. Related documents ..................................................................................................................19

14. APPENDIX I : Analyzing Software Report ...............................................................................20

15. APPENDIX II: daily Network Doctor reports............................................................................21

16. APPENDIX III: Call and handover troubleshooting charts ......................................................22

17. APPENDIX IV: FORMS FOR optmization process .................................................................24

17.1 Parameter Change Request.................................................................................................24

17.2 Network Doctor Request ......................................................................................................26

17.3 Hardware Change Request Form ........................................................................................27

17.4 Optimization Summary Report .............................................................................................28

17.5 Cluster Sign Off report ..........................................................................................................29

18. On Air verification check list .....................................................................................................30

19. Parameter audit Report Template ...........................................................................................33

20. DOCUMENT REVISION HISTORY .........................................................................................33


4/33


4 (33)


4

1. PURPOSE

The purpose of this document is to define how the drive test and network optimization is performedbefore and during the network launch. This document is based on experiences from earlier networkplanning projects including experiences from previous AWS 3G optimization project. This documentgives general guidelines on how to optimize and analyze GSM network performance, and iscustomized for AWS 3G turnkey project.

2. SCOPE

Network Optimization process is a continuous and iterative process of improving overall networkquality. The objective of the optimization in a turnkey project is to verify that the plan is implementedcorrectly. Any problems encountered are corrected to make sure that the network meets theacceptance criteria defined in the contract. The basic tools used are NMS2000 and Drive TestMeasurement and Analysis Tool.

3. RESOURCES

To optimize network in proper manner, it demands resources of different skills. Everyone has his orher own specific responsibilities while performing optimization. Different skills are listed below:

3.1 Network Planning Manager

Is responsible on national level for AWS 3G Network Planning.

3.2 RF Technology Consulting

Is responsible on national level for technology related issues in AWS 3G Network Planning. Network

Planning Market Manager informs any inter vendor related issues to the RF Technology Consultingduring the project.

3.3 Regional Network Planning Manager

Is responsible on the regional level for Network Planning issues. Based on the geographical location,the whole country is divided into four regions viz. California, Hawaii and Alaska Region, WesternRegion, Great Lakes and New York Region and Southern Region. Each Region has a nominatedregional planning manager.

3.4 Network Planning Market Manager

Network Planning market manager is responsible for the customer deliverables and makes sure that

everything goes according to optimization schedule and there are resources at the right place at theright time. He/she makes the optimization schedule and resource plan according to network ready(launch) with help of optimization lead and NOKIA Optimization Consultant. During the project, themarket planning manager takes care of the following issues:

1. Makes sure that the Datafill prepared by the Network planners during the network planningphase is correct and forwards it to the RIC Support, RIC RNW.

2. Once the implementation begins, the Network Planning Manager makes sure that theoptimization team verifies the frequency plan. No frequency out of allocated band should beused. If network doctor reports are not available for the verification process, BSC dataextracted via MML commands should be used instead.


5/33


5 (33)


5

3. Makes sure that there are enough resources e.g., headcount (optimization engineer + drivers),

drive test equipment etc.

3.5 NOKIA Optimization Consultant

Is the technical optimization support for the market. The Optimization consultant is responsible for:

1. Supporting integration team with on air verification process as explained in section 7.1.

2. Looking at the daily reports on the network level and communicates with the cluster owners ifany changes are needed,

3. Providing support to the NP manager in both technical and management issues as and whenrequired,

4. Helping cluster owners analyze data and troubleshoot in the field as and when needed, and5. Conducting regular technical overview sessions for the optimization team.

3.6 Partner Optimization Lead

The Optimization Lead has the following responsibilities:

1. Reporting the preliminary check results to the planning manager and optimization consultantas explained in section 7.1

2. Scheduling drive in the cluster i.e., which area to drive, baseline or troubleshooting drive,

3. Saving the Daily NMS Reports and alarms in the server,

4. Updating Cell Tracker,

5. Sending change request to the RIC center after consulting with NOKIA OptimizationConsultant,

6. Making sure with each cluster owner that the deliverables are ready on time,

7. Preparing the parameter audit report before the Comarco Drive i.e. a week before the Networkready date using the template attached in Section 19

8. Distributing the cluster responsibility and assigns drivers and drive test equipment to theoptimization engineers if needed on the daily basis,

9. Making the presentation slides based on the bmp files and KPI charts completed by the clusterowners, and

10. Optimization engineers report their weekly cluster KPIs and cluster report the optimizationLead

In the event that there is no NOKIA Optimization Consultant in the market, Partner Optimization Leadtakes up the responsibilities of the optimization consultant as well.

3.7 Optimization Engineer Cluster Owner

Takes complete responsibility of the cluster. Each optimization engineer should be capable ofperforming optimization of more than one cluster at the same time depending on cluster size.

1. Checks alarms for the cluster sites,

2. Checks daily NMS reports for the clusters,

3. Analyzes measurement data for the cluster,


6/33


6 (33)


6

4. Reports the deliverables to the Optimization Lead, and

5. Provides the bmp file and KPI charts for their clusters on time i.e. at least 5 working hoursbefore the delivery deadline.

3.8 Drive Tester

Drive teams are one-person teams. Person with local knowledge is recommended to do the drivetests. He/she is also responsible for the measurement system during driving. Depending on themarket size there are several measurement drive teams. After the completion of the Drive Test for theday, the drive tester saves the file into the server and informs the cluster owners (optimizationengineers) about the location. The drive testers contact the cluster owner (optimization engineer) fromthe field during the drive test in case of any problem.

3.9 Implementation Coordinator

Implementation coordinator is responsible for all hardware modifications and changes of the network.Hardware change requests are made by optimization engineers. Change requests are collected fromall the optimization engineers by the optimization Lead/ Network Planning Manager and passed on tothe implementation team.

3.10 Transmission Planning Support

This team supports the markets by checking the MSC Datafill. The planners in the markets send theMSC Datafill to the Transmission Planning Team based in Irving, Texas. If there is any problem, theDatafill is sent back to the market with the description of problem. If the Datafill is in the correctformat, Transmission Planners post it in the e-room.

3.11 NMS Support

There are mainly three entities at the RIC center. For any BTS issues, the BTS engineers at RIC canbe contacted. For BSC issues, the BSC engineers at RIC can be contacted. For any NetworkPlanning related issues, the Network Planners at the RIC Center can be contacted. The contactdetails of RIC RNW are:

E-mail: [email protected] RNW and [email protected] BTS and BSCLocation: Irving, TexasOperating hours: 9:00 a.m. - 9:00 p.m. (CST)Telephone: 1 866 665 4242 (ext. 1 for BTS assistance, 2 for BSC assistance and 3 for

RNW assistance.)

RIC RNW is responsible for all NMS reporting and he/she executes all the software modifications ofthe network via NMS interface. Setting of the automatic Network Doctor reporting is also part of NMSoperator responsibilities. RIC RNW sends the standard daily reports to the optimization team everymorning. In case of NMS connection problem, RIC RNW informs the markets about the delay.

Change requests and Network Doctor report requirements are received by RIC RNW via e-mail fromlocal optimization engineer. The requested reports and the response to change requests are sent tothe market as soon as it is completed.


7/33


7 (33)


7

In addition to RIC support, RIC RNW is also responsible to check the Datafill sent by the markets. Ifthere is any problem, the Datafill is sent back to the market with the description of problem. If theDatafill is in the correct format, RIC RNW forwards it to RIC implementation team.

3.12 AWS Local Market and Corporate

All the local market knowledge of AWS is needed while planning drive test routes. Close contactsduring optimization process with AWS personnel gives them a good future knowledge of the GSMnetwork. The networks market final acceptance is agreed by AWS and Nokia. The weeklyoptimization progress reports (see attachment Appendix IV, Section 17.4) are delivered to local andcorporate AWS teams and NOKIA management.

In addition, there are tasks such as communicating with the Project Manager and the integrationteam, Frequency Fine tuning, communicating with Bechtel, integration team, Nortel, local AWS teamand corporate AWS team. It is up to the Network Planning manager how he/she wants to handle ordelegate these tasks.

4. SCHEDULE

Drive test and optimization activities are started six weeks before network launch date in each market.AWS and Nokia agree on a schedule for the optimization process. Actual cluster optimization can bestarted when 80% of sites are integrated in each cluster. Pre-work activities as cluster- and routedefinitions and getting the drive test equipment to market should be done as early as possible. If it isnecessary to start optimization earlier, less than 80% of the sites integrated, clusters or drive routesmay be changed or modified for the purpose.

5. PROCESS FLOW

Figure 1 shows the process flow of the network drive tests and optimization before network launchwith one cluster being completed at a time.


8/33


8 (33)


8

Optimization Plan

Cluster Definition

Drive Route

Definition

Measurement

TOM, NMS

Drive Test Analysis /

NMS Report Analysis

Verification of

Site Readiness

Submit Cluster and complete network

KPI and Optimization

Summary to AWS

Cluster Analysis

Result

Re - Drive after

change Implementation

Continue the above

steps to meet the

KPIs within the target date

Make hardware and parameter

changes wherever needed

Figure 1. Optimization flowchart with one Cluster being complete at a time


9/33


9 (33)


9

Figure 2 shows the process flow of the network drive tests and optimization before network launchwith the clusters being worked on in parallel.

Optimization Plan

Cluster Definition

Drive Route

Definition

Measurement

TOM, NMS

Drive Test Analysis /

NMS Report Analysis

Verification of

Site Readiness

Submit Cluster and Network

KPIs and Optimization

Summary to AWS

Cluster Analysis

Result

Re - Drive after

change Implementation

Continue the Optimization of previous

clusters and start optimization of the

next clusters to meet KPI targets on time

Make hardware and parameter

changes wherever needed

Figure 2. Optimization flowchart with all Clusters being complete at the same time


10/33


10 (33)


10

6. GENERAL

Before any drive tests and optimization is performed the site readiness should be checked. Every sitegoes through the on-air verification. The network analysis and optimization is either done by clustersor simultaneously covering all the clusters depending on the implementation plan.

A cluster is a set of adjacent sites that are defined based on the sites' geographical location. Sites in acluster should belong to the same BSC if possible. If needed, the cluster border may cross the BSCborder. The reason for dividing the network in smaller areas is to make the optimization and follow-upprocesses easier. Optimization reporting to AWS is done on cluster basis and each cluster shouldmeet the KPI target by the end of Optimization. The actual optimization is performed in cell level. Theweekly optimization report consists of cluster Tracking sheet to make the follow up process easier.

7. PRE-CONDITIONS FOR OPTIMIZATION

7.1 Priliminary checks

Before starting any optimization activities in the network, the preliminary checks as listed belowshould be completed. RF Shakedown (On Air Verification), Drive Test and Optimization activities startonly after the following tasks are performed:

1. First step is to make sure that the NetAct frequency plan and the datafill frequencies matchsector for sector. Once the sites are built in the BSC, Optimization Engineers should performRF Datafill Implementation Audit. The audit should be done as soon as possible to verify thatnone of the BTSs are transmitting at frequency out of allocated band and that the parameterslisted below are exactly as the datafill or not.

TRX frequencies (BCCH and non BCCH),

BSIC (ncc and bcc),

BTS max power,

Cell ID

LAC

MAIO

HSN

Adjacencies

Optimization team should do the complete parameter audit on the network before the on airverification. Parameter audit should be done on the daily basis till the network ready day. NetworkDoctor Report 68 & 111, NetActPlanner export and Planedit dump from the NMS should be usedfor datafill audit and network parameter audit.

If NMS is not ready, data is extracted from the BSC via MML commands for audit. It is PartnerOptimization Leads responsibility to make sure that these checks are done on time and the statusis reported to the Network Planning Manager and the Optimization Consultant.

2. Antenna and cable installation should be checked by the implementation team,


11/33


11 (33)


11

3. BTS operability and timeslots should be checked by the implementation team by placing call ineach timeslot. This test verifies that calls are successful on all timeslots in the TRX. Observetest mobile display 1 row 2 column 1. When in idle mode, this field will be 0 indicating timeslot0. Make successive calls and note the timeslot number. The usual sequence will be 1, 3, 5, 7,2, 4,6 or (in a 2+2+2 config) 3,5,7,2,4,6. Every successive call will cause the timeslot toincrement in an even or odd sequence.

4. Uplink power control, Call setup, intra - site and inter site handovers checked byimplementation team,

7.2 On air verification

Once the above mentioned checks are done, On-Air verification should be performed on per sitebasis prior to optimization. These tests should be performed on every sector by the Optimization

Team. The process includes successful call origination and termination, intra-site handovers,frequency and BSIC verification. The checklist in section 18 should be used during the On AirVerification.

The problems noticed should be recorded in the problem description section and should be reportedto the Partner Optimization Lead and Nokia Optimization Consultant at the end of the day. Theoptimization lead should compile the list of hardware and parameter settings problem on the sameday. The parameter settings should be corrected immediately by sending change request to RICCenter. The hardware issues should be immediately communicated to the BTS team for correctiveactions as soon as possible (same day or the next day).

The following problems should be noted during On Air Verification:

1. Cable swap between the sectors (may result in interference)2. Site with MHA but no Bias T (poor uplink)3. Site with no MHA but Bias T (poor uplink)4. Incorrect azimuth for the site (dominance skewed)5. Sector with bad TRX (TRX output very low and very weak signal strength)6. Site having unstable T1 (Regular failure of calls)

If E911 call testing is arranged for with the local E911 call center, this test should be included in on airverfication test. E911 call needs to be placed on each sector with Step 1 below to verify that the call isbeing routed through the right call center.

The sites have emergency calls restricted and cells are barred by default when integrated. Hence, theintegration team should contact the integration center to temporarily remove the emergency callrestriction and cell bar option. After performing the following tests listed as 1-8, the parameters shouldbe turned back on such that emergency calls are restricted and all the cells are barred till the networkis launched.

1. Mobile Originated Call in all sectors (mobile to land, mobile to mobile).

2. Mobile Terminated Call in all sectors (land to mobile, mobile to mobile).

3. Confirm that the cell is transmitting at the correct FREQUENCY Display 1 on the test mobileindicates the channel no.

4. Check the BSIC (Base Station Identification Code) . Test mobile display 2

5. Check LAC, CID, MCC and MNC.. Test mobile display 11


12/33


12 (33)


12

6. MsPowerControl. Make sure that the feature is activated at the BSC (check with RFplanner/BSC engineer). Test mobile display 1, row 1, and last column. It will show XXX. Makea call within close proximity to the site (100-500 ft). Once the call has been connected observethe same field. The 1

st'X' changes to '*'. This indicates that the phone is transmitting. The

other 'X' changes to 0. As the call progresses, this field should increment to 123..4 andreach a stable state other than 0. This verifies that power control is working.

7. Intra-Site handover (between sectors). Start driving around the site in a clockwise direction.You should be handed over to the next sector. Confirm this by looking at the CI. Perform alltest (1-6) in this sector. Repeat the same process in an anti-clockwise direction.

8. To check if the uplink is working well, place call on the sector (step 1) at least 1.5 miles awayfrom the BTS

If the Core Network for GPRS is ready during this process, include the attach/detach test in step 1.

The attach/detach test should be performed in each sector.

In addition to all the above tests, the optimization engineers should do spot checking of 1 800 and 411calls in the network and make sure that it works in every BSC.

7.3 Manually locking onto a frequency Channel:

In certain situations to verify call set up success, co-channel interference etc., it may be necessary tomanually lock onto a channel at a particular site.

The following procedure can be used to lock on to a particular channel.

1. Make sure that 'Field Test' has been activated on the phone from the menu.

2. Edit the phone entry 'bts test'. This can be programmed by entering the frequency number inmemory location 31 in the test mobile.

3. Change the no. for 'bts test' to the channel that needs to be locked onto and save thechanges.

4. Press the MENU key and scroll to 'Field Test'. Hit 'Select'. The screen will change to Test 01.Change 01 to 17. Press OK. Wait 10 sec for screen to change to BTS Test Off. Power cyclethe phone. The display should be 'BTS TEST ON".

5. The phone will now lock onto the channel if you check Test mobile screen 01.

7.4 Cluster Definition And Naming

Clusters are created using approximately 10-30 adjacent sites (BTSs) or 30-90 sectors depending the

geography. All the sites in one cluster should belong to the same BSC if possible. The cluster namingis done alphabetically. E.g.

Cluster A

Cluster B

Cluster C

If the BSC boundaries are the same as cluster boundary i.e. if the BSC areas are very big, each BSC(cluster) should be divided into a number of sub-clusters for drive testing. However, for the simplicityof reporting, the sub-clusters should be combined into bigger clusters. For naming convention:


13/33


13 (33)


13

BSC1 = Cluster A comprising of sub-clusters A-1, A-2, A-3

BSC2 = Cluster B comprising of sub-clusters B-1, B-2, B-3, B-4BSC3 = Cluster C comprising of sub-clusters C-1, C-2

Mapinfo software is used to create clusters. Hard copies are generated of each cluster and filed intooptimization master database. The soft copies are saved to the local market server. The folderdirectory is: \Market\Quality\Optimization\Cluster##\

8. DRIVE TEST PROCESS

8.1 Preprocess

Optimization engineer defines the drive test routes. The drive routes are approved by the PlanningProject Manager and sent to AWS for approval. The comments from AWS are taken into

consideration and the final agreement is reached with the customer regarding Drive Routes. Theoptimization engineer does optimization according to the drive test measurements/results

Before doing any drive tests the site readiness have to be checked (See Section 7). OMC/NMS2000check is performed to detect if there is any trouble, outage or work orders to prevent the drive test.NMS/2000 alarm check and printout is also accomplished.

The Optimization consultant should also do the consistency check on neighbor list to make sure thatthe datafill has been implemented correctly. The optimization consultant should check all the basicconfiguration reports, e.g., 060 (Adjacency discrepancies), 061 (one way neighbor), 062 (co-channeland adjacent channel neighbors), 065 (adjacency to non existent cells, 067 (ho synchronization, 070(cells with minimum number of neighbors), 071 (cells with max neighbors), 074 (neighbor list) and 076(adjacencies with co BCCH, co BSIC).

Totem planning tool printouts of the dominance areas of the each cell and frequency plan are needed.Drive routes are designed by using Mapinfo 6.0 software. Printouts of the each drive route aregenerated and filed to the optimization master database. The soft copies are saved to the localmarket server in the following folder: \Market\Quality\Optimization\Cluster##\Planning

Drive routes are defined carefully before drive tests are started. Once drive route is defined the sameroute is used all the way during optimization process. Following things have to be taken into accountwhile planning the drive routes:

1. Max. duration of the drive test of the each cluster is 8 hrs per day. Still enough calls (>=200)

have to be generated during each drive tests to have reliable results,

2. Route design have to include all the sectors/cells of the cluster,

3. Handovers are measured in both ways (clockwise and anticlockwise) if possible,

4. All the highways and major roads are drive tested in the cluster, and

5. Areas and routes that are outside the predicted GSM coverage or are known to have poor

TDMA coverage will be excluded from the system drive test.

The table below lists coverage requirements for the both GSM and TDMA networks.


14/33


14 (33)


14

Coverage Area Type IS 136 RSSI Value GSM RSSI Value

Urban -75 dBm -77 dBmSuburban and Freeway -85 dBm -87 dBm

Rural service -95 dBm -97 dBm

Table 1. RSSI thresholds

Drive tests include measurements for both networks, TDMA850/1900 and GSM1900. For TDMA, onlythe RXLev and RXQual need to be measured and reported. In the markets where TDMA network is1900Mhz the drive route planning is straightforward. But market areas where TDMA is 850MHz thedrive route definition needs more careful planning because of the different cell size betweenTDMA850 and GSM1900 networks. Use of local AWS knowledge of the area and co-operation withthem is highly recommended while defining routes. AWS approval is needed for drive routes.Planning tool dominance area printouts are used to help defining drive routes.

8.2 Drive Test

Drive tests are performed in one-person team. Local people should be used for that job. Drive testerdoes the actual driving and also checks if the measurement system works properly during drive tests.The site information including azimuth and downtilt is checked visually during drive test if possible.The correct data is found from Totem planning tool database and the printouts are used whilechecking site information. Time spent on cluster drive test should not exceed 8 hrs per day per team.

Drive test system includes:

1. TOM Measurement software and laptop,

2. Measurement rack, power supply and connection cable to the laptop,3. GPS system connected to the laptop, and

4. 1 TDMA850/1900 mobile phone and 1 to 3 GSM1900 mobile phones.

At least one GSM phone and a TDMA phone should continue the call until it drops. The settings areas follows:

Call Duration = 9999 sec, Repeat = 999, Call Attempt timeout= 30 sec, Delay betweenend of call to attempt = 15 sec. This is only for coverage and quality purposes and notfor statistics.

At least one phone in call generator mode with the following settings:

Call Duration = 135 sec, Repeat = 999, Call Attempt timeout= 40 sec, Delay betweenend of call to attempt = 25 sec.

The above settings are identical to Comarco Drive test settings that are used to evaluate the NetworkPerformance.

During each drive, measurement system generates at least 200 GSM1900 calls to produce correctand reliable status of the current network quality. See the user manual of the TOM measurementsoftware how to setup and use the measurement system.

During drive test, driver checks failures of the measurement system and problems of the network (e.g.dropped calls). Driver makes notes if something fails during drive tests and reports to the optimizationengineer.


15/33


15 (33)


15

8.3 Post Processing

All the measurement files from the drive tests are saved to the local market server. The folder iscalled:

\Market\Quality\Optimization\Cluster##\\Date(mmddyy)\ GSM \Trace\A1.##_Date

\Market\Quality\Optimization\Cluster##\\Date(mmddyy)\ GSM \Call Gen\A1.##_Date

\Market\Quality\Optimization\Cluster##\\Date(mmddyy)\ TDMA\Trace\A1.##_Date

1. "Drive Test Problem - PerformanceTracking" spreadsheet needs to be filled after every drivetest, see Appendix IV. The spreadsheet is located at local market server:

\Market\Quality\Optimization\Cluster##\Reports

2. The report called "Quality Survey Report" is generated with SAM analyzing software, seeAppendix I. All the measurement files from drive tests for the cluster are combined to generatethis report. These reports are saved to the local market server in following folders:

\Market\Quality\Optimization\Cluster##\Reports\mmddyy.xls

3. There is a form called "Optimization Summary", see Appendix IV that needs to be completedweekly. The tables need to be filled with information from the Quality Survey Report. Bottomtable of the report is filled by the data from the NMS2000 Network Doctor reports. This form isalso saved into the following drive and is delivered to AWS weekly as mentioned in Section3.11.

\Market\Quality\Optimization\Cluster##\Reports\OptimizationSummaryReport_Wk##.doc

All three reports are generated by optimization engineer with help of drive test teams.

9. CLUSTER ANALYSIS

Analysis of the cluster is done by SAM software, drive test measurements, and use of Network Doctorreports and OMC data. See SAM user guide for data analysis software usage and Section 9.4 forNetwork Doctor reporting.

9.1 Analysis Process

Process for measurement analysis is as follows:

1. Run the Quality Survey Report,

2. Analyze the drive test measurements,

3. Analyze the handover between cells,

4. Check Rx Level and Rx Quality value, and

5. Analyze Network Doctor Reports

DL Quality criteria applied to the system drive test results is RXQUAL 4 in 95 % of the samples.

See Section 10 for detailed quality criteria definitions approved by AWS and Nokia.

Appendix III shows flowcharts for typical network problems and how to proceed to fix the problems.In the event the above quality criteria are not met, Nokia will provide equipment to mitigate theproblem, but not exceeding 2% of the installed BTS base.


16/33


16 (33)


16

From these studies RF planner comes to the conclusion to execute modifications to the network. Ifeverything is performing according to predefined network criteria planner signs off the clusteroptimization and fills the "Cluster Sign Off" form, approved by AWS, and proceeds to the next cluster.The "Cluster Sign Off " form is saved in the common server.

\Market\Quality\Optimization\Cluster##\Reports\ClusterSignOff.doc

9.2 Modifications

The first thing is to identify if the problem detected is hardware or a software problem. Hardwareproblem can be for example tilting, azimuth, cables, timeslots, and frequencies. Software problem canbe for example RX-level, RX-quality, handover failures, call setup problems or drop calls.

The second step is to define a solution for the problem. It is very important to remember that amodification to solve a particular problem can create another problem in another area of the cluster.

Any change requests are first checked by the optimization lead. The optimization lead alwaysconsults with NOKIA optimization consultant for any network wide change. After the modifications areaccepted they are e-mailed to RIC RNW ([email protected]). After the implementation, RIC RNWsends immediate response. For any network wide changes, the NOKIA optimization consultant shouldbe consulted and the Network Planning Market manager should be informed.

The RIC RNW request should have the standard format as shown in Appendix IV.

Form "HW Change Request.doc", see Appendix IV, is used for hardware change requests. It is givento implementation team after optimization Lead/Consultants approval. Own copy is saved to server.

\Market\Quality\Optimization\Cluster##\HWChangeRequests\

There should be seamless communication between the optimization lead and NOKIA optimizationconsultant and the Network Planning Market manager should be continuously updated of theoptimization progress.

Optimization progress and analysis reporting is reviewed by AWS. The loop of measurement,analyzing and modifications is repeated until QoS of the network requirements are fulfilled andaccepted by AWS.

9.3 Intercluster Verification

To perform intercluster optimization at least two adjacent clusters should have common border. Thepurpose of intercluster verification is to check that the performance of the system (mainly handovers)

is good in the border area between the clusters. Hence, the drive routes are planned for each clusterin such a way that it covers at least one tier of cells in the surrounding clusters.

9.4 Network Doctor Reporting

The Network Doctor report scripts are executed to give more info of network performance from NSSpoint of view. These reports come from NMS2000/5000. The list of daily reports is as shown in

Appendix II.

Alarm report 27 is to be checked before any drive tests. There is more information about the usableNetwork Doctor report scripts in Appendix II.


17/33


17 (33)


17

27: Alarm Report (run before the drive)204: Network Benchmark stats (run after the drive)800: Quality survey (run after the drive)

If any additional reports are needed, the requests are sent to RIC RNW. There is example of "NetworkDoctor report request", see Appendix IV. Request e-mail includes report number, when reportgeneration happens and for what period etc.

10. QUALITY OF SERVICE CRITERIA, KPI FACTORS

Table 2 below shows the quality criteria of the network agreed by AWS and Nokia. Target networkcriteria calculations formulas are same as Network Doctor report 204 uses.

Table 2. Statistical Performance Criteria

Criteria Target

Retainability (100 - Dropped Calls) % 98%

Accessibility (Call Setup Success Rate) % 94%

Voice Quality (RXQUAL) 4 in 95 % of the samples

10.1 Retainability (Call Success Rate, 1-TCH Drop Call Ratio) (%)

Acceptable Retainability should be more than 98% over the network. Retainablility (CSR) = 100% -DCR%.

10.2 Downlink Quality (%)

The GSM Quality is categorized in 8 different classes based on received Bit Error Ratio (BER). In thequality measurements the measured samples are cumulatively shared in different classes.

Acceptable cumulative Downlink RX Quality is classes 05 of 95% of the time. AWS requirement isto have more than 95% of samples in quality 04.

10.3 Accessibility or Call Setup Success Ratio

Within the coverage area when requested by user, ratio of successful SDCCH reservations and madecall attempts.

Acceptable CSSR value in general is 95% and excellent value is 99%. AWS requirement is to have

accessibility or CSSR of 94% accessibility.

10.4 Coverage (% of time), Downlink Level

Within the coverage area the received downlink signal is measured to define if the recommendedsignal threshold is reached.

Acceptable Downlink Link level's value of time in general is 95% and excellent value is 99%.In AWS 3G Project there is no terms for meeting coverage thresholds.


18/33


18 (33)


18

10.5 Handover Success Ratio

Within the coverage area, ratio of successful handovers and handover attempts.Acceptable HOSR value in general is 95% and excellent value is 99%.In AWS 3G Project there is no terms for meeting handover threshold but we should have an internaltarget of 98%.

11. DOCUMENT DELIVERY

Optimization Summary report is delivered to AWS RF engineer once a week, see file "OptimizationStatus Report.Doc". Final reporting includes Quality Survey report with all agreed QoS criteria,Optimization Summary report and Drive Route-, Cluster- and Coverage maps saved to the CD-ROMand delivered to the AWS after all clusters are finished and approved by AWS. File format is Mapinfo6.0 compatible for all graphical data.

Final detailed reporting:

1. Drive routes including DL RXLEV level (thresholds -77dBm in Red, -87dBm in Yellow, -97dBm in Green, -102dBm in Blue and anything


19/33


19 (33)


19

13. RELATED DOCUMENTS

Following documents are used for optimization process tracking purposes.

Drive Test Problem Cluster#Tracksheet.xls All the info during drive test measurements,network and measurements problems, solutionsand actions taken are included in this file. Updatedafter every test drive.

Optimization Status Report.doc Weekly filled with drive test and NMS qualitycriteria values. Delivered to AWS weekly.

Network Doctor Report.xls Spreadsheet includes list of Network Doctorreports what are useful during optimizationprocess.

HW Change Request Form.doc All the hardware change requests are made using

this form. Form is send to implementation team.


20/33


20 (33)


20

14. APPENDIX I : ANALYZING SOFTWARE REPORT

The data collected from the drive test equipment is post processed using Nemos SAM software.Quality survey report is generated from the collected data. A sample is shown below. The highlightedfields are used to update the Optimization Summary table shown in Appendix IV. This reporting isperformed for AWS GSM1900 network only.SAM 2.22 Nemo Technologies 13/9/2001 19:07

QUALITY SURVEY for GSM

NETWORK: AWSSERVICE AREA: Las VegasSURVEY START: 10/9/2001 8:44SURVEY END: 13/9/2001 17:55

Downlink Quality

0 1 2 3 4 5 6 7

62.4 71.3 80.8 88.5 95.4 96.9 98.8 100 %

Serving Downlink Level5 25 50 75 90 95 98 100 %

-51 -65 -75 -82 -88 -90 -93 -111 dBm

System Response Time

4 5 6 7 8 10 12 30 seconds

94.9 96.3 97.1 97.6 98.3 99.9 100 100 %

MS Output Power Level

15 14 13 12 11 10 9 8

3.4 4.6 6.1 7.9 9.9 12.2 15.1 18.1 %7 6 5 4 3 2 1 0

21.4 25.3 29.7 35.4 42.4 50.1 59.9 100 %

Number Of Handovers Per Call0 1 2 3 4 5 6 7

34.3 63.4 81.7 89.6 93.6 96.7 98.6 100 %

Time From Response/Handover To Next Handover

3 5 10 15 20 30 60 120 seconds

10.9 31.9 47.7 62.7 70.9 82.2 99.3 100 %

Call Length From TCH Assignment

5 7 10 15 30 60 90 120 seconds

0.4 0.4 1.1 2 4.3 6 100 100 %

CALLS

Attempts 846 (Call Attempts)

Failures 2 (Call Attempt Failures)Connections 700 (Successful TCH Connections)Dropped 24 (Calls Dropped after TCH Connection)Disconnects 676 Calls Disconnected b the Measurement S stem

Attempt Success Rate 99.7 % (TCH Connections/ (Call attempts - Measurement Failures))Drop Call Rate 3.4 % (Dropped/Connections)

Measurement Failures 144 (Unsuccessful Call Attempts Caused by Measurement System)

HANDOVERS Inter: HO between cells, Intra: HO in the same cell, System: HO between bands/systems

Inter Intra System Total

Attempts 752 273 0 1025 (Handover Attempts)Completes 727 269 0 996 (Successful Handovers)Fails 24 4 0 28 (Handover Failure, return to old channel)Dropped 0 0 0 0 Call dro ed durin Handover Success Rate 96.7 98.5 0 97.2 % (Handover Completes/ Handover Attempts)

Conducted by: Approved by:


21/33


21 (33)


21

15. APPENDIX II: DAILY NETWORK DOCTOR REPORTS

022 Active Base Station alarms

027 Cell outages breakdown over 10 days

042 Radio network ordered by BSC, BCF, BTS

043 Cells with LAC and cell id

050 Find locked BCFs, BTSs, TRXs and channels

060 Adjacency discrepancies

061 Non-symmetrical adjacencies

062 Adjacent cells with same or adjacent frequency

065 Adjacencies to non-existing or foreign cells

067 HO synchronization068 BTS parameter survey

069 Adjacent cell double frequencies

070 BTS with max number of adjacencies

071 BTS with min number of adjacencies

074 Adjacencies of cells. Long output if big area selected

076 Adjacent cells of a cell having same NCC, BCC, freq

090 Network configuration summary

111 Frequency plan

134 Cells having RACH rejections

150 Cells having high HO failure ratio153 Adjacencies having high HO failure ratio

154 Handover cause distribution, by cells

163 Cells having high TCH Dropout or Drop Call ratio

166 SDCCH Drop ratio per cell

190 Cells having UL interference, 24-hour/10-day breakdowns

195 TRXs by DL,UL level balance

197 UL and DL quality per TRX

204 Network benchmark statistics. Heavy, use small area

800 Quality Survey


22/33


22 (33)


22

16. APPENDIX III: CALL AND HANDOVER TROUBLESHOOTING CHARTS

Any

Alarms in

problem

period?

Is it RF

related

Any

recent change on

Neighbor List or

Frequency

Plan?

Check the severity of

the alarm

Correct the fault

situation.

Check is service

affecting problem.

Is the link

balanced?

(195)

Is the DL

worse?

Check receiver path

incl receiver, cables,

LNAs, connectors.

Is UL/DL having

high B.E.R.

Is the cell serving

an area it should

not serve? (213)

1

Is DL bad

because of

interference?

Make

modifications:

Downtilts/

Azimuths.

Check Frequency Plan

Check TRX.

Check

for all neighbor

relations and

discrepancies

Check 213 (Cell

Doctor) and 216 (Cell

Analyzer)

Drive Test area and

analyze.

Check (213) level quality

matrix (cell doctor).

Check for coverage

holes.

Is

there UL

interference?

(190)

Any alarms insurrounding area? 1

Check transmitter path

incl transmitter.

YES

NO

YES

YES

YES

YESNO

NO

YES

NO

YES

NO

YES YES

NOYES

NO

Area Hi Drop Call Rate

NO

In-band

interferance?

Check Frequency

Plan.

External

interference?

Drive Test.

Spectrum

Analyzer .

Check Receiver

Check TRX.

YES

NO


23/33


23 (33)


23

Check the neighbor listto see is any neighbors

are missing.

Are HO fai ls

outgoing?(150)

Is reason

blocking?

(150)

Check (153) to find theproblematic

relationship.

Is the failure

100%?

Check (154) Reason of HO.

Is the failure

100%?

Check (135) to see if

there is real TCHblocking in target and

source.

More

TRX's

needed

Check the site alarms(e.g. transmission) of

target and source.

Check neighbor list -

could be same BSIC

same frequency.

Check (60)Discrepancy Report.

Check (213/216)

Quality Matrix.

Check (196)

UL/DL Quality.

NO

YES

NO

YES

NO

YES

NO

YESProblem is atthe target cell.

High HO Failures

Check (153) to find

the problematic

relationship.

NO

YES


24/33


24 (33)


24

17. APPENDIX IV: FORMS FOR OPTMIZATION PROCESS

17.1 Parameter Change Request

Here is example how Software change request looks. This is e-mailed to NMS operator. There isalways a reply from NMS operator that request has been received.

Subject: Market -Request to change parameters Date of request (mmddyy) Time of request(CST)

For example:

Chicago-Request to change RxLevMinCell11/28/01 3:00pm CST

Detroit-Request to change RadioLinkTimeout11/26/01 2:40pm CST

The following form is used for change request


25/33

Market:

Name:

Phone:

Date:

Modifications

BSC_ID BCF_ID BTS_ID BTSName Parameter Old value New value Parameter Old value New value Parameter Old

value

New

value

LSVGBSC04 21 60 LASVNVL113A Channel/TRX1 588 606 NCC 2 3 BCC 3 7

LSVGBSC03 14 41 LASVNVL027B riority in TCH All (Beyond BCCH 1 (From BCCH)

Adjacencies

BSC_ID BCF_ID BTS_ID BTSName BSC_ID BCF_ID BTS_ID BTSName

CREATE BIDIRECTIONAL LSGVBSC04 16 47 LASVNVL048C LSVGBSC04 16 46 LASVGNVL048A

MODIFY BIDIRECTIONAL LSGVBSC04 10 29 LASVNVL100B LSVGBSC04 9 27 LASVGNVL130C O Power Margin Budge 6 4

Comments

NOK

Parameter

CHANGE REQUEST to RIC RNW(Dallas)

Notice that TSC must have the same value as BCC.

Purpose ClassSource Target Old

value

New

value

11/10/2001

Las Vegas

Mr. Gambler

777 777 7777


26/33

PRE-LAUNCH OPTIMIZAT IONGUIDELINE REV 4

26 (33)

Network Planning/ NET Mar 15, 2002

17.2 Network Doctor Request

This is an example of Network Doctor report request. This is e-mailed to RIC RNW with Subject line of emaas:MarketRequest for ND Report ## Date of request [mmddyy] Time of Request [##:## am/pm] CSTFor example:Tampa-Request for ND Report 063 11/28/01 3:00pm CST

West Palm Beach-Request for ND Report 232 11/26/01 3:00pm CST

In Addition, the following information should be provided in the request

Cluster/BSC/Network:

Reporting Start Date and Time:

Reporting End Date and Time:

Comments:

Optimization Engineer:

If the request fulfillment is going to take long, RIC RNW sends the response that request has been receivedand that the estimated time for the task completion.


27/33


27 (33)


17.3 Hardware Change Request Form

GSM1900 OPTIMIZATION CHANGE REQUEST

HARDWARE

City/Market Site ID

Site Name Cell ID (LAC, CI)Cluster No Date

Problem Description:

Element Old Status/Value New Status/ValueTilt

AzimuthCables

Complete Checking of the Site Yes/No

Comments:

Requested By Date

Modified By Date


28/33


28 (33)


17.4 Optimization Summary Report

OPTIMIZATION SUMMARY

City/Market Cluster Number

Responsible Date

The following table outlines the TOM performance figures for this GSM1900cluster (per drive):

DriveDate

DateAnalyzed

# ofCalls

# ofCheckedsites

Accessibility orSuccessfulCall Setup %

Retainability =(100 - DroppedCalls) %

% DL Quality0-4

The following table outlines the OMC performance figures for this GSM1900cluster (per week):

Report

Date

Accessibility or

Call SetupSuccess Rate((csf_1a) * (csf_2d)* (csf_3))

%

Retainability =(100- Drop CallRate (dcr_8b))

% DL Quality

0-4

% UL Quality 0-4


29/33


29 (33)


17.5 Cluster Sign Off report

GSM1900 CLUSTER SIGN OFF FORM

Region Western California/HI

North East Southern

City/Market

Date Cluster Number

Performance details

Performance Indicator Comments

Retainability 98%

98%

The Retainability figure is = %

Accessibility 94%

94%

The Accessibility figure is = %

Quality 04 95%

95%

Quality 04 figure is = %

Comments onproblems affectingKPIs adversely

Checks ND Report Status CommentsAdjacency discrepancy ND 060 Clear Not clear

Non symmetrical adjacency ND 061 Clear Not clear The reason for existing non-symmetricalneighbors is

Co-Channel neighbors ND 062 Clear Not clear

Adj to non-existent cells ND 065 Clear Not clear

Handover synchronization ND 067 Clear Not clear

Cell with maximum number

of adjacencies

ND 070 Clear Not clear

Cell with minimum numberof adjacencies


Adjacencies with the sameBCCH and BSIC


Frequency/ LAC/ CI Audit ND 111 Clear Not clear

Parameter Survey and

audit

ND 068 &

ND 063Clear Not clear For detailed description please refer to

parameter audit report

NOKIA Optimization

EngineerDate

NOKIA Market OptimizationTeam Lead

Date

AWS ApprovalDate


30/33


30 (33)


18. ON AIR VERIFICATION CHECK LIST

Optimization Engineer (Full Name and Signature)

Date

Market Name BSC Name BTS Name Sector Azimuth

Parameter BCCHFrequency

TCHFrequency

NCC BCC LAC CI MCC MNC MAIO HSN

Plannedvalue fromDatafillActualvalue inthefield

Actions in Sector A Status Actions in Sector A Status

MOC (mobile to land)OK

NOKMTC (mobile to mobile)

OK

NOK

MOC (mobile to mobile) OKNOK

GPRS Attach OKNOK

Call Setup E911OK

NOKHandover to Sector B

OK

NOK

MTC (land to mobile)OK

NOKHandover from sector B

OK

NOK

BSIC of neighborsdecoded

OK

NOKUplink Power control

OK

NOK

Checked By:

Optimization Team Lead (Full Name and Signature)

Date



31/33


31 (33)


Optimization Engineer (Full Name and Signature)Date



TCHFrequency


Plannedvalue from

DatafillActualvalue inthefield

Actions in Sector B Status Actions in Sector B Status



OK

NOK

MOC (mobile to mobile)OKNOK

GPRS AttachOKNOK

Call Setup E911OK

NOKHandover to Sector C

OK

NOK


NOKHandover from sector C

OK

NOK


OK


OK

NOK

Checked By:


Date



32/33


32 (33)


Optimization Engineer (Full Name and Signature)

Date



TCHFrequency


Planned

value fromDatafill

Actualvalue inthefield

Actions in Sector C Status Actions in Sector C Status



OK

NOK

MOC (mobile to mobile)OK

NOK

GPRS AttachOK

NOKCall Setup E911

OK

NOKHandover to Sector A

OK

NOK


NOKHandover from sector A

OK

NOK


OK


OK

NOK

Checked By:


Date



33/33


33 (33)


19. PARAMETER AUDIT REPORT TEMPLATE

20. DOCUMENT REVISION HISTORY

Date Version Author Approved By Summary of Changes

04/16/2001 1.0 Markku Pulli Karl Quattrochi Original Document

Date Version Edited by Approved By Summary of Changes

11/26/2001 2.0 Jeni R. Modification in resource requirementand task responsibility.

Details of on air verification addedreferring to the documentshakedown.doc

Modification of optimization processbased on previous AWS optimizationproject experience and the newrequirements.

02/28/2002 3.0 Jeni R. Modification in On Air VerificationProcess, section 7 and 7.1.

Addition of check list for on air section18 verification

Addition of parameter audit in section3.6

Addition of parameter audit template insection 19

03/15/2002 4.0 Jeni R. Modification of Cluster Sign Off form insection 17.5 to include consistencychecks and parameter audit.

AWS ParameterAudit Report Rev 1 M

Documents

AWS Optimization Guidelines Rev 4 Mar 15 2002