You are on page 1of 33

PRE-LAUNCH OPTIMIZATION PROCESS GUIDELINE

FOR

AWS 3G GSM NETWORK





NOKIA NETWORKS









RADIO NETWORK PLANNING
























PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 ............................................................................................................................................10
7. 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 .......................................................................................................................15
9. 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


PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
3 (33)

Network Planning/NET Mar 15, 2002



3
10.2 Downlink Quality (%) ............................................................................................................17
10.3 Accessibility or Call Setup Success Ratio............................................................................17
10.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



PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 performed
before and during the network launch. This document is based on experiences from earlier network
planning projects including experiences from previous AWS 3G optimization project. This document
gives general guidelines on how to optimize and analyze GSM network performance, and is
customized for AWS 3G turnkey project.

2. SCOPE
Network Optimization process is a continuous and iterative process of improving overall network
quality. The objective of the optimization in a turnkey project is to verify that the plan is implemented
correctly. Any problems encountered are corrected to make sure that the network meets the
acceptance criteria defined in the contract. The basic tools used are NMS2000 and Drive Test
Measurement and Analysis Tool.

3. RESOURCES
To optimize network in proper manner, it demands resources of different skills. Everyone has his or
her 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 Consulting
during 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, Western
Region, Great Lakes and New York Region and Southern Region. Each Region has a nominated
regional 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 the
right 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, the
market planning manager takes care of the following issues:

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

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


PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 if
any changes are needed,
3. Providing support to the NP manager in both technical and management issues as and when
required,
4. Helping cluster owners analyze data and troubleshoot in the field as and when needed, and
5. 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 consultant
as 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 Optimization
Consultant,
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 Network
ready date using the template attached in Section 19
8. Distributing the cluster responsibility and assigns drivers and drive test equipment to the
optimization engineers if needed on the daily basis,
9. Making the presentation slides based on the bmp files and KPI charts completed by the cluster
owners, and
10. Optimization engineers report their weekly cluster KPIs and cluster report the optimization
Lead
In the event that there is no NOKIA Optimization Consultant in the market, Partner Optimization Lead
takes 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 of
performing 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,


PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 hours
before the delivery deadline.


3.8 Drive Tester
Drive teams are one-person teams. Person with local knowledge is recommended to do the drive
tests. He/she is also responsible for the measurement system during driving. Depending on the
market size there are several measurement drive teams. After the completion of the Drive Test for the
day, the drive tester saves the file into the server and informs the cluster owners (optimization
engineers) about the location. The drive testers contact the cluster owner (optimization engineer) from
the 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 from
all the optimization engineers by the optimization Lead/ Network Planning Manager and passed on to
the implementation team.

3.10 Transmission Planning Support
This team supports the markets by checking the MSC Datafill. The planners in the markets send the
MSC Datafill to the Transmission Planning Team based in Irving, Texas. If there is any problem, the
Datafill is sent back to the market with the description of problem. If the Datafill is in the correct
format, 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 can
be contacted. For BSC issues, the BSC engineers at RIC can be contacted. For any Network
Planning related issues, the Network Planners at the RIC Center can be contacted. The contact
details of RIC RNW are:

E-mail: ric.rnw@nokia.com for RNW and ric.usa@nokia.com for BTS and BSC
Location: Irving, Texas
Operating 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 of
the network via NMS interface. Setting of the automatic Network Doctor reporting is also part of NMS
operator responsibilities. RIC RNW sends the standard daily reports to the optimization team every
morning. 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 from
local optimization engineer. The requested reports and the response to change requests are sent to
the market as soon as it is completed.



PRE-LAUNCH OPTIMIZATION
GUIDELINE 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. If
there is any problem, the Datafill is sent back to the market with the description of problem. If the
Datafill 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 contacts
during optimization process with AWS personnel gives them a good future knowledge of the GSM
network. The networks market final acceptance is agreed by AWS and Nokia. The weekly
optimization progress reports (see attachment Appendix IV, Section 17.4) are delivered to local and
corporate AWS teams and NOKIA management.

