- This topic is empty.
10th April 2008 at 18:22 #51849ArpanGuest
We are facing problem of high call drop rate after site shifted from one BSC to another BSC. Database is correctly defined. Wat can be the possible reasons?? Also problem is in specific cells; not in all cells..12th April 2008 at 06:53 #51850pixGuest
what is the cause of the call drop ? can you find a more specific indicator ?
if you didn’t change anything on the radio side, the problem is coming from your BSC or your Abis link. Therefore, it’s quite probably vendor specific… Have you tried deleting the BTS & cells and re-creating them ?16th April 2008 at 08:39 #51851Da ArchitectGuest
Would it be that old BSC and new BSC belong to two different MSC?
And when shifted the cell wasn’t created correctly in target MSC?
Is the new LAC for this cell update in MSC?
HO relation: this cell must be defined as external to old BSC, or outer to old MSC, with correct CGI.16th April 2008 at 18:08 #51852ArpanGuest
the two bscs are in the same MSC and lac.. the cause of drop is RLTC drop..17th April 2008 at 08:33 #51853pixGuest
radio link counter timeout… it means the BTS doesn’t receive SACCH frames from the MS or the MS doesn’t receive SACCH frames from the BTS. But it can be caused by a hidden problem.
Altogether, the TCH is already allocated, it means there is no real radio problem.. possibly, the A interface (or Ater) is wrongly connected.
what is the average TCH duration in those cells ?
I would check the A/Ater timeslot definitions… can you perform an A trace?
a good thing to do is :
*** a drive test ***
analyse the layer 3 messages, you will probably see that the TCH is allocated, but then something goes wrong.17th April 2008 at 09:50 #51854NarChaiGuest
data base of cell incorrect on MSC such as defind wong CI with wrong BSC or signalling point code