/XFHQW7HFKQRORJLHV

Bell Labs Innovations

Engineering Guideline

EG16: Field Measurements: Drive Testing

LM: 4

401 - 380 - 346

Version 0.9
February 1998

Lucent Technologies — Proprietary

This document contains proprietary information of Lucent Technologies and is not to be
disclosed or used except in accordance with applicable agreements.
Copyright © 1998 by Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Engineering Guideline EG 16: Drive Testing

Lucent Technologies  PROPRIETARY

See notice on first page
2 Version: 0.9 LM: 4
Engineering Guideline EG 16: Drive Testing

This material is protected by the copyright and trade secret laws of the United States and
other countries. It may not be reproduced, distributed or altered in any fashion by any
entity, including other Lucent Technologies Business Units or Divisions, without the
expressed written consent of the Customer Technical Support and Information
organisation.

Notice

Every effort was made to ensure that the information in this document was complete and
accurate at the time of printing. However, information is subject to change.

Lucent Technologies  PROPRIETARY

See notice on first page
Version: 0.9 LM: 4 3
Engineering Guideline EG 16: Drive Testing

Lucent Technologies  PROPRIETARY

See notice on first page
4 Version: 0.9 LM: 4
Engineering Guideline EG 16: Drive Testing

Table of Contents

1.1 About this Guideline 7

1.2 The Purpose of Drive Testing 7

1.2.1 When to Drive Test 7
1.2.2 Where to Drive Test 8

1.3 Planning 8
1.3.1 Route Plans 8
1.3.2 Radio Test Plan 8
1.3.3 Network Test Plan 11
1.3.4 Trouble Ticket 11
1.3.5 Data Collection 13
1.3.6 Layer 1 Messages 13
1.3.7 Layer 3 Messages 13
1.3.8 Set-up Criteria 13
1.3.9 Sampling Times 13
1.3.10 Scanning Receiver 14
1.3.11 Call Classification 14

1.4 Field Analysis 15

1.5 Troubleshooting 15
1.5.1 No Data Collected 15
1.5.2 No Positional Information Collected 15
1.5.3 Coverage Holes 16
1.5.4 Dropped Calls 16
1.5.5 Handover Problems 16
1.5.6 Blocked Calls / System Busy 17

1.6 Drive Test Equipment 17

1.7 Staffing 17

Lucent Technologies  PROPRIETARY

See notice on first page
Version: 0.9 LM: 4 5
Engineering Guideline EG 16: Drive Testing

Lucent Technologies  PROPRIETARY

See notice on first page
6 Version: 0.9 LM: 4
Engineering Guideline EG 16: Drive Testing

1.1 About this Guideline

This guideline explains when, where , why and how drive testing should be used to collect
real-time RF information from the field. Generally this is done using a vehicle, but it can
also be carried out on foot where circumstances dictate.

1.2 The Purpose of Drive Testing

Drive testing is principally applied in both the planning and optimisation stage of network
development. However, there are other purposes for which drive testing can be used:
• To provide path loss data for initial site survey work
• To verify the propagation prediction during the initial planning of the network.
• To verify the network system parameters, as defined in the EG8: GSM/DCS
System-Specific Parameters.
• To provide the initial test parameters used in Benchmarking (as defined in the
“Analysis” section of the Network Performance and Monitoring Guideline).
• To verify the performance of the network after changes have been made e.g.
when a new TRX is added; the removal or addition of a new site; any power
adjustments or changes to the antenna; any changes in clutter or traffic habits
such as the addition of new roads etc.
• To measure any interference problems such as coverage from neighbouring
countries.
• To locate any RF issues relating to traffic problems such as dropped or blocked
calls.
• To locate any poor coverage areas.
• To monitor the network against a slow degradation over time, as well as
monitoring the network after sudden environmental conditions, such as gales
or electrical storms.
• To monitor the performance of a competitor’s network.

1.2.1 When to Drive Test

Drive testing can take place during the day or at night and is dependant upon the
Operator’s requirements and subscriber habits.
Drive testing during the day will mimic the conditions as seen by subscribers, but may
clog up the network if call analysis is being performed.
Drive testing during the night will allow a greater area to be surveyed due to the reduction
in vehicular congestion. It will also allow for certain test signals to be transmitted and
tested, particularly when setting up a new site, without interrupting normal operation.
However, night-time testing does not mimic the conditions experienced by subscribers.
For planning purposes, drive testing is typically performed at night and for maintenance
purposes, drive testing is performed during the day.

