HO failure cause congestion

Hi Pix,

Have you an explanation why the RTCH_HO congestion rate is much bigger than TCH_assign_cong rate although rhe number of HO request is lower??

Thanks Pix,
But in our network we have T7 = 7 seconds and my question is that during this time (T7)the radio conditions have normally changed so that the best cell is perhaps not the latest one.moreover , you have already said that in case of intra bsc HO the BSC tries to attempt the second , the third during T7 (in case the best one is congestionned)so it has more chances to find them not congestionned during this T7 period.
In case of inter BSC HO , yes it’s the case since it only attemp the best cell

Good evening Slim and Pix!

In one of our regions we have the same problem – high TCH blocking rate due to HO congestion. It’s an urban area with good coverage and high traffic, most of HOs are *better cells* ones. We’ve already implemented such features like Directed Retry, Forced DR, Traffic HO, Fast THO etc. All these actions of course gave some result, but our management wants more 🙂
We have some restrictions: can’t change HoM., Averaging windows and HO thresholds.
Now I would like to tune Cell_Evaluation process in order to decrease *attractiveness* of highly loaded cells after HO detection, but we have never done such things before 🙂
I would be very very grateful if your share your opinion (and maybe experience) in this question. Could it be really effective?

After scrupulous reading docs we have, next settings were chosen:

CELL_EVALUATION = Order_evaluation (as I understand it’s more appropriate than GRADE_EV here)

Free_Factor_1 = -15
Free_Factor_2 = -10
Free_Factor_3 = -3
Free_Factor_4 = 0
Free_Factor_5 = 3

Free_level_1 = 1
Free_level_2 = 3
Free_level_3 = 5
Free_level_4 = 10

Could it be dangerous? 🙂 and effective? 🙂

Many thanks in advance!

Best regards.
Lily

too many questions….

-SLIM-

in case of intra-BSC HO, the T7 method is not used. Sorry for my error. The target cells are tested one by one immediately by the BSC, as soon as HO is detected. In the nextr SACCH period if HO is still detected, the BSC will again try all candidate cells, until one of them is *not* congested.

now, for inter-BSC HO, during T7, if the best cell has changed before T7 expiry, the new candidate cell is sent to the MSC (new message “HO REQUIRED”). It is then up to the MSC to forward the HO REQ to the target BSC, etc. The new cell should supersede the old cell.

– SERGIO / BHT / LILY –
It is a common mistake : DO NOT USE HO Congestion in the TCH Congestion formula. It makes it artificially High. You should rather use the TCH “Normal Assignment” Congestion (TCNACGR), which is the proper way to monitor the congestion.
HO Congestion does not represent the reality, because BSC will attempt the HO so many times automatically !

But reducing the number of HO by increazsing the avg window is a great idea. The less the number of HO, the better.
A_PBGT_HO = 16
A_LEV_HO = 8
etc.

– LILY –

You misread the documents. The GRADE evaluation is WAY WAY WAY WAY better than the Order Evaluation.

In the serving cell :

CELL_EV = GRADE
EN_LOAD_ORDER = ENABLE
LINKfactor(0,n) = 0 (unless you want to give a static penalty or bonus to cell(n) )

And the load protection is done with those :
—————-
Load_Factor_1 = -2
Load_Factor_2 = -6
Load_Factor_3 = -9
Load_Factor_4 = -12
Load_Factor_5 = -15
—————-
Loadlevel_1 = 50%
Loadlevel_2 = 60%
Loadlevel_3 = 70%
Loadlevel_4 = 90%
—————-

I’m sure you understand how they work and how to tune them… The values I gave are tuneable, of course !

Why not “ORDER” ? Because you must tune each setting depending on the number of free TS left in the cell. Different cells with different number of TRX –> Different settings. Very tiresome to followup. Here, the Grade is using the “TCH Load”. It is smarter, nicer, cleaner, easier to follow-up.

Cheers
pix

Hello, Pix!

Thank you very much for clear and detailed explanation 🙂 shame on me 🙂
I’m starting to implement recommended settings. I’ll share the result – maybe it will be useful for somebody one day 🙂

About KPI *TCH_blocking_rate* – unfortunately we can’t just choose which formula to use…
We received from Moscow HQ new QoS standard and there was the next unambiguous formula:

TCH_Blocking_Rate(%) = 100 * (MC812 + MC541A + MC551 + MC561) / (MC812 + MC541A + MC551 + MC561 + MC15A + MC15B+ MC703)

Before we use this one:

TCH_Blocking_Rate (%) = 100.0*( MC812) / ( MC140A-( MC142E+ MC142F))

So now for us HO_congestion impacts TCH_blocking_rate (Most important KPI!!!) very much :((((

That’s why we’re now fighting windmills 🙁

Once more – many many thanks to you !

Dear Pix,
First of all thanks a lot for prompt response & knowledge sharing.
Its really so nice of you.
I have configured half rate tch but the problem is this site is S2/2/2.
So not many resources to play with but sudden peaks in traffic left me clueless.
HO causes are Uplink level,Uplink quality & PBGT.
thanks once again.

and do you see congestion on the 3 sectors ?

– from which cell are those HO coming from ? (that’s for you, I don’t need this answer 🙂 )

– could you check the indicator
RTCH_allocated_peak (GTCTRCAMN) per hour, and see if the max number of TCH TS are used ?

what we could try to do is share the incoming HO among the 3 sectors. We can do that by ensuring the 3 sectors are defined as neighbours with the serving cell.

Do that first, if it wasn’t done… And wait.

If it doesn’t work then it becomes complicated because the load evaluation is done every 5s. But let’s try :

In the serving cell and in the 3 neighbours:
CELL_EV = GRADE
EN_LOAD_ORDER = ENABLE
LINKfactor(0,n) = 0

And in the 3 neighbours
—————-
Load_Factor_1 = -10
Load_Factor_2 = -14
Load_Factor_3 = -16
Load_Factor_4 = -18
Load_Factor_5 = -20
—————-
Loadlevel_1 = 40%
Loadlevel_2 = 50%
Loadlevel_3 = 60%
Loadlevel_4 = 70%

By doing this, the BSC will quickly consider the “best” neighbour as loaded. The 2 further neighbours will gradually become more attractive.
It will work only if all inc HO are not coming exactly at the same time.

To avoid the second neighbour to send the traffic to the 1st neighbour (as a kind of ping pong situation), you should activate the Traffic HO between the 3 sectors :
with “i” and “k” from 1 to 3
EN_TRAFFIC_HO(ni, nk) = Enable
DELTA DEC HO MARGIN(ni) = 20dB
DELTA INC HO MARGIN(ni) = 20dB
HIGH_TRAFFIC_LOAD(ni) = 70%
A_TRAFFIC_LOAD(ni) = 1 (5s)
N_TRAFFIC_LOAD(ni) = 1 (5s)

Those settings are a test. They might generate unexpected behaviour… Be ready to rollback to default values.

This is a little weird, perhaps dangerous, but it will work IF you are in a rural area with almost no “static” traffic.

For the UL LEV and UL QUAL HO, you might also check the PATH BALANCE and the RMS of the serving cell.
Are there interference ? Or a bad coverage ?

cheers