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…