- This topic is empty.
20th August 2007 at 06:24 #48911NKGuest
Thanks in advance. In our Siemens Network, even at 0.92 E we have congestion of 4% for 58 channels(terrestrial). Such congestions have occured in many cells. What could be reasons for such a congestion?20th August 2007 at 07:26 #48912NarenGuest
Just check the H/W. this could be because of TS blocking. just for insitent make soft reset one cell and look on result………20th August 2007 at 08:27 #48913NKGuest
Thank you for your suggestion. But the congestion occur some hours but not continuously.rest of hour it is carrying normal traffic. The Radio Command gives Alarm of “Resource Unavailable” for that congestion. Can we use your suggestion in this case also?20th August 2007 at 08:48 #48914pixGuest
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,20th August 2007 at 09:02 #48915NKGuest
Thanks for your advice. Of course congestion is in air interface and abis interface is not via satellite therefore it is terrestrial link. In my network, of course few(2) channels are defined as TCH/SDCCH.
Also, priority is given to voice call. Therfore, Voice traffic will preempt PDCH.
Any suggestion!!!20th August 2007 at 09:18 #48916pixGuest
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 🙂20th August 2007 at 10:23 #48917NKGuest
Thank you once again. Congestion is in air interface not in Abis. For that paticular hour:
NO OF TCH ASSIGNMENT:60
TIME:05 AM- 06 AM
% TCH ASSIGNMENT:98.33
NO OF TCH ASSIGNMENT:1090
% TCH ASSIGNMENT:99.358
The abnormal congestion doesnot last more than one hour.20th August 2007 at 11:44 #48918pixGuest
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…21st August 2007 at 04:22 #48919NKGuest
Thank you for your incessant suggestion. Can you explain how TCH queueing will solve the problem?
Nirendra KC21st August 2007 at 07:34 #48920PixGuest
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,27th September 2007 at 07:16 #48921hyatham SenGuest
I would like to know the exact formula for TCH Drop in Ericsson, &what is the different between Normal TCH Drop & Subsciber recieved TCH Drop.27th September 2007 at 08:52 #48922asoGuest
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
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 .30th September 2007 at 06:16 #48923Gito PrastomoGuest
I think I agree with PIX for point 2. I have also experienced with this.
THe TCH Blocking occured but the traffic was very small. Then I checked the GPRS PDCH Traffic, then i saw there are GPRS traffic. Because in the counter, GPRS traffic is not counted as voice traffic so the traffic show very small although in BSC database setting the GPRS is down grade first, but this problem still occured. Then I discuss with customer to disable GPRS in the cell that indicated problem to see the performance, then resulted in normal condition.1st October 2007 at 19:44 #48924pixGuest
Out of curiosity : Why was there so much GPRS traffic in this cell ?2nd October 2007 at 08:07 #48925Hi Pix,Guest
Yes Pix, that GPRS Traffic is real GPRS, because the cell is served our customer office and they has free APN to access GPRS, and they realize this condition