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

1

13

328

9518

4003

0,14%

8,19%

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

With Best Regards, Marco

% HandFai/HandCom

% AssFail/AssCom

Interval #

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.