- This topic has 1 reply, 1 voice, and was last updated 12 years, 11 months ago by pix.
7th November 2008 at 14:45 #54607NYKGuest
What are the main reason for delayed Handover?
I mean I have found several times from TEMS log files that,neighbors have sufficient rx_level (and of course higher then the serving cell by at least ho_margin or higer)but no HO was initiated (neighbor relation exists) and so the call dropped.
How to make the HO initiation quicker ?9th November 2008 at 10:11 #54608pixGuest
when a HO is “delayed” on the air interface, it can mean multiple things. It is probably not a wrong HO parameter though!
A handover ca be split in 3 phases:
1/ internal detection in the BSC: the Ho algorithm is verified
2/ neighbour selection + neighbour tch channel activation
3/ the HO command is sent to MS, so the MS “releases” the current TCH and tries to access the neighbour TCH.
In TEMS you can only see the phase 3. The 2 first phases do not have any visible effect on the Air interface and therefore you cannot know, with TEMS, if the problem lies in phase 1 (the algorithm is not verified, so either that’s a parameter problem or the conditions are actually not good enough to trigger a HO, or the BSC is in overload, unable to process the measurement reports -very rare !!-) or if it lies in phse 2 (the neighbour cannot establish a TCH, due to congestion or HW problem).
Now, you must ensure that the neighbour was not congested and able to establish a TCH when you were doing your drivetest. Congestion is probably the main reason why the MS didn’t receive its HO command in time.
Verify carefully that the radio conditions were good enough to verify the algorithm, during the “window averaging” period. Usually, it takes 4 to 8 seconds of “good measures” before a better cell HO is detected. An emergency HO takes about 2 to 4 seconds.
I hope that helps,