aws optimization guidelines rev 4 mar 15 2002
TRANSCRIPT
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
1/33
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
3/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
3 (33)
Network Planning/NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
4/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
4 (33)
Network Planning/NET Mar 15, 2002
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.
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
5/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
5 (33)
Network Planning/NET Mar 15, 2002
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,
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
6/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
6 (33)
Network Planning/NET Mar 15, 2002
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.
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
7/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
7 (33)
Network Planning/NET Mar 15, 2002
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/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
8/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
8 (33)
Network Planning/NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
9/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
9 (33)
Network Planning/NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
10/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
10 (33)
Network Planning/NET Mar 15, 2002
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,
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
11/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
11 (33)
Network Planning/NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
12/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
12 (33)
Network Planning/NET Mar 15, 2002
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:
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
13/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
13 (33)
Network Planning/NET Mar 15, 2002
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.
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
14/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
14 (33)
Network Planning/NET Mar 15, 2002
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.
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
15/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
15 (33)
Network Planning/NET Mar 15, 2002
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.
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
16/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
16 (33)
Network Planning/NET Mar 15, 2002
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.
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
17/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
17 (33)
Network Planning/NET Mar 15, 2002
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.
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
18/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
18 (33)
Network Planning/NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
19/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
19 (33)
Network Planning/NET Mar 15, 2002
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.
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
20/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
20 (33)
Network Planning/NET Mar 15, 2002
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:
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
21/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
21 (33)
Network Planning/NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
22/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
22 (33)
Network Planning/NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
23/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
23 (33)
Network Planning/NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
24/33
PRE-LAUNCH OPTIMIZATIONGUIDELINE REV 4
24 (33)
Network Planning/NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
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.
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
27/33
PRE-LAUNCH OPTIMIZAT IONGUIDELINE REV 4
27 (33)
Network Planning/ NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
28/33
PRE-LAUNCH OPTIMIZAT IONGUIDELINE REV 4
28 (33)
Network Planning/ NET Mar 15, 2002
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
29/33
PRE-LAUNCH OPTIMIZAT IONGUIDELINE REV 4
29 (33)
Network Planning/ NET Mar 15, 2002
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
ND 071 Clear Not clear
Adjacencies with the sameBCCH and BSIC
ND 076 Clear Not clear
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
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
30/33
PRE-LAUNCH OPTIMIZAT IONGUIDELINE REV 4
30 (33)
Network Planning/ NET Mar 15, 2002
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
Problem Description:
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
31/33
PRE-LAUNCH OPTIMIZAT IONGUIDELINE REV 4
31 (33)
Network Planning/ NET Mar 15, 2002
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 from
DatafillActualvalue inthefield
Actions in Sector B Status Actions in Sector B Status
MOC (mobile to land)OK
NOKMTC (mobile to mobile)
OK
NOK
MOC (mobile to mobile)OKNOK
GPRS AttachOKNOK
Call Setup E911OK
NOKHandover to Sector C
OK
NOK
MTC (land to mobile)OK
NOKHandover from sector C
OK
NOK
BSIC of neighborsdecoded
OK
NOKUplink Power control
OK
NOK
Checked By:
Optimization Team Lead (Full Name and Signature)
Date
Problem Description:
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
32/33
PRE-LAUNCH OPTIMIZAT IONGUIDELINE REV 4
32 (33)
Network Planning/ NET Mar 15, 2002
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
Planned
value fromDatafill
Actualvalue inthefield
Actions in Sector C Status Actions in Sector C Status
MOC (mobile to land)OK
NOKMTC (mobile to mobile)
OK
NOK
MOC (mobile to mobile)OK
NOK
GPRS AttachOK
NOKCall Setup E911
OK
NOKHandover to Sector A
OK
NOK
MTC (land to mobile)OK
NOKHandover from sector A
OK
NOK
BSIC of neighborsdecoded
OK
NOKUplink Power control
OK
NOK
Checked By:
Optimization Team Lead (Full Name and Signature)
Date
Problem Description:
-
8/12/2019 AWS Optimization Guidelines Rev 4 Mar 15 2002
33/33
PRE-LAUNCH OPTIMIZAT IONGUIDELINE REV 4
33 (33)
Network Planning/ NET Mar 15, 2002
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