Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

HO failure cause congestion

Viewing 15 posts - 16 through 30 (of 33 total)
  • Author
  • #61330

    Hi all
    Can someone enlighten me regarding ERP and EiRP and what is the formula used?
    Another issue that I have:
    I just implemented Intra-cell HO and HR/FR paramter to a number of sites and the result is what I expected (a reduction of HO drop)however, I am experiencing high volume of call blocking while there are still resources available. The percentage of time all resources have been used is 0% and still blocking calls. Can someone provides some help Please…!
    Something came to mind but I do not have any documentation to support it: I was thinking that the system automatically hold on to a number of time slots to allow the Intracell HO due to Bad Qual and the AMR FR/HR which gives priority to actual traffic (with a number of time slots already occupied) than incoming traffic. It seems that the system prioritizes the resources for actual traffic therefore does not allocate any resources for incoming traffic causing blocking. Please your help will greatly appreciated.

    Slim Tunisiana

    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??



    yes of course…
    number of ho rejected / number of ho requests

    is higher than

    number of call setup rejected / number of call requests

    a rejected HO will be reattempted several times (every T7 seconds!) until the target cell is eventually not congested.

    on the opposite, a call is attempted only once. Then it is up to the user to reattempt the call. An average user will try twice, then get bored and stop trying.
    The bsc is never bored of trying…


    slim OTT

    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


    hello Pix and Slimm OTT
    i’m dealing exactly the same problem bad KPI *TCH congestion* because it’s complex and also considers failures due to HO congestion
    That’s why when i increased the sizes of averaging windows as You advised in one of previous threads i noticed decreasing common amount of HO requests, HO itself and as consequently decreasing TCH congestion. I was watching one certain BSC and after recommended by you changes amount of HO req decreased for 17%. thanx you much for help I want to write earlier but I’m also far from civilization :0 i don’t have permanent access to internet
    I appreciate your help very much


    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.


    Can someone help me with which Handover windows should be adjusted in order to reduce handover?
    P, N values along with threshold value for Rxlev,PBGT etc or is there any other window margins which needs to be adjusted.
    Thanks in advance.


    too many questions….


    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

    – LILY –

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

    In the serving cell :

    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.



    Thanks Pix.
    I am currently facing a problem.
    We have one site at MSC border.
    The site is located in rural area and main purpose is to provide road coverage.
    Cell3 have No. of overflow include handover increase suddenly in certain hours.(60, 160 , 30 overflows all because of incoming handover’s).
    But with 0% congestion exclude handover.which shows no static user or slow moving user near the site.
    It may be due to train passing as railway track is along the road.
    Suggestions are required to handle this situation without going for expansion of trx.
    Thanks in advance.


    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 !



    there are no miracle solutions… perhaps activate Half Rate and remove some SDCCH timeslots to use them as TCH.

    What are the causes of HO ? PBGT ? Bad Level ?


    Explain russians that HO Congestion is not a subscriber issue (not directly, anyway) 🙂 And a definite solution is to change the averaging windows… well, it’s like asking you to swim 20km, you prepare for months for that… and then… I’ll tie your feet & hands together and push you in the water.

    Go now, swim…



    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.


    🙂 …. 🙁

    Dear Pix!

    You saw our country with your own eyes… Russia is the same kind…
    Did you see lots of sanity? 🙁

    We have written hundreds of letters, but received rather clear answer … m-m-m “don’t bother yourself, nobody would read your scribble”…

    … so very enthusiastically we’re learning to swim without hands and feet …



    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:
    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 ?



    Thanks so very much.
    Really appreciate your help.
    Take care

Viewing 15 posts - 16 through 30 (of 33 total)
  • The forum ‘Telecom Design’ is closed to new topics and replies.