- This topic has 15 replies, 1 voice, and was last updated 9 years, 6 months ago by pushkar.
22nd November 2010 at 20:36 #65062SADIKIGuest
Could anyone help me please. I am currently experiencing NO HO COMMAND INITIATED at Layer 3 Messages until the call drops.(usually happens at INTER BSC/MSC but there are also cases at INTRA’s). All cell level param are defined properly(neighbor relation, external definition, mbcch, nccperm). Im working with ERICSSON Network (locating algorithm 1). Thanks in advance.23rd November 2010 at 08:36 #65063brotherGuest
if the target cell is external you need to define LAC,BSIC, BCCH..etc the neighbor cell are defined manuelly. So ıt can be defined by mistake. Can you check these values?
Brother23rd November 2010 at 13:22 #65064SADIKIGuest
Yes. All values are correctly defined.CEll / BSC / MSC level. The Outer LAC definition at MSC is ok.
Any other ideas?
Thanks.23rd November 2010 at 15:43 #65065pixGuest
NO HO COMMAND INITIATED
–> What kind of message is that ? It is not a layer 3 msg from the Air interface, so where have you seen this message ?
In your drive test tool ? In such case, this msg is generated by your DT tool itself, not by the BSS.
Your problem looks like the HO is not triggered even though the quality is bad, or that there is no “good” neighbour available.
In which cell does this problem occur ?
Cell at MSC border ?
Cell at LAC border ?
Cell “inside” a LAC ?
Cell without neighbours ?
When you see this, what is the problem ? Bad RXqual ? Low RxLev ? Better cell ? High TA ?
There are some E/// parameters that could filter out all possible candidate cells, so you should check them out (i don’t know their names…).
pix23rd November 2010 at 16:53 #65066SADIKIGuest
Sorry to confuse you. I mean the “Handover Command” message at Layer 3 is not initiated. This is INTER BSC, INTER MSC and INTER LAC at the same time. The Cell has immediate neighbors. The HO is triggered only on its INTRA BSC/MSC neighbors but when you cross to borders no handover command despite the difference in Rx lev is very obvious (like 30dBm). All CELL/BSC/MSC definitions wer check but all are correctly defined. SI5 contains all the BCCH of the neighbors both internal and external. No interference / hardware problem on its external neighbor base on kpi. Please help..Thanks.23rd November 2010 at 19:39 #65067pixGuest
this is a very very very common issue. Please don’t think I am being sarcastic or being a wise-a$$ : the problem is in the MSC !
Ask your NSS colleagues to double-check all the settings :
– are the external cells well defined ?
– are the external LAC well identified ?
This problem is always the same : HO inter MSC are not possible and yes, the MSC was already checked and all is good. And yet there is no HO… So …?
And the solution is always the same : “oh yeah, there was a mistake in the MSC definition… dammit !” 🙂
If you want to prove that the MSC is not doing its job, you just have to verify the following QoS counters :
from serving cell’s BSC :
how many HO REQUIRED are sent to the MSC ?
from the target cell’s BSC :
how many HO REQUEST are received from the MSC ?
If you obseve
“outgoing” HO REQUIRED = 1,000
“incoming” HO REQUEST = 0
–> Then it proves that the MSC is not forwarding the HO REQUIRED to the target BSC. It proves the MSC is not well-configured.
And if the counters show no problem then continue the same investigation : the target BSC should reply with the HO SUCCESSFUL [HO COMMAND] towards the MSC, and then MSC should forward the HO COMMAND to the serving BSC. Do the same comparison thanks to BSS counters.
Sometimes the HO works in one direction, but not in the other direction, it’s quite funny. But still, AFAIK, it is the MSC problem.
Pix24th November 2010 at 04:22 #65068SADIKIGuest
Thanks pix for your expertise..I’ll dig for this counter. I also requested redrivetest on the same and some other borders and if all are fix then something is happening on the MSC which they are keeping to themselves(lol). By the way, does syncronization on the BSC is not a possible cause?thanks24th November 2010 at 06:29 #65069ManiaGuest
you should alse get it checked if the destination LAC is defined in your source MSC. Mostly that is the case.24th November 2010 at 09:20 #65070Fresh OptGuest
Any one knows any docs about handover reference values. Let’s say what does it mean Handover Reference 18.
Fresh Opt24th November 2010 at 09:41 #65071pixGuest
the HO reference value is just the ID of the HO, so that the BSC can identify each HO which is happening in the cell.
You can see that in the 44.018
pix24th November 2010 at 09:53 #65072Fresh OptGuest
I just wondered if it’s related to any HO Cause.
Fresh Opt24th November 2010 at 14:12 #65073SADIKIGuest
Redrivetest result is ok. Seems that hey did some LAC defininition on MSC without my knowing. Thanks
By the way, does anybody knows about the BSC counters in ericsson related to what pix is talking about earlier?
“outgoing” HO REQUIRED
“incoming” HO REQUEST
Only “BSCCUMMS” (BSC counter) and TASSATT (CELL counter) I encountered related to inter BSC HO upon my research.
Please share your expertise. Thanks.24th November 2010 at 16:22 #65074pixGuest
that’s typical from nss guys ! it is a behaviour they must learn during their trainings…
you : “hey guys, there is a problem in your MSC’s definitions !”
them : “no no, we checked everything already, it’s all good”
you : “oh ok, nevermind then. you sure it can’t be a wrong LAC definition ?”
them : “no, no, don’t worry, all is fine”
2 days later, spending nights checking your BSS:
you : “hey, guys, it’s working now, have you changed anything ?”
them : “yeah, there was a little mistake in a LAC definition, but don’t worry, now it is fixed. You must not worry about this”
you : “GRRRRRR” (you become a werewolf and eat them alive)
again, i don’t want to be a wise a$$, but it is always the same scenario, over and over, all over the world.24th November 2010 at 20:02 #65075SADIKIGuest
hahaha…nice one pix!Probably 3GPP needs to revise the standards and include certain messages in the layer 3 like “Engr behaviour faliure” or “Engr not acknowledged”..lol I don’t wan’t to generalized though cause there are still good nss guys who will be open on the real problem but unfortunately mostly I encounter the opposite..thanks anyways..24th November 2010 at 20:33 #65076RexGuest
exactly the same scenario. I thought only our NSS is like that. Probably that they think they are unmistakable. Anyway, respect for NSS since they are the Core part.