- This topic has 3 replies, 1 voice, and was last updated 9 years, 5 months ago by pix.
4th August 2011 at 20:04 #66887Sumair AzamGuest
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 🙂6th August 2011 at 05:36 #66888pixGuest
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…
pix7th August 2011 at 17:43 #66889Sumair AzamGuest
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.
🙂8th August 2011 at 03:38 #66890pixGuest
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 ?