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

Impact of BTS_Queue_length to 8(ALU)

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #66887
    Sumair Azam
    Guest

    Hi all,

    I am working on ALU equipment and i would like to know if having the value of BTS queue length as 8 instead of 6 or 10 which are the default values depending on number of trxs(6 for trx number > 2 and less than 5, 10 for trx number in cell > 4). What good can we achieve by tunning it to 8 in a low traffic network. What are the cons of using 8 instead of 6 for cell having 3 or 4 trxs).

    Also if we put BTS_queue_Length as 8 for 2 trx cells instead of default value of 4 will it have any impact on CDR or any other significant KPI in a NOT congested cell. I can visualize the impact in case of a congested cell owing to impact on HOs(inc and out) and hence degrading CDR as a result but for low traffic not congested cell will it make any impact.

    @ pix: i am counting on you heavily to help me out here ๐Ÿ™‚

    #66888
    pix
    Guest

    hi sumair,

    it is a good idea to increase this number. Here are some extra info:

    1/ a MS which is requesting a TCH will get a TCH, if one is free.
    2/ if no TCH is available, then the MS is put in the queue if there is less than BTS Q LENGTH ms already waiting in the queue. Else, the call is rejected.
    3/ while MS is in the queue, the BSC will attempt to do directed retry (DR and FDR), will attempt Fast Traffic HO and wait for a TCH to get released in the serving cell. If any of those does happen, then the MS gets a TCH.
    4/ If nothing happens after “T11” seconds, then the call is rejected.

    In other words : if the cell is not congested, then the queue is empty. It is useless.
    The parameters bts q length and T11 are useless.

    Maximizing BTS Q LENGTH will not have any negative effect on subscribers, nor on QoS.
    Increasing T11 : the subscribers will “stay” in the queue longer. So they might wonder what is happening. 10s is the limit… after that, they wonder what’s happening and hang up by themselves – > by the way, if they do that, then that’s not counted as congestion… ๐Ÿ˜‰

    You will see some Qos indicators which show how “long” is the queue (hiow many MS in the queue), and what happens to MS in the queue : are they rejected, or do they find a TCH after all, etc.

    Thos indicators are located under the family “Forced Directed Retry”, or “TCH Queuing”, I forgot. Just search for “queue / queuing” in the list of indicators…

    Regards
    pix

    #66889
    Sumair Azam
    Guest

    Thanks a lot for your insightful analysis, its much clearer now, i already had an idea but just wanted to make sure ๐Ÿ™‚

    P.S i would also like to cite an observation regarding increase in BTS queue length before Christmas and new year night , for congestion relief it helped but it impact the global indicator for CDR .

    I believe the degradation was owing to less inc HO on congested cells which in turn when taken into the formula for glocal CDR degraded the KPI , a trial reversal for one BSC resulted in instant improvement on the that BSC wrt CDR.

    Correct me if i am wrong here.

    Thanks again

    ๐Ÿ™‚

    #66890
    pix
    Guest

    hi,

    it really depends on what is your formula for CDR. Did the actual number of call drops improved when you increased the queue length ?

    I would expect to see an increase of SDCCH Drops, since the SDCCH is seized for a longer time (the MS in a queue is using a SDCCH channel during its whole queuing duration)

    But an increase of CDR… that’s strange. The explanation about HO is not satisfying : whether there are 6 ppl in queue or 8 ppl in queue doesn’t change the fact that most cells are congested and cannot accept incoming HO.
    (Handovers are not put in a queue, except for the external one (BSC to BSC) )

    Whcih type of BSC are you using ? G2 or Mx ?

    regards
    pix

Viewing 4 posts - 1 through 4 (of 4 total)
  • The forum ‘Telecom Design’ is closed to new topics and replies.