- This topic has 4 replies, 1 voice, and was last updated 9 years, 10 months ago by
.
-
Posts
-
for the ALU BSC connecting to HUAWEI MSC, the GSM HO-out success ratio is a little bit lower. After check the trace, it is found that ALU BSC is sending two consecutive HO Required Request in less than 1 second (around 500~600ms) because the first HO Required Request is being processing, HUAWEI MSC will reject the second one result in degraded HO Success rate. is there any Parameter in ALU to control HO required request. We increased T25 to 2Sec but still BSC i sending 2 onsecutive HO Required Request
Hi Bilal,
Interesting. So basically your HO SUCCESS RATE is around 50% ?
I’ll check the specs tonight.
Regards,
PixHi Pix, Thanks for your response and yes your are right. I would like to add one more point that ALU BSCs are connected to Huawei & Ericson core and in both cases BSC is sending Double HO Required request, The ONLY Difference is that Huawei MSC is rejecting the 2nd request with CLEAR COMMAND while Ericson MSC ignores the 2nd HO Required request, So KPI degradation can only be seen under Huawei MSC and there is no impact visible for BSCs under Ericson core
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
pixHi Pix, Many Thanks for your support. We have escalated this case to TEC support and going to collect A-Trace in order to find why there is 2nd HO RDQ Req. I will update you with the the Trace results.
By the way I have another Interesting case in a new Thread 🙂
Many Thanks
- The forum ‘Telecom Design’ is closed to new topics and replies.
