All About Drive Test Problems Part 1 PDF

‫بسم هللا الرحمن الرحيم‬
All about DT [DRIVE-TEST] problems

2G Problems [Part 1]
Prepared by:
Eng. Abdelrahman Ashraf Mostafa
RNE-Telecomax Consult
E-mail: aabdelsalam@telecomaxgroup.com
abdelrahman_ashraf@hotmail.com
Phone: +2-0109-6739100
All about DT [Drive-Test] problems
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.
By: Abdelrahman Ashraf Mostafa 2

-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.

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.

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.

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.

-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.

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.

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.

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.

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.

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???
Cell 1 Cell 2
Serving cell Neighbor cell
MS
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.

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.

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.

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.

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???

-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.

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.

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.

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.

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

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.

-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.

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.

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.

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.

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.

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.

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.

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 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

All About Drive Test Problems Part 1 PDF

Uploaded by

Copyright:

Available Formats

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

All about DT [DRIVE-TEST] problems

Eng. Abdelrahman Ashraf Mostafa

By: Abdelrahman Ashraf Mostafa 2

2-Bad radio conditions:

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

By: Abdelrahman Ashraf Mostafa 3

3-Hardware problem in ME handset:

By: Abdelrahman Ashraf Mostafa 4

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

By: Abdelrahman Ashraf Mostafa 5

By: Abdelrahman Ashraf Mostafa 6

By: Abdelrahman Ashraf Mostafa 7

4-Blocking/Reflections; Causes temporary bad levels problem

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

By: Abdelrahman Ashraf Mostafa 8

By: Abdelrahman Ashraf Mostafa 9

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

By: Abdelrahman Ashraf Mostafa 10

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

By: Abdelrahman Ashraf Mostafa 11

No or late handover can be due to:

2-Poor H.O parameters:

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

By: Abdelrahman Ashraf Mostafa 12

By: Abdelrahman Ashraf Mostafa 13

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

By: Abdelrahman Ashraf Mostafa 14

As shown in following snaps;

By: Abdelrahman Ashraf Mostafa 15

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

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

By: Abdelrahman Ashraf Mostafa 16

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

By: Abdelrahman Ashraf Mostafa 17

2-Bad quality on MS handset:

By: Abdelrahman Ashraf Mostafa 18

3-Data link failure:

By: Abdelrahman Ashraf Mostafa 19

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:

So, from network KPI point of view:

But from TEMS point of view:

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

By: Abdelrahman Ashraf Mostafa 20

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

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

By: Abdelrahman Ashraf Mostafa 21

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

By: Abdelrahman Ashraf Mostafa 22

By: Abdelrahman Ashraf Mostafa 23

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

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

By: Abdelrahman Ashraf Mostafa 24

15-TCH [Traffic Channel] Problem;

 Cross feeder on TCH.

1-Cross feeder on TCH:

By: Abdelrahman Ashraf Mostafa 25

3-DL interference [Co. or Adjacent]:

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

By: Abdelrahman Ashraf Mostafa 26

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