hi bilal,
i read the specs, a little quickly, so let’s try what i understood :
1/ it’s the timer T7 which prevents the serving BSC to repeat the HO REQUIRED too quickly. Increase this timer.
2/ The serving BSC will resent a HO REQUIRED to the MSC if there is a change in the possible neighbour Cell candidates. I doubt that this possibility is what is causing the repetitions in your case
3/ N PREF CELLS : says how many candidate cells are included in the HO REQUIRED. You might want to reduce this number (1 is a good value).
4/ There is a O&M parameter called RESP_REQ, which says whether the TARGET MSC should actually send a HO REQUIRED REJECT back to the SERVING MSC, in case the MSC itself cannot service the request. I’m not sure what’s the best value, but i’d say asking for a response is better.
5/ T HO REQD LOST EXPIRY should be increased, so that in case the target MSC does not REJECT the HO REQD right away, the BSC will not repeat the HO REQD too soon.
Ok, so basically, there are 2 timers you could play with.
Huawei behaviour, with the clear command, indicates that the MSC is actually trying to serve the 2nd HO REQUIRED. Obviously, the MS is already gone using the 1st HO REQD, so the 2nd HO REQD fails, and returns a HO Radio Failure.
You got to find why the BSC is sending 2 HO REQD, by doing a A interface trace maybe… do you notice a difference in both HO REQD ? Or are they having the same sequence number ? If they have the same seq, then it’s a fault in ALU BSC. It shouldn’t duplicate this msg.
Well, let me know how it goes…
Cheers
pix