In addition, there are tasks such as communicating with the Project Manager and the integration
team, Frequency Fine tuning, communicating with Bechtel, integration team, Nortel, local AWS team
and corporate AWS team. It is up to the Network Planning manager how he/she wants to handle or
delegate 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 be
started when 80% of sites are integrated in each cluster. Pre-work activities as cluster- and route
definitions and getting the drive test equipment to market should be done as early as possible. If it is
necessary to start optimization earlier, less than 80% of the sites integrated, clusters or drive routes
may 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 launch
with one cluster being completed at a time.



PRE-LAUNCH OPTIMIZATION
GUIDELINE 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


PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 launch
with 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



PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 site
goes through the on-air verification. The network analysis and optimization is either done by clusters
or 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 a
cluster should belong to the same BSC if possible. If needed, the cluster border may cross the BSC
border. The reason for dividing the network in smaller areas is to make the optimization and follow-up
processes easier. Optimization reporting to AWS is done on cluster basis and each cluster should
meet the KPI target by the end of Optimization. The actual optimization is performed in cell level. The
weekly 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 below
should be completed. RF Shakedown (On Air Verification), Drive Test and Optimization activities start
only after the following tasks are performed:

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

TRXfrequencies (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 air
verification. Parameter audit should be done on the daily basis till the network ready day. Network
Doctor Report 68 & 111, NetActPlanner export and Planedit dump from the NMS should be used
for datafill audit and network parameter audit.
If NMS is not ready, data is extracted from the BSC via MML commands for audit. It is Partner
Optimization Leads responsibility to make sure that these checks are done on time and the status
is reported to the Network Planning Manager and the Optimization Consultant.

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



PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 in
each timeslot. This test verifies that calls are successful on all timeslots in the TRX. Observe
test mobile display 1 row 2 column 1. When in idle mode, this field will be 0 indicating timeslot
0. 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 to
increment in an even or odd sequence.

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

7.2 On air verification
Once the above mentioned checks are done, On-Air verification should be performed on per site
basis 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 Air
Verification.

The problems noticed should be recorded in the problem description section and should be reported
to the Partner Optimization Lead and Nokia Optimization Consultant at the end of the day. The
optimization lead should compile the list of hardware and parameter settings problem on the same
day. The parameter settings should be corrected immediately by sending change request to RIC
Center. The hardware issues should be immediately communicated to the BTS team for corrective
actions 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 air
verfication test. E911 call needs to be placed on each sector with Step 1 below to verify that the call is
being routed through the right call center.

The sites have emergency calls restricted and cells are barred by default when integrated. Hence, the
integration team should contact the integration center to temporarily remove the emergency call
restriction and cell bar option. After performing the following tests listed as 1-8, the parameters should
be turned back on such that emergency calls are restricted and all the cells are barred till the network
is 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 mobile
indicates 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


PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 RF
planner/BSC engineer). Test mobile display 1, row 1, and last column. It will show XXX. Make
a call within close proximity to the site (100-500 ft). Once the call has been connected observe
the 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 and
reach 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 all
test (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 away
from 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 411
calls 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 to
manually 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 in
memory location 31 in the test mobile.
3. Change the no. for 'bts test' to the channel that needs to be locked onto and save the
changes.
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 cycle
the 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 naming
is 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 simplicity
of reporting, the sub-clusters should be combined into bigger clusters. For naming convention:



PRE-LAUNCH OPTIMIZATION
GUIDELINE 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-4
BSC3 = 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 into
optimization master database. The soft copies are saved to the local market server. The folder
directory 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 Planning
Project 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. The
optimization 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/NMS2000
check 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 that
the datafill has been implemented correctly. The optimization consultant should check all the basic
configuration reports, e.g., 060 (Adjacency discrepancies), 061 (one way neighbor), 062 (co-channel
and 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 are
generated and filed to the optimization master database. The soft copies are saved to the local
market 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 same
route is used all the way during optimization process. Following things have to be taken into account
while 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.




PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 dBm
Suburban 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, only
the RXLev and RXQual need to be measured and reported. In the markets where TDMA network is
1900Mhz the drive route planning is straightforward. But market areas where TDMA is 850MHz the
drive route definition needs more careful planning because of the different cell size between
TDMA850 and GSM1900 networks. Use of local AWS knowledge of the area and co-operation with
them 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 tester
does 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 while
checking 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 are
as follows:

Call Duration = 9999 sec, Repeat = 999, Call Attempt timeout= 30 sec, Delay between
end of call to attempt = 15 sec. This is only for coverage and quality purposes and not
for 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 between
end of call to attempt = 25 sec.
The above settings are identical to Comarco Drive test settings that are used to evaluate the Network
Performance.
During each drive, measurement system generates at least 200 GSM1900 calls to produce correct
and reliable status of the current network quality. See the user manual of the TOM measurement
software 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 optimization
engineer.


PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 is
called:
\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 drive
test, 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, see
Appendix I. All the measurement files from drive tests for the cluster are combined to generate
this 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 completed
weekly. The tables need to be filled with information from the Quality Survey Report. Bottom
table of the report is filled by the data from the NMS2000 Network Doctor reports. This form is
also saved into the following drive and is delivered to AWS weekly as mentioned in Section
3.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 Doctor
reports and OMC data. See SAM user guide for data analysis software usage and Section 9.4 for
Network 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 the
problem, but not exceeding 2% of the installed BTS base.


PRE-LAUNCH OPTIMIZATION
GUIDELINE 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. If
everything is performing according to predefined network criteria planner signs off the cluster
optimization 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. Hardware
problem can be for example tilting, azimuth, cables, timeslots, and frequencies. Software problem can
be 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 a
modification 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 always
consults with NOKIA optimization consultant for any network wide change. After the modifications are
accepted they are e-mailed to RIC RNW (ric.rnw@nokia.com). After the implementation, RIC RNW
sends immediate response. For any network wide changes, the NOKIA optimization consultant should
be 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 given
to 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 optimization
consultant and the Network Planning Market manager should be continuously updated of the
optimization 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 and
accepted by AWS.

9.3 Intercluster Verification
To perform intercluster optimization at least two adjacent clusters should have common border. The
purpose 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 cluster
in 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 NSS
point 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 usable
Network Doctor report scripts in Appendix II.



PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 "Network
Doctor report request", see Appendix IV. Request e-mail includes report number, when report
generation 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 network
criteria 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 the
quality 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 is
to 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 made
call 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 recommended
signal 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.



PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 internal
target of 98%.

11. DOCUMENT DELIVERY
Optimization Summary report is delivered to AWS RF engineer once a week, see file "Optimization
Status 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-ROM
and delivered to the AWS after all clusters are finished and approved by AWS. File format is Mapinfo
6.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 <-102dBm in Black) and DL quality (0-5 in
yellow, 6-7 in red)
2. One common cluster Quality Survey report of all sites of each cluster
3. Route and Cluster maps

12. DEFINITIONS
AWS AT&T Wireless Services
BSC Base Station Controller
BSS Base Station Subsystem
BTS Base Transceiver Station
DL DownLink (from the BTS to the MS)
GSM Global System for Mobile Communications
IS 136 TDMA network
KPI Key Performance Indicator
MS Mobile Station
MSC Mobile service Switching Center
NMS Network Management System
NSS Network and Switching Subsystem
NWP Network Planner
OMC Operation and Maintenance Center
QoS Quality of Service
RIC Rollout Integration Center
RSSI Receive Signal Strength Indicator
SAM Software for Analyzing Measurements
TCH Traffic Channel
TDMA Time Division Multiple Access
TOM Tool for Outdoor Measurements
UL UpLink (from the MS to the BTS)




PRE-LAUNCH OPTIMIZATION
GUIDELINE 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, solutions
and actions taken are included in this file. Updated
after every test drive.
Optimization Status Report.doc Weekly filled with drive test and NMS quality
criteria values. Delivered to AWS weekly.
Network Doctor Report.xls Spreadsheet includes list of Network Doctor
reports what are useful during optimization
process.
HW Change Request Form.doc All the hardware change requests are made using
this form. Form is send to implementation team.











PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 highlighted
fields are used to update the Optimization Summary table shown in Appendix IV. This reporting is
performed for AWS GSM1900 network only.

SAM 2.22 Nemo Technologies 13/9/2001 19:07
QUALITY SURVEY for GSM
NETWORK: AWS
SERVICE AREA: Las Vegas
SURVEY START: 10/9/2001 8:44
SURVEY 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 Level
5 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 Call
0 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 by the Measurement System)
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 dropped during Handover)
Success Rate 96.7 98.5 0 97.2 % (Handover Completes/ Handover Attempts)
Conducted by: Approved by:


PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 synchronization
068 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 ratio
153 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




PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 in
surrounding area?
1
Check transmitter path
incl transmitter.
YES
NO
YES
YES
YES
YES NO
NO
YES
NO
YES
NO
YES YES
NO
YES
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


PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
23 (33)

Network Planning/NET Mar 15, 2002



23




Check the neighbor list
to see is any neighbors
are missing.
Are HO fails
outgoing?
(150)
Is reason
blocking?
(150)
Check (153) to find the
problematic
relationship.
Is the failure
100%?
Check (154) Reason of HO.
Is the failure
100%?
Check (135) to see if
there is real TCH
blocking 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
YES Problem is at
the target cell.
High HO Failures
Check (153) to find
the problematic
relationship.
NO
YES


PRE-LAUNCH OPTIMIZATION
GUIDELINE 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 is
always 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 RxLevMinCell 11/28/01 3:00pm CST

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

The following form is used for change request
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 TRX Priority in TCH Allocation 2 (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 LASVGNVL130CHO Power Margin Budget 6 4
Comments
NOK
Parameter
CHANGE REQUEST to RIC RNW(Dallas)
Notice that TSC must have the same value as BCC.
Purpose Class
Source Target Old
value
New
value
11/10/2001
Las Vegas
Mr. Gambler
777 777 7777


PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
26 (33)

Network Planning/ NET Mar 15, 2002



26
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 email
as:
MarketRequest for ND Report ## Date of request [mmddyy] Time of Request [##:## am/pm] CST
For 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 received
and that the estimated time for the task completion.



PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
27 (33)

Network Planning/ NET Mar 15, 2002



27
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/Value
Tilt
Azimuth
Cables

Complete Checking of the Site Yes/No

Comments:






Requested By Date
Modified By Date




PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
28 (33)

Network Planning/ NET Mar 15, 2002



28
17.4 Optimization Summary Report
OPTIMIZATION SUMMARY

City/Market Cluster Number
Responsible Date

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

Drive
Date
Date
Analyzed
# of
Calls
# of
Checked
sites
Accessibility or
Successful
Call Setup %
Retainability =
(100 - Dropped
Calls) %
% DL Quality
0-4









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

Report
Date
Accessibility or
Call Setup
Success Rate
((csf_1a) * (csf_2d)
* (csf_3))
%
Retainability =
(100- Drop Call
Rate (dcr_8b))
% DL Quality
0-4
% UL Quality 0-4












PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
29 (33)

Network Planning/ NET Mar 15, 2002



29
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 on
problems affecting
KPIs adversely





Checks ND Report Status Comments
Adjacency discrepancy ND 060 Clear Not clear
Non symmetrical adjacency ND 061 Clear Not clear The reason for existing non-symmetrical
neighbors 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 number
of adjacencies
ND 071 Clear Not clear
Adjacencies with the same
BCCH and BSIC
ND 076 Clear Not clear
Frequency/ LAC/ CI Audit ND 111 Clear Not clear
Parameter Survey and
audit
ND 068 &
ND 063
Clear Not clear For detailed description please refer to
parameter audit report

NOKIA Optimization
Engineer
Date
NOKIA Market Optimization
Team Lead
Date
AWS Approval

Date



PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
30 (33)

Network Planning/ NET Mar 15, 2002



30
18. ON AIR VERIFICATION CHECK LIST
Optimization Engineer (Full Name and Signature)
Date

Market Name BSC Name BTS Name Sector Azimuth



Parameter BCCH
Frequency
TCH
Frequency
NCC BCC LAC CI MCC MNC MAIO HSN
Planned
value from
Datafill

Actual
value in
the
field


Actions in Sector A Status Actions in Sector A Status
MOC (mobile to land)
OK
NOK
MTC (mobile to mobile)
OK
NOK
MOC (mobile to mobile)
OK
NOK
GPRS Attach
OK
NOK
Call Setup E911
OK
NOK
Handover to Sector B
OK
NOK
MTC (land to mobile)
OK
NOK
Handover from sector B
OK
NOK
BSIC of neighbors
decoded
OK
NOK
Uplink Power control
OK
NOK





Checked By:
Optimization Team Lead (Full Name and Signature)
Date
Problem Description:


PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
31 (33)

Network Planning/ NET Mar 15, 2002



31
Optimization Engineer (Full Name and Signature)
Date

Market Name BSC Name BTS Name Sector Azimuth



Parameter BCCH
Frequency
TCH
Frequency
NCC BCC LAC CI MCC MNC MAIO HSN
Planned
value from
Datafill

Actual
value in
the
field


Actions in Sector B Status Actions in Sector B Status
MOC (mobile to land)
OK
NOK
MTC (mobile to mobile)
OK
NOK
MOC (mobile to mobile)
OK
NOK
GPRS Attach
OK
NOK
Call Setup E911
OK
NOK
Handover to Sector C
OK
NOK
MTC (land to mobile)
OK
NOK
Handover from sector C
OK
NOK
BSIC of neighbors
decoded
OK
NOK
Uplink Power control
OK
NOK





Checked By:
Optimization Team Lead (Full Name and Signature)
Date
Problem Description:


PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
32 (33)

Network Planning/ NET Mar 15, 2002



32

Optimization Engineer (Full Name and Signature)

Date

Market Name BSC Name BTS Name Sector Azimuth



Parameter BCCH
Frequency
TCH
Frequency
NCC BCC LAC CI MCC MNC MAIO HSN
Planned
value from
Datafill

Actual
value in
the
field


Actions in Sector C Status Actions in Sector C Status
MOC (mobile to land)
OK
NOK
MTC (mobile to mobile)
OK
NOK
MOC (mobile to mobile)
OK
NOK
GPRS Attach
OK
NOK
Call Setup E911
OK
NOK
Handover to Sector A
OK
NOK
MTC (land to mobile)
OK
NOK
Handover from sector A
OK
NOK
BSIC of neighbors
decoded
OK
NOK
Uplink Power control
OK
NOK




Checked By:
Optimization Team Lead (Full Name and Signature)
Date




Problem Description:


PRE-LAUNCH OPTIMIZATION
GUIDELINE REV 4
33 (33)

Network Planning/ NET Mar 15, 2002



33
19. PARAMETER AUDIT REPORT TEMPLATE


20. DOCUMENT REVISION HI STORY
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 requirement
and task responsibility.

Details of on air verification added
referring to the document
shakedown.doc

Modification of optimization process
based on previous AWS optimization
project experience and the new
requirements.

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

Addition of check list for on air section
18 verification

Addition of parameter audit in section
3.6

Addition of parameter audit template in
section 19
03/15/2002 4.0 Jeni R. Modification of Cluster Sign Off form in
section 17.5 to include consistency
checks and parameter audit.



AWS Parameter
Audit Report Rev 1 Mar01 2002.pdf

You might also like