too many TBF cong happens for two reasons :
1/ your abis is totally overloaded
2/ the GP board (or GPU) is totally overloaded
Check if the cells which are congested are connected to the same GP board ?
If yes -> all cells with the issue are connected to one GPU and are suffering at the same time all together –> you should add more GP boards per BSC in your MFS.
If not -> the problem occurs only on random sites in your network -> add more extra nibbles on your abis’s.
In both case, you should actually be able to see the congestion on some other JPI’s as well : check out ABIS indicators, ATER indicators and MFS (DSP) overload indicators.
I checked all the counter of failures and highest failures are because of “P105k – NB_DL_TBF_EST_FAIL_TOO_MANY_TBF” which is defined as
Number of DL TBF establishment failures due to:
– a too low number of GCH to guarantee a minimum throughput for the DL TBF.
– This may happen when the number of TBFs is too high compared to the number
of available GCHs.
– or the MAX_TBF_TRX_DL_GP[U] constraint.
from which what I can understand is that there is the lack of resources between MFS and Site, either on ABIS or ATERMUX but when you check the congestin on ATER it is totally ZERO but there is sligth congestion on ABIS during the hours of degradations for example if too many TBF congestion is in thousands then ABIS congestion is in tens or twenties.So, it’s a bit confusing.
there are several ways to count the abis congestion, so maybe you are not looking at the right counter ? I don’t have them in mind, though, but you should get them from the abis objects in NPO, not the cells.
however, as i said, the abis might not be the problem : the other cause of this congestion is due to GP overload
“or the MAX_TBF_TRX_DL_GP[U] constraint.”
and this is not causing ABIS or ATER congestion. It is something else altogether, and you can verify it by checking the MFS object or GP object/kpis in NPO.
Viewing 4 posts - 1 through 4 (of 4 total)
The forum ‘Telecom Design’ is closed to new topics and replies.