high TCH congestion at low traffic

Just check the H/W. this could be because of TS blocking. just for insitent make soft reset one cell and look on result………

NK,

I’m sorry if my question is stupid, but what do you mean by “terrestrial” ?

Are you getting 4% congestion rate on the radio channels ? In this case, you should be checking the number of channels on the radio interface, not on the terrestrial interface.

Final question : are you measuring TCH congestion or SDCCH congestion ? 0.92 erlangs seem a very low amount of traffic for TCH, especially on a cell with 58 ts for TCH…

IF during 1 hour you’re getting 4% TCH congestion rate on a cell with 58 TCH timeslot, and getting an hourly TCH erlang of 0.92 Erl, then it is either :

1. the software that is “freezing” the timeslots (cf. Naren’s post)

2. you TCH timeslot are preempted by PDCH (GPRS traffic), or SDCCH (signalling traffic, if your TS are defined as dynamic TCH/SDCCH). Therefore, check your SDCCH traffic and GPRS traffic (or PDCH occupancy)..

Regards,

NK,

but congestion is usually on the air interface, not both air and abis.

so where is your congestion air, or abis ? 🙂

so what you can do next is to check the TCH mean holding time in each TRX (and if possible in each timeslot).

Can you write also a table from hour 00 to hour 23, with (for which hour) tch congestion rate, tch mean holding time, tch erlang, number of tch seizure requests, number tch seizure success.

Thank you 🙂

NK,

Thank you for the QoS report, it is very helpful. You forgot the TCH mean duration time though… can you get this value for those 2 hours ?

In my opinion, this is an “artificial” issue, not a real problem. Either a counter problem, or a faulty software, somehow.

Maybe you should also check the TCH request for incoming HO and for call setup. You might measure TCH congestion due to incoming HO = 4%, while you’re having only 60 TCH requests for call setup.

Finally, in order to reduce the congestion, you could activate TCH QUEUING, and increase the timer T11. It might help…

Hello NK,

Well, you can imagine a supermarket for instance. The customer wants to pay at a cashier. If all cashiers are busy, then if leaves the supermarket, without paying. He’s not happy, and supermarket is not happy either 🙂

If the supermarket manager allows queuing, the customer will simply queue in a common line, and when he’s the first of the queue, as soon as a cashier is free, he’ll go there.

It’s exactly the same in GSM : during call setup, the mobile performs all the SDCCH signalling (authentication, ciphering, etc.) and then waits for a free TCH in a queue. I hope you understand how it can help reduce congestion now…

The queue is defined by :

1- a max queuing time (T11) : the MS cannot stay more than T11 seconds within the queue. Within this period he is allowed to wait for a TCH, after that, he’s rejected due to congestion.

2- a total amount of MS in the queue : not more than BTS_QUEUE_LENGTH mobiles can wait for a free TCH at the same time. If a MS number “bts_queue_length + 1” is asking for a TCH, it is rejected due to congestion

3- QUEUE_ANYWAY : if the MSC does not allow TCH queuing in the BTS, it can be “forced” by the BSC. But instead of using T11, it will use T11_FORCED.

Regards,

dear
for normal TCH drop
TN_DROP = TFNDROP + TFNDROPSUB + THNDROP + THNDROPSUB
and formula for subscriber perceived drop on TCH is T_DR_S=(TN_DROP/N_CALLs)*100
where
TFNDROP:- The number of dropped full-rate TCH in underlaid subcell.
TFNDROPSUB:- the number for the drop for hlaf rate TCH.
THNDROP and THNdropsun is total number for drop
hope it help you but dear this definition is not obliged to put you can modified as the operator want for example in other operator for call drop the took in to consideration the drop which happen due to handover which makeit call drop less than that with out handover this is way you can say tricky way .

Gito,

Out of curiosity : Why was there so much GPRS traffic in this cell ?