hi alu,
no problem for the delay, it’s great that you continue sharing 😉
so both ways are impacted, and it is always in the execution phase, exactly as you experienced it during the drivetests. So there is nothing more that can be “proven” here, except that the failures are occuring in *both* directions, and not only in *one* direction as you described before.
(look at the outgoing efficiency rate in each cell, it’s around 80% to 85%).
so only 15% of calls are impacted by this failure. Which means it is not a problem that occurs all the time. Are those AMR calls ? FR ? HR ? MS which are GPRS-attached ? I don’t know.
Perhaps at has to do with few A-interface channels which are misconfigured (or AterMux ?), and as soon as a call is supposed to land on one of those channels after a HO, then there is a failure.
From A interface traces, are you able to isolate those faulty HO ?
Do you see the kind of radio channel and on which A interface those calls are being put on ? Is there anything similar among those HO ?
HO Required / HO Request / HO Response / ISUP msg / HO Command / HO Detected…
From those messages you should find all those info.. If you want to display all messages of one instance of a faulty HO here, don’t hesitate ! 🙂
The rtac will probably request such flow if they don’t already have encountered this problem before.
Regards
pix