All About Drive Test Problems [Part 1]

بسم هللا الرحمن الرحيم

All about DT [DRIVE-TEST] problems

2G Problems [Part 1]

Prepared by:

Eng. Abdelrahman Ashraf Mostafa

RNE-Telecomax Consult

E-mail: [email protected]

[email protected]

Phone: +2-0109-6739100

All about DT [Drive-Test] problems

By: Abdelrahman Ashraf Mostafa

2

NOTE: We can say that most of the 2G problems can be caused by/due to bad quality problem as we will proceed,

so in order to solve most of 2G problems you should try to fix the main reason which is the bad quality problem.

1-Blocked Calls;

While initiating a call on TEMS, your call is blocked and you hear call blocked on TEMS, this may occur due to 1 of the

following reasons:

Congestion.

Bad Radio conditions.

Hardware problem in handset MS.

1-Congestion:

[Means there are no available resources in your serving cell], where in 2G there are 2 types of congestion:

-SDCCH congestion problem [no SD's available for you to perform call-setup procedure] and it appears on TEMS in

Layer 3 messages as [No Immediate Assignment] message.



3

-TCH congestion problem [no Traffic channels available to perform your call-setup procedure] and it appears on

TEMS in Layer 3 messages as [No Traffic Channel Assignment] message.

NOTE: It's normal that Overshooting site to you may suffers congestion as it will be carrying traffic and serving

users in its region and other users in your far away serving region.

2-Bad radio conditions:

[You then suffer from bad Rx Level or bad Rx Quality so you can't communicate with your serving cell or decode any

of its DL messages]

-Bad Rx Levels can be a result of bad 2G coverage where there is no dominant server exists in the area.

-Bad Rx Quality can be caused by bad coverage [bad levels results bad quality] or due to a high level of interference

[Up-link or Down-link interference] on either your MS or your serving cell and it appears on TEMS in Layer 3

messages as [No Service] message.

BUT how to differentiate that bad quality is due to bad coverage Rx levels or due to interference ?

-Bad Quality in case of bad levels is normal as bad levels will normally causes bad quality While

-Bad Quality in case of good levels, so for sure there is interference.



4

3-Hardware problem in ME handset:

[Sometimes your test mobile suffers temporary sudden errors due to excessive usage, so it reports blocked calls with

no apparent reason] and it may appears on TEMS in Layer 3 messages as [No Alert or Connect] message.

NOTE: TEMS is a stupid software that generates events but it doesn't receive any indicators about these events

from network, it only memorizes a specific sequence of messages, if any of these messages dropped due to any

reason and didn't received by mobile so TEMS didn't record it, it may then report blocked call with no reason.

NOTE: Not all the events that appear on TEMS during test actually occurred and stored/counted among network

KPI's, as sometimes any sudden hardware errors in your DT tools may cause events in a very good radio conditions

[Blocked calls-Dropped calls-H.O failures, etc…], that's why in analysis we sometimes neglect events which occur

in a very good radio conditions as these events occurred due to some temporary errors in your test tools.



5

2-Interference;

When noticing that quality in 2G GSM Radio Parameters window [Rx Qual] and value of C/I in GSM Hopping

Channels window are bad for a specific ARFCNs while levels of 2G coverage for the same ARFCNs are good, where

there exist 2 types of interference:

Up-link interference.

Downlink interference.

1-Up-link interference:

[Your serving cell will not be able to decode any of your up-link messages if your MS suffers any up-link

interference].

Interference in up-link can be due to any external system that may be broadcasting or transmitting on a used

GSM/DCS ARFCN frequency with a high power, hitting any information that is transmitted over this ARFCN and

serving BTS will not be able to decode your up-link messages, ex. Military applications.

Up-link interference is an interference on your MS mobile handset, causes bad quality in up-link between your MS

and the network, where an external system transmits power on a specific frequency ARFCN which is the same as the

frequency you are using to communicate with your serving cell. So, any message or information you are transmitting

on this ARFCN may suffer high amount of errors due to interference causing high BER [Bit Error Rate] so quality

turned bad by time.

2-Down-link interference:

[Your mobile will not be able to decode any of the network down-link messages if there is any down-link

interference on the serving BTS].

There are 2 imp. Types for the down-link interference:

-Co-Channel Interference [You find a bad quality and bad C/I problems for a specific ARFCN in

good Rx levels].

- Occur when 2 same frequencies interfere with each other BCCH's or TCH's.

-Neighboring sector to your own serving sector is transmitting on [BCCH/TCH] ARFCN channel which is the same

ARFCN your serving sector is transmitting on to you in down-link.

-Adjacent-Channel Interference [You find a bad quality and bad C/I problems for a specific ARFCN in good Rx levels].

- Occur when 2 adjacent close frequencies interfere with each other BCCH's or TCH's.

-Neighboring sector to your own serving sector is transmitting on an adjacent ARFCN channel to the ARFCN channel

of your serving sector [BCCH/TCH].

Down-link interference is an interference on your serving cell, causes bad quality in down-link between your MS and

the network, meaning that a neighbor or an overshooting cell is transmitting power [Information] for its serving

users in the area on a specific ARFCN frequency in down-link which is the same as the frequency you are using to

communicate with your serving cell. So, any message or information your serving cell is transmitting on this ARFCN

may suffer high amount of errors due to interference causing high BER [Bit Error Rate] so quality turned bad by time.



6

Conclusion:

Interference is unwanted power, if it hits the up-link, serving cell may then not be able to decode any of the user's up-link messages and it will be named Up-link interference and if it hits the down-link, user's MS mobile may then not be able to decode any of the serving cell's down-link messages and it will be named Down-link interference.

NOTE: Overshooting sites may cause interference as they may be using the same ARFCN's [BCCH /TCH] of your

near-by serving cells due to the frequency reuse pattern as shown:

3-Overshooting;

When we get the signal from an away site that not close to the current area drive test, whether this site was serving

you or just appears as a neighbor with good Rx levels to you.

-In case this overshooting site was serving with good levels: Usually we get bad [Rx Qual] due to down-link

interference from neighboring cells with Co. or Adjacent channel BCCH and large value for TA [Time Advance] also it

may causes call drop by the time as you will not be able to perform handover because all the neighboring sites to

you will be missing neighbors for it [not in your serving site BA list], you will remain on serving site until call drops

due to bad radio conditions.

It may also cause [congestion] problem under this overshooting site as it is now serving away from its supposed

coverage region so the site near-by users may found no resources to use + levels under site may be bad causing

coverage problems specially indoor.



7

-In case this overshooting site appears as a neighbor with good levels: It may cause a bad [Rx Qual] due to 2G DL

interference problem [Co. or Adjacent channel interference] as due to the frequency reuse pattern, this

overshooting site may be using an ARFCN which your serving site are using as BCCH or TCH, so it will impact it

causing bad [C/I] value.

NOTE: Any sites near water may overshoots due to the ducting phenomena in water that it could transfers signal

for a large distances.



8

4-Blocking/Reflections; Causes temporary bad levels problem

When Rx levels from your serving site suddenly drops to the -90's/-100's dbm which is very bad [While it was very

good] in the -60's during DT, while you are near to site and its levels to you was supposed to be very good but it

suddenly turned bad for a while then while moving levels turned very good again [Temporary bad levels].

In reality field you find a body [building-metal-trees-mountain or hill-etc……] which existed in the bad levels region

between you and serving site, this obstacle:

-Whether blocks LOS (Line Of Sight) for you from site, so you can't see site from your position of bad level. [Blocking]

Back then blocking body height is = or higher than serving site.

-Or makes reflections to received signal so that it doesn't reaches you with good levels. [Reflections]

Back then blocking body height may not be = or higher than site height, its height may be lower than site height

but made from a metal/conductor material or trees causing reflection, you even may see the site but you still find

bad levels.



9

As shown above, levels turned bad [Red color] suddenly after it was good ,once approaching near a region levels

turned bad and suddenly it turned good again, a metal container exists in the area of about same height as serving

site causing blockings to the received signal from site for a while.

5-Cell Barred;

When served by a cell in dedicated mode and as soon as you end your call you find yourself in (No Service Mode) as

this cell is banned to be accessed in idle mode, so this cell only accepts handovers in dedicated mode with good

levels normally but you can't access or initiate a call on it as it is closed/barred in idle mode.

As shown in snaps before, when served by sector 2 BCCH: 59 in dedicated mode after making a handover from

sector 1 BCCH: 29, levels were good and coverage in front of sector 2 was good, but once call is ended while in front

of sector 2 you find (No Service Mode) on TEMS as cell is barred and your MS can't make cell selection or reselection

to it in idle mode as it is barred.



10

Once you end your call and be in idle mode, your MS will try to camp and perform cell reselection to the cell BCCH

59 considering that it was with the highest level in idle mode, but once MS try to read the system information on

BCCH 59 for this cell, it will know that this cell is barred and so that it should leave this cell immediately, so MS will

perform forced cell reselection to any other nearby cell even if it was lower in level than this barred cell BCCH 59 and

sometimes your MS may not find any neighbors to perform this forced cell reselection to any of them so it will enter

SOS emergency call mode and you will see No Service on TEMS.

NOTE: A cell may sometimes barred by optimization teams if this cell suffers:

1- High SDCCH congestion causing bad KPI's in CBR (Call Block Rate) due to high utilization on SD channels.

2- Temporary hardware problem.

6- Handover Ping Pong (Repeated); May causes call drop problem

In very small area/route also in a very small time period you perform many quickly handovers among 2 or more cells

all are with high levels but none of them is high enough to be the only dominant serving cell in the area.

While testing, you are performing many handovers between your serving cell and neighboring cells all are

transmitting power in the area with very good levels

NOTE: Handover process takes a lot of signaling procedure of messages and commands between MS and network

also it requires a full time slot to be executed, many HO's will be executed over a lot of time slots TCH's, these

TCH's was supposed to be used for your traffic speech transmission but instead you are performing many HO's on

them instead, so repeated HO's causes an excessive processing load on the network and bad voice quality.



11

7-VSWR-Hardware problem; Causes bad levels or even gaps under site

Right under a site on TEMS map or very near to it but the Rx levels from it is very bad, so coverage under the site will

be bad that it may causes calls to be dropped right under serving site due to bad levels.

VSWR may be due to a problem in feeders, jumpers or connectors connecting the cabinet to sector antenna also it

might be an antenna or a DTRU-card hardware problem inside cabinet.

NOTE: VSWR [Voltage Standing Wave Ratio] is simply means that the full EIRP that is generated from cabinets are

not fully reaching sector antenna so levels under site turned very bad.

A scene like this in site will for sure causes VSWR problem as sector feeders are bent also sector antenna is dropped

down the tower to the ground.



12

8-No or Late Handover; leads to call dropped due to bad radio conditions

In window [GSM Serving + Neighbors] , you find a better neighbor in level which is better than your now-serving cell

but no or late(takes a while and not quickly) handover occurred to this neighbor which leads to bad radio conditions

from your serving now cell by the time and might cause call dropped.

No or late handover can be due to:

TCH congestion.

Poor-wrong H.O parameters.

1-TCH congestion:

This better neighbor in level back then it may was suffering from TCH congestion, so it has no TCH resources left to

be assigned to new users, so no H.O occurred to it until call is dropped.

2-Poor H.O parameters:

Sometimes H.O parameters require tuning, how???

Imagine you were served by Cell 1 with bad levels due to large distance away from it, you see cell2 as neighbor with

better levels but no H.O occurred!!! Usually due to large value of H.O margin between 2 cells

NOTE: H.O margin is a 2G cell parameter, this parameter determines when to leave your serving cell 1 and

perform H.O to the better neighbor cell 2, in another words I should perform H.O to the neighbor cell 2 when its

level is better than cell 1 by how many dBs?

In some cases like this one H.O margin of cell 1 is large so however cell 2 level was better than cell 1 but no H.O

occurred to cell 2 as its level is not reached yet the margin threshold of H.O to cell 1 which causes the delay in H.O

between the 2 cells.

Cell 1 Serving cell

Cell 2 Neighbor cell

MS



13

Being served by cell 1541 BCCH: 66 with very bad radio conditions as Rx level is -95 dbm but you notice another

neighboring cell K31281 BCCH: 67 appear as a neighbor with better levels -66 dbm.

Handover between 2 cells should happen but H.O is delayed more and more [it may not even happen] until call is

dropped due to very bad radio conditions on serving cell 1541 as shown in snaps.

No H.O command has been sent to you to perform H.O on cell K31281 as cell may be congested.



14

9-Wrong Handover;

When a handover procedure occurs from a better Rx-level serving cell to a lower/worse Rx-level neighbor cell

[occur when H.O target cell is lower in level than serving cell] which is wrong.

Or

When H.O process occurs from a cell [serving cell 1] to another cell [target H.O cell 2] which is normally better than

[serving cell 1], while there exists a better neighboring cell 3 which is better in level than both [serving cell 1] and

[target H.O cell 2].

H.O command was supposed to be on cell 3 instead of cell 2 as cell 3 level is > cell 2 level but may be cell 3 was

suffering from TCH congestion so you didn't receive a H.O command to camp on it from BSC.

10-Wrong-Shifted Azimuths;

Visiting a site but you notice something strange in sectors levels as you sometimes suspect a cross

feeder or sector but sometimes everything is normal but you can't judge, so:

[Once you found something strange that site sectors are serving in front of each other's and you can't judge,

suspect the site azimuths are they correct or wrong]

Or visiting a site, you notice a sector on TEMS map [cell file], its position and direction w.r.t the surrounding clutter

and coverage appears to be wrong logically!!!!! How come?

Sometimes you find azimuth for a sector is not logical !!!!

You may find a sector antenna is serving in direction of a desert or water instead of being serving in the place

which it was supposed to be serving, so you will find bad coverage levels as this antenna is originally wrong

planned or wrong directed by site installation team.



15

As shown in following snaps;

-In front of sector 2, for a while you suspect a cross feeder in site between sectors 1 and 2 as sector 1 serves with

almost same levels in front of sector 2 about 1.2 Km but to make sure [we must go in front of sector 1] !!!!!

-In front of sector 1, found that sector 2 is dominant all the time in front of sector 1 with good level while sector 1

levels is bad, so case turned to be a suspected cross sector instead of being a cross feeder case between sectors 1

and 2.



16

Now is it cross feeders or cross sectors problem between sector 1 and sector 2 ……?????

This is up normal case as we couldn't decide!!!!!

We then suspected that site azimuths may be wrong in TEMS cell file, so sadly the rigger performed site auditing

for this site to check for correct site azimuths.

It appeared that both sectors 1 and 2 azimuths in site were shifted, so when correcting azimuths in TEMS cell file,

everything was cleared and it was clearly a cross sector, as:

-In front of Sector 1 BCCH: 55, sector 2 BCCH: 8 is dominant with good levels while sector 1 levels are bad.

But we still must go in front of sector 2 to make sure???



17

-In front of Sector 2 BCCH: 8, sector 1 BCCH: 55 is dominant with good levels while sector 2 levels are bad.

So clearly cross sector is now confirmed between sectors 1 and 2 in site after correcting site azimuths in cell file.

11-Handover failure; leads to call dropped due to bad radio conditions from serving cell

NOTE: H.O failure [from system KPI point of view] means that you [MS] did sent H.O Access to new target H.O cell

but you didn't receive physical channel information so handover fails.

When you fail to perform H.O from your serving cell [old] to a better level neighbor target cell [new], so you make

ROC [Return to Old Channel] on your serving old cell to continue your call and you hear handover failure on TEMS,

this may occur due to 1 of the following reasons:

Bad radio conditions [quality] or a H.W [hardware] problem on targeted H.O cell.

Bad radio conditions [quality] on MS handset.

Data link failure = Layer 2 failure.

1-Bad quality or a H.W problem on targeted H.O cell:

[Means that targeted H.O cell suffered from UL Up-Link interference ICM [Idle Channel Measurement external

interference] at the time MS was sending its UL H.O access command to it, so targeted H.O cell couldn't decode MS

UL message due to UL interference or a H.W problem on targeted cell.



18

As shown in the following snaps, H.O failure occurred due to target H.O cell C06063 BCCH: 718 suffer from UL

interference from an external resource causing bad quality on targeted H.O cell so it couldn't decode the UL H.O

access command sent by MS on UL due to interference and as so targeted H.O cell didn't sent the DL Physical

channel information to MS.

2-Bad quality on MS handset:

[Means that targeted H.O cell suffered from DL Down-Link interference [Co-Adjacent channel interference] at the

time new targeted H.O cell was sending its DL Physical channel information to MS, so MS couldn't decode targeted

H.O cell DL message due to DL interference.

As shown in the following snaps, H.O failure occurred due to target H.O cell 12593 BCCH: 67 suffer from DL Co-

channel interference on BCCH: 67 from a neighboring cell 6403 BCCH: 67 causing bad quality on MS handset so it

couldn't decode the DL Physical channel information sent by target H.O cell 12593 on DL.



19

NOTE: Any H.O failure occurred due to [Protocol error – Physical channel failure – or any other messages, etc.] in

layer 3 messages on TEMS is considered to be a H.O failure due to a 1 of the 2 radio problems that we have just

mentioned.

3-Data link failure:

MS connection with the mobile network is established upon layers connection, so in order for MS to establish

connection with the new target H.O cell to complete handover process, MS should establish a transmission layer 2

[Data link layer] with the new BTS.

When MS fails to any reason to establish layer 2 with new BTS, H.O fails and MS returns to old serving BTS ROC and

you hear H.O failure on TEMS.



20

NOTE: Any H.O failure occurred due to [Data link failure- Layer 2 failure- N200.T200 timer expiry] in layer 3

messages on TEMS is considered to be a H.O failure due to a transmission problem which is not RF [Radio]

problem.

NOTE: Bad radio conditions [quality] on serving cell [old] in H.O process is not a reason for handover failure from network KPI point of view!!!! HOW???

Handover is a process between all 3 of:

1- Serving cell. 2-Mobile station. 3-Target H.O cell.

Where H.O Scenario on TEMS is:

1-H.O command: Sent on DL FACCH from BSC to MS containing info. About new target H.O cell.

2-H.O Access: Sent on UL FACCH from MS to new target H.O cell requesting a TCH to continue call when handover occurs.

3-Physical channel information: Sent on DL FACCH from targeted H.O cell to MS informing the MS about the new hold TCH to take it.

4-H.O complete: After H.O process completed successfully MS sent H.O complete to BSC through target new H.O cell to inform that H.O is completed.

So, from network KPI point of view:

H.O is considered to be failed when MS send H.O Access in UL to new target cell and didn't receive physical channel information from it in DL due to any of the 2 before possible reasons.

But from TEMS point of view:

H.O is considered to be failed when any of the following happens;

1-BSC sends H.O command in DL to MS and didn't receive H.O complete message in UL from MS within timer T3103, this issue is considered as a H.O drop or call drop in the system not H.O failure.

2- MS send H.O Access in UL to new target cell and didn't receive physical channel information from it in DL within timer T3124, this issue is considered as a H.O failure on both TEMS and network.

3-Target H.O cell sends physical channel information in DL to MS and didn't receive SABM message to establish data link [layer 2] in UL from MS within timer T3105, this issue is considered as a H.O drop or call drop in the system not H.O failure.



21

So, sometimes TEMS counts events as H.O failures however these events are not counted as failures in network

KPI's but they are counted as H.O drops or call drops, but we normally analysis these types of events however

they are not counted as H.O failures from system point of view, that's why sometimes in reports you find H.O

failures due to bad radio conditions on serving cell whether level or quality where MS couldn't decode the DL H.O

command sent by BSC on the serving old cell due to the bad radio conditions between your MS and the network

back then.

So we will add a 4th reason for H.O failures however it is not correct as these failures are not counted as H.O

failures in the system but as H.O drops.

Bad radio conditions [quality] or H.W [Hardware] problem on serving cell.

4-Bad quality or a H.W problem on serving cell:

[Means that serving cell suffered from bad radio conditions [level or quality] from DL Down-Link interference [Co-

Adjacent channel interference] at the time it was sending BSC's DL H.O command to MS, so MS couldn't decode

serving cell DL message due to DL interference.

As shown in the following snaps, H.O failure occurred due to serving cell 19101 BCCH: 79 suffer from bad radio

conditions causing bad quality on MS handset so it couldn't decode the DL H.O command sent by BSC on serving

cell.

NOTE: As a conclusion, H.O failure [from system KPI point of view] means that you did sent H.O Access to new

target H.O cell but you didn't receive physical channel information so handover fails and MS ROC to old BTS and



22

send H.O failure as an indication to the network.

12-Missing Neighbor; Might leads to call dropped due to bad radio conditions from serving cell

When approaching near cell 2 while attached by another serving cell 1 in dedicated mode [during a call], you notice

that cell 2 BCCH doesn't exist in GSM Serving + Neighbors window at all disappeared

-To make sure cell 2 is a missing neighbor to your serving cell 1, check BA list in [System information type 5] in layer

3 messages for same band BCCH's or BA list in [System information type 5-ter] for other band BCCH's to see all

defined neighbors BCCH's to your serving cell.

Served by cell 12203 BCCH: 64 while radio conditions was getting bad, noticed 2 near-by cells [BCCH's: 83,728] but

there BCCH's don't exist in GSM Serving + Neighbor window, they may be missing neighbors.



23

-To confirm that, we checked both Sys.Info Type 5 and Sys.Info Type 5-ter in layer 3 messages and both BCCHs

were not defined to serving cell BCCH.

13-Site-Cell Down;

Site may be down due to 1 of the following 2 reasons:

Power problem.

Hardware problem.

1-Power problem:

Under a cell but the Rx-Level from its BCCH in GSM Serving + Neighbors window is too bad, this problem may be due

to wrong antenna tilting or due to VSWR alarm in site.

2-Hardware problem:

Cell on TEMS map but when moving near to it, you didn't find its BCCH in GSM Serving + Neighbors window [even

while in Idle mode] so cell is not missing neighbor for sure but it is not serving as it is down.

Under site PRTSAID-TWN but you notice both sectors BCCH's [61, 43] are not exists in GSM Serving window as site is

down during drive test.



24

14-Dropped Calls;

During a call on TEMS, your call is suddenly dropped and you hear call dropped on TEMS.

Call is dropped due to only 1 reason which is the bad radio conditions [level or quality] from your serving cell, which

may occur due to any of the following reasons:

Bad radio conditions between your MS and the network is the only reason that may cause a call to drop, but the

question is why you remained on your serving cell until radio conditions turned bad, why you didn't perform H.O

to any neighboring better cell ?!

For sure you tried to perform H.O but this H.O may was delayed or failed or you couldn't perform H.O as the

neighboring cells to you were not defined as neighbors [Missing] to your serving now cell, so you remained on

serving cell until call is dropped.

So, dropped calls may occur due to 1 of the following reasons:

No or delayed H.O.

H.O failure.

Missing Neighbor to your serving cell.

Ping-Pong H.O.

We already proceed in all these 4 reasons in our before demonstrations.

NOTE: Any dropped call occurred due to [No service (Channel release)] in layer 3 messages on TEMS is considered

to be due to bad radio conditions from serving cell [Level or quality], BUT as for reasons like [Abnormal network

release – or any other messages, etc.] in layer 3 messages, you should differentiate if a dropped call occur due to

any of these messages while:

-Radio conditions were bad, then this call is dropped due to bad radio conditions.

-Radio conditions were good, then this call is dropped due to sudden hardware problem on serving cell BTS which

is not RF [Radio] problem.



25

15-TCH [Traffic Channel] Problem;

In GSM hopping channels window, you find a problem in a specific TCH [Traffic Channel] while other TCH's in

hopping window are good which will be due to 1 of the following reasons:

Cross feeder on TCH.

Faulty DTRU [Hardware problem].

DL interference [Co. or Adjacent].

1-Cross feeder on TCH:

Noticing bad Rx-Levels for specific TCHs in GSM hopping channels window while C/I value is fair in front of site

sector's main beam, the feeder carrying this TCH from TRX to antenna may be switched and fixed in another sector

antenna causing this bad level for this TCH.

2-Faulty DTRU:

Noticing bad Rx-Levels for specific TCHs in GSM hopping channels window while under site, this may be due to

cabinet TRX-DTRU card hardware problem which generates power for these TCHs.

NOTE: You have to make sure that these TCHs Rx-Levels aren't bad because of cross feeder problem that these

TCHs power are not being transmitted in another region with good levels before deciding that it is DTRU card

hardware problem.



26

3-DL interference [Co. or Adjacent]:

Noticing bad C/I values for specific TCHs in GSM hopping channels window while Rx-Levels for same TCHs are good,

this may be due to DL [Co. or Adjacent] channel interference affecting these TCHs causing high level of interference

on them in down link.

16-Good Rx-Levels in 1 direction BUT turned bad in opposite direction;

When performing DT for a route, moving from Cell 1 towards Cell 2 While served by Cell 1, you notice normal good

Rx-Levels on TEMS map BUT when moving backwards on same route from Cell 2 towards Cell 1 you notice that Rx-

Levels turned bad on TEMS map.



27

This problem may occur due to 1 of 2 possible reasons:

Served by DCS of Cell 2.

Delay H.O from Cell 2 to Cell 1.

1-Served by DCS of Cell 2:

You were served by Cell 2 DCS band with bad levels as DCS has high serving priority over GSM even if it was serving

with bad levels and GSM levels were better back then.

1-Delay H.O from Cell 2 to Cell 1:

You performed late H.O to Cell 1 may be due to poor H.O parameters or TCH congestion on Cell 1, this delayed H.O

causes these bad levels on route as Cell 2 was serving with bad levels until H.O occurred to Cell 1 and levels

enhanced.

-Imagine moving from site RS-UM-HUWAYTAT [Cell1] to RS-SAFAGA-STH [Cell2]:

Served by RS-UM-HUWAYTAT with good Rx-Levels along the whole route until performing H.O to RS-SAFAGA-STH,

so overall levels were good.

-BUT when moving back on same route from RS-SAFAGA-STH [Cell2] to RS-UM-HUWAYTAT [Cell1]:

Served by RS-SAFAGA-STH [Sometimes by its DCS and sometimes with its GSM] and both were with bad levels until

finally performed late HO to RS-UM-HUWAYTAT, so overall levels on the route back were bad.



28

17-Shifted Site Position;

Reaching under a site on TEMS map but in field reality you find no site exists at all in the area also you find that site

Rx-Levels in GSM Serving + Neighbors window aren't very good in the -40's or -50's dB [while under site] as

supposed to be.

Sometimes you perform a visit for a specific site and you reach its position on TEMS map but in reality you find no

mobile tower at all in the field and people told you that no mobile station exists at this place, So where is our site !?

So, how to find the actual position of this shifted site???!!!!

Moving all around the site region until reaching a spot where you receive very good levels from this shifted site

[-40's or -50's dB], so for sure site is very near to you somewhere, search for it !!!!

As shown in the following snaps, visiting a site named RS-HUR-VILLAS but when reaching under it by 300 meters,

noticing its bad levels in GSM Serving + Neighbors window and no site is found in reality so for sure this site is

shifted somewhere.



29

While moving around site region searching for it, suddenly noticed that site Rx-Levels turned very good when

reaching a specific spot and it turned that site is shifted in reality about 3 KM away from its position on TEMS map.



30

And as since the Cross [Feeder or Sector] problems are the most difficult detecting problems for drive-

testers........

So,

Stay tuned for 2G Problems [Part 2] which will be mainly about Cross [Feeder, Sector].

Thanks & good luck for you all.

For any questions, contact me on my e-mail or phone.

All About Drive Test Problems [Part 1]

Documents