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,
Regards
pix