Hello colleagues,

I analysed the provided traces.

I did not find any wrong behaviour in signaling messages. I found that the % Handover
failure/handover command are equal to 8,19%. But I cannot say if this value is too high
or not, because it depends on several factors (i.e interference, cell attribute, etc.). The
only chance to understand if we are facing to a problem, is to have counters for this cell
before the migration to Gemini. Unfortunately, when this BTS was in BR line the alarm
“channel above threshold” was not implemented. So in my opinion:
1- It is mandatory to have counters before the migration
2- It is better to investigate this counter on FlexiBTS since this alarm was present even
before migration to Gemini; and so the comparison is easier. (if I remember well
customer claims this problem after migration to Gemini Network both on ex-siemens
BTSs and ex-Nokia BTSs).
In any case, if you want to continue the analysis in this site please, provide me the PM
counters for at least a week before the migration to Gemini.
Hereafter I am reporting some data regarding to the first nethawk file.
ASSIGNMENT COMMAND

HANDOVER COMMAND
ASSIGNMENT FAILURE

HANDOVER FAILURE

% HandFai/HandCom
% AssFail/AssCom
Interval #

1 13 328 9518 4003 0,14% 8,19%

Investigating better the Handover Failures causes I found:

Count of msg
cause Total
- Abnormal release, no activity on the radio path
(04h) 22
- Abnormal release, timer expired (03h) 132
- Abnormal release, unspecified (01h) 123
- Frequency not implemented (0Ah) 2
- Normal event (00h) 13
- Protocol error unspecified (6Fh) 36
(blank)
Grand Total 328

With Best Regards, Marco