Lucent Technologies  PROPRIETARY

See notice on first page
Version: 0.9 LM: 4 7
Engineering Guideline EG 16: Drive Testing

1.2.2 Where to Drive Test

Some areas of a network will have greater performance problems than others. Drive
testing should not be uniform throughout the whole network, but should be weighted
towards areas where there are significant RF problems.
There may be other areas of the network that require temporary coverage during a certain
time of the year e.g. an exhibition centre or a sports stadium. These areas should be
examined and planned in greater detail.

1.3 Planning
It is important that a drive test is documented. This is specified by the Operator and can
either take the form of creating a new item of documentation or filling in an existing
document. All documentation will be passed to Analysts and Engineers, who will need
accurate records of any test work carried out.

1.3.1 Route Plans

The area to be drive tested is ascertained before leaving the office. There are three levels
of drive testing depending on the purpose of the test:
Primary Route: This includes all major roads, highways and throughfares and should be
given priority to all other roads when conducting a coverage test, unless a new site is put
into service for a specific objective.
Secondary Route: This includes all streets, by-streets and compounds, where accessible,
such as a University Campus. Secondary routes are used in areas where problems have
been located during a primary route test and further investigation is needed.
Miscellaneous Routes: This includes in-building and non-access routes to vehicles such
as shopping malls, golf courses, airports, hotels, conference centres etc.
A route is prepared by photocopying a map and highlighting the route to be driven. For
primary routes, a map of scale no less than 1:20,000 should be used, and a map of scale
1:10,000 is recommended for secondary routes. It is recommended that the route is
marked in a contiguous circuit, taking account of one-way streets at this stage.
A drive test should be planned in both directions, where possible, and at the same speed.
This minimises any errors and checks the point of handovers and cell dimensioning. For
new sites that are being tested, it is recommended that the transceiver is forced to camp
onto the cell (forbidding any handovers) in order to ascertain the full coverage of the cell.
The test should be re-driven with any forced handovers removed.

1.3.2 Radio Test Plan

A Radio Test Plan is used during new surveys where CW measurements are being taken.
It is a document detailing the transmission methods and receiving details used during the
survey. An example of a Radio Test Plan is shown in Figure 1:

Lucent Technologies  PROPRIETARY

See notice on first page
8 Version: 0.9 LM: 4
Engineering Guideline EG 16: Drive Testing

RADIO TEST PLAN

Test Details:
Date: Monday 28th July 1997 Time at start of test: 10:30
Test Name: 280797a Time at end of test: 18:30
Site Name: Cosmos Building Technician: S Allen-Stevens

Transmission Details:
Antenna Height: 2m Antenna Gain: 6 dB
Antenna Type: Omni Antenna Polarisation: Vertical
Transmitter ERP at 500 W Transmitter ERP at 497 W
start of test: end of test:
Frequency at start of 915 MHz Frequency at end of 915 MHz
test: test:
Cable Loss: 3 dB Downtilt angle: 0°
Building Height: 30 m Comments: Lip around building of 1 m

Receiver Details:
Antenna Gain: 0 dB Antenna Polarisation: Vertical
Antenna Mounting: Mag. Mount Antenna Type: ¼ Wave dipole
Cable Loss: 3 dB Vehicular Height: 2m
Comments:
Antenna mounted on roof in centre of vehicle.

Route Details:
Mainly city centre incorporating High Street, Kings Street, Regent Street... as shown on Map 2807.1
Very congested with vehicular traffic from 12:00 to 13:45

Additional Comments:
LOS with transmitter from Marker1 to Marker2.
Transmitter powered down from 16:35 to 16:55 due to electrical storm.

Figure 1:Example of Radio Test Plan

Lucent Technologies  PROPRIETARY

See notice on first page
Version: 0.9 LM: 4 9
Engineering Guideline EG 16: Drive Testing

NETWORK TEST PLAN

Test Details:
Date: Monday 28th July 1997 Time at start of test: 09:30
Test Name(s): 280797a/b/c/d/e/f Time at end of test: 16:00
Technician: S Allen-Stevens

Reasons for Test:

Complaint Site under Survey:
Reference:
Complaint details: Details of Site:
ERP:
Downtilt Angle:
Routine N Height:
Maintenance Y/N:
Other: Possible interference with Allocated Channels:
neighbour network
Comments:

Set-Up Details:
Sample Method: Lee Scanning Data to be collected:
Maximum Speed: 40 km/h Channels: 124 Contiguous
Scanning Antenna 0 dB Avg/Max/Min: Average
Gain:
Scanning Cable Loss: 3 dB Min. Signal Strength 10
level:
Transceiver Antenna 0 dB Tracking Data to be collected:
Gain:
Transceiver Cable 3 dB Buffer size: 5
Loss: (in relation to handovers)
Comments: Antennae are mag. Mount in centre of roof. Phones calibrated 15/03/97.

Route Details:
As shown on Map 2807-3. Regent Street closed for re-surfacing therefore not surveyed.

Figure 2: Example of Network Test Plan

Lucent Technologies  PROPRIETARY

See notice on first page
10 Version: 0.9 LM: 4
Engineering Guideline EG 16: Drive Testing

1.3.3 Network Test Plan

The Network Test Plan is a document used to record the set-up of the surveying
equipment. It is used during analysis, in order to isolate specific problems or can be part of
the problem solving process.
An example of a Network Test Plan is shown in Figure 2.

1.3.4 Trouble Ticket

1. The Trouble Ticket is a document originating from the CRC (Customer Technical
Support), by which problems reported by customers are passed through Lucent at
various levels. An example of a Trouble Ticket is shown in Figure 3.
2. The trouble tickets are currently logged on to a database CAROD which will
eventually be replaced by another database. GTSIP. A database has also been
set u specifically for field service engineers to pass information for
troubleshooting in the field which is not connected to Trouble Tickets. This
database is called FELIX.
3. According to the problem area, location and origin of the call, different scenarios can
be followed in order to solve the problem.

Lucent Technologies  PROPRIETARY

See notice on first page
Version: 0.9 LM: 4 11
Engineering Guideline EG 16: Drive Testing

4. TROUBLE TICKET
Problem Area:
1: Problem
o Unable to place call o Crosstalk
o Unable to receive call o Call dropped
o Unable to hear audio o Echo
o Unable to be heard o Busy Tone
o Unable to call specific o Announcement
o Glass breaking sound o Other
o Noisy connection

Customer Details:
2: Originator Number: 3: Calling Number: Tel. No:
o Local o National o International

4: Originator Name: 5: Originator Contact Number:

6: Location of Problem
City Area Street

7: Was Originator? 8: Time Problem Occurred

o Stationary o Driving
o In-Building At what Speed?

Customer Care Area

9: Ticket No: 10: Date: 11: Time

12: Operator Name: 13: Contact Number:

14: Problem Description:

Cell Site Names:

15: Clearance Details:

Date: Time:
Trouble Found:

Action Taken:

Figure 3: Example of a Trouble Ticket.

Lucent Technologies  PROPRIETARY

See notice on first page
12 Version: 0.9 LM: 4
Engineering Guideline EG 16: Drive Testing

1.3.5 Data Collection

While conducting a drive test, all data should be collected, saved and tagged with:
• A time stamp
• A positional stamp
If the data is not stamped, it is not possible to efficiently analyse or plot the data. In
addition to the above stamps, other necessary criteria required for field measurements are:
• RxLEV of Serving Cell - Dedicated/Idle
• RxQUAL of Serving Cell - Dedicated/Idle
• Timing Advance of Serving Cell - Dedicated mode only.
• Cell ID of Serving Cell (NCC, MNC, LAC, BSIC, BCCH)
• Cell ID of Neighbour Cells (BA Table)
• RxLEV & RxQUAL of Neighbour Cells

1.3.6 Layer 1 Messages

Other Layer 1 criteria that is useful for field measurements include:
• C1 criteria
• ARFCN of Serving Cell - (TCH in dedicated mode, BCCH in idle mode))
• Time Slot (TS)

1.3.7 Layer 3 Messages

All Layer 3 messages should be collected where possible. Layer 3 Messages are used by
Analysts to determine more accurately the cause of a problem within the network.
Some field test equipment can perform basic analysis of particular Layer 3 messages
during data collection. This enables certain conditions such as call classification or
handovers to be flagged to the survey technician.

1.3.8 Set-up Criteria

Before a drive test can take place, both the scanner and receiver will need to be set-up
with certain criteria. The criteria will depend on both the test to be performed and the
equipment used, but will typically include statistical information , channels to be tested,
scanning methods to use, together with criteria for determining call classification.

1.3.9 Sampling Times

Due to the losses and fading effects of an RF environment, it is meaningless to measure
individual spot readings of field strength. It is usual practice for a number of samples to be
taken in a given time and then mean averaged.
In general, the sampling methods used are either the Nyquist sampling rate or the Lee
Criteria Method .
In high-multipath areas with deep fades, such as that experienced in city centres, a
measured mean value is not enough in itself to inform the Radio Engineer of the dynamics
of the radio environment. In this case it is advisable to also collect the maximum,
minimum and standard deviation of the readings.

Lucent Technologies  PROPRIETARY

See notice on first page
Version: 0.9 LM: 4 13
Engineering Guideline EG 16: Drive Testing

1.3.10 Scanning Receiver

As well as the sampling rate, the number of channels, scanning rate and synchronisation
times are used to determine the maximum speed that the vehicle can travel in order to
make efficient field measurements.
Error! Reference source not found. can be used as a guide for maximum vehicle speed
using a scanner speed of 25 ch/s, collecting data every second..
Table 1: Guide to maximum vehicle speed.

Number of Channels GSM 900 (km/h) GSM 1800 (km/h)

20 60 30
40 30 15
60 20 10
80 15 8
100 12 6
124 10- 5
Note: The ESVD or Rohde and Schwartz TS9951 has a scanning rate of 400 ch/s. This
rate is high enough to rarely limit the speed of the vehicle.

1.3.11 Call Classification

In principle there are five call classifications, some of which can be sub-divided further.
Good Calls: These are calls that are successfully placed on the network and maintained
for the required duration.
Dropped Calls: These are calls that are successfully placed on to the network but are
terminated without authorisation. Using Layer 3 Messages, these calls can be sub-divided
into:
• End User Hang-up
• System Hang-up
• Other
Blocked Calls: These are calls that cannot be placed on to the network. Again, using
Layer 3 messages, these can be sub-divided as follows:
• System Busy
• End User Engaged
• No Service
• Other
Roamed Calls: These are calls that are successfully placed on another network. Roamed
calls may also be good calls or dropped calls.
Noisy Calls: These are calls which have been successfully completed for the duration of
the call but which experienced a number of noise bursts that a subscriber may find
intolerable. The threshold for determining the level of poor audio is programmed during
the set-up of the test.
In GSM, this particular classification is very difficult to determine with great accuracy. It
should be noted that it is not enough to monitor just the RxLEV and the RxQUAL.

Lucent Technologies  PROPRIETARY

See notice on first page
14 Version: 0.9 LM: 4
Engineering Guideline EG 16: Drive Testing

1.4 Field Analysis

After the drive test is completed, it is important that the data is checked to ensure that
enough has been collected in order to complete a thorough analysis back in the office,
before returning.
In order to check the data, a certain amount of analysis will need to be performed. Often,
the cause of the problem may be obvious to the surveying technician , and this should be
reported to the office immediately.
The following are some of the most commonly encountered performance problems
encountered during drive testing.
• No data collected
• No positional information collected
• Coverage Holes
• Dropped Calls
• Handover Problems (Ping-Ponging)
• Blocked Calls / System Busy
Remedial action for these problems is shown in Section 1.5 below.

1.5 Troubleshooting
This section suggest some of the most likely causes of problems during a drive test.

1.5.1 No Data Collected

Occasionally, the equipment fails to trigger the collection device to save the data to file.
• Check all cables
• Ensure the Processing Unit is powered
• Re-start the laptop computer
• Re-start the equipment
• Re-drive the test.

1.5.2 No Positional Information Collected

If data is collected using GPS only, it may be possible that satellite reception was lost
during a drive through a tunnel etc. It is important that back-up equipment is used, such as
a Dead-Reckoning device, since a GPS receiver will re-transmit the last known position
until it receives an update. If the vehicle moves without GPS cover, the data will be
inaccurate and cannot be analysed.
• Check the GPS antenna cable to the receiver
• Drive to an open area and ensure that the GPS system is working correctly
• If required, install a back-up positional device to safeguard against lost GPS

Lucent Technologies  PROPRIETARY

See notice on first page
Version: 0.9 LM: 4 15
Engineering Guideline EG 16: Drive Testing

1.5.3 Coverage Holes

If there are patches of poor coverage in unexpected areas, it may indicate the fringes of a
coverage hole. It is important to re-drive this particular area.
• Complete a route plan using secondary roads as far as possible
• Make notes of any buildings / obstructions that may cause shadowing
• Take note of pedestrian / vehicular habits in the area

1.5.4 Dropped Calls

Dropped calls can be caused by either RF environments or incorrect system parameters.
The following data should be checked to ensure that it has been collected properly.
• Layer 3 Messages
• Neighbour Cell List (BA Table)
• RxLEV (Server & Neighbour)
• RxQUAL (Server & Neighbour)
Finally, ensure that the automatic setting for the call length is not shorter than that for the
timer monitoring for unauthorised call drop-outs. The setting should be a minimum of 30
seconds.

1.5.5 Handover Problems

Handover problems are generally caused by inaccurate settings of the handover boundary.
This can cause ping-ponging, where the server will keep changing, and congestion at the
switch. Check the following.
• The transceiver antenna is fitted correctly
• Collection of Layer 3 Messages
• Collection of Neighbour Cell List (BA Table)
• Collection of Scanning Information
• Collection of Cell Identities
• Collection of T.Adv for the Serving Cell
Also, ensure that the collection of data from the new serving cell immediately after the
handover has occurred (particularly RxLEV and RxQUAL) is not timed to occur prior to
the-synchronisation of the transceiver itself.
If a particular serving cell can be isolated as a potential cause of handover problems,
slowly drive around the cell in a radius of around 500m - 1km, checking when handovers
occur.

Lucent Technologies  PROPRIETARY

See notice on first page
16 Version: 0.9 LM: 4
Engineering Guideline EG 16: Drive Testing

1.5.6 Blocked Calls / System Busy

If calls are repeatedly classified as blocked, it is recommended that the drive test is
temporarily halted in order to try and locate the cause.
• Check that the number called is fully functional
• Check that there is adequate coverage from the expected serving BTS
• Check the equipment transceiver is functioning correctly by using an ordinary
mobile to call the office
• If all appears functional, try to place calls through an alternative BTS. If this
succeeds, inform the office immediately and re-suspend the drive test.

1.6 Drive Test Equipment

The equipment needed in to perform a drive test will typically be made up of the
following:
• Transceiver - to exercise the network and to collect RF Information from the
network
• Scanning Receiver to collect RF information
• Position Locating System to track the vehicle position
• Processing Unit to process the information collected
• Collection / Storage Unit - such as a laptop computer, to store the data
The equipment must be properly installed into a vehicle. It must also be powered for at
least 30 minutes before the start of any test in order to minimise drift through temperature
changes.
Always ensure that the transceiver has been registered on the network before beginning a
drive test and that a test number has been allocated for placing and analysing calls. It is
also important that an ordinary mobile is taken on drive tests in order to place and receive
calls to and from the office during tests.
More detailed information about drive test equipment is given in EG17: Field Test
Equipment.

1.7 Staffing
There should always be at least two people in the drive test vehicle:-
• The driver responsible for driving the designated route
• The surveying technician, responsible for monitoring the measurements,
making notes, watching the display and computer, and performing preliminary
analysis in the field.
The number of staff in an optimisation / survey team will depend on the complexity of the
network. In general, the surveying technician will obtain instructions from a Radio
Analyst with regards to problem areas to be surveyed. The technician is responsible for
planning the drive routes associated with the problem, collecting and crudely analysing
the data to ensure that the Analyst has enough data to troubleshoot more accurately.

Lucent Technologies  PROPRIETARY

See notice on first page
Version: 0.9 LM: 4 17
Engineering Guideline EG 16: Drive Testing

Lucent Technologies  PROPRIETARY

See notice on first page
18 Version: 0.9 LM: 4