6- Handover Ping Pong (Repeated)
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
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.
Visit our Facebook Page
8-No or Late Handover
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
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.
[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.
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.
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
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.
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.
Visit our Facebook Page
10-Wrong shifted Azimuths
Visiting a site but you notice something strange in sectors levels as you sometimes suspect a crossfeeder 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] !!!!!
levels is bad, so case turned to be a suspected cross sector instead of being a cross feeder case between sectors 1 and 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???
Visit our Facebook Page
Prepared by:
Eng. Abdelrahman Ashraf Mostafa
abdelrahman_ashraf@hotmail.com