- This topic has 10 replies, 1 voice, and was last updated 11 years ago by paul.
12th April 2010 at 06:14 #62052PaulGuest
I would be grateful if anyone could help me to figure out, what parameter I have to set.
There is one cell, where in the DL TBF release Cause statistic, “suspend” DL TBF always happens. The customer always experienced a drop GPRS access.
I wonder what if this “DL TBF “suspend” is the cause of this case.
Is there any idea to reduce DL TBF “suspend”?
Paul12th April 2010 at 07:13 #62053BijoyGuest
TBF abnormal release due to “SUSPEND” happens if
1.MS initiates CS services during the process of PS services.
2.Cell is on the edge of the network location area and therefore the location updating of the MS is frequent.
Hope ,now you can troubleshoot.
Bijoy12th April 2010 at 08:07 #62054pixGuest
the Suspend is not “abnormal” : it is not a “TBF drop”
On the opposite ! A suspend is a normal scenario, when someone receives or makes a call while a PS transfer is on-going.
What happens next is that the TBF is “suspended”, and will be “resumed” at the end of the voice call. It is not a degraded behaviour, it is very normal.
You can’t reduce the number of suspend 🙂 Unlesss you change you subscriber behaviour…
Now, another question would be :
the TBF which were suspended are not resumed (you can check your indicators to find the ratio).
That kind of failure is not counted as a TBF Drop in ALU (afaik). Indeed, if resume is not done, the MS will re-establish a new TBF automatically. That’s why it shouldn’t be counted as a drop.
pix12th April 2010 at 08:39 #62055BijoyGuest
Resume will not happen if a LAC change takes place(Location update).Check if the cell is nearby a LAC boundary or overshooting to LAC border.
Bijoy13th April 2010 at 06:23 #62056PaulGuest
Dear Pix & Bijoy & All,
Thank you for your explanation.
Yes, indeed, suspend is normal, I’ve read that in ALU documentation, but your answer does make it more obvious, before, I really a bit confuse about suspend. Thanks 🙂
Then, if I may, i want to ask related to this.
1. If MS allocates 1 dynamic PDCH, then as this is PDCH dynamic (can be also allocated to TCH or suspend behavior) and voice TCH is too high at that time, it pushes TCH to use the seized PDCH Dynamic, then what will happen if the TCH still use that Dynamic PDCH for a long time? I think the MS can’t browse the internet anymore if the TBF doesn’t resume (Please correct me if I’m wrong). Will this case affect the MS to break down the internet connection?
2. I have a case where in that cell, traffic voice is low, but traffic Data demand is high (1E1 Abis). Then I set MIN_PDCH=4, MAX_PDCH_HIGHLOAD=8 and MAX PDCH=14 (4 TRXs). Unfortunately, the user can’t use BBM (Bleckberry), email, and browsing. But, when I re-set the configuration became MIN_PDCH=2, MAX_PDCH_HIGH_LOAD=2, and MAX_PDCH=11 (40% of Available TCH), the user can access easily.
My analysis is related to the available GCHs in Abis. Is there any possibility that when we assign MAX_PDCH_HIGH_LOAD(or MAX PDCH >40% of Available TCH) too high or = MAX_PDCH, it will affect the accessibility? As I know, MIN_PDCH==> has dedicated GCHs reserved in Abis, MAX_PDCH_HIGH_LOAD ==> has dedicated GCHs as demanded (if the nibble/GCH is not used by traffic voice, it would be used for dedicated traffic data), MAX_PDCH ==> Has no GCH reserved. Then, perhaps, when we assign too high MAX_PDCH_HIGH_LOAD, it will force to always reserve the GCHs in Abis, meanwhile, no GCHs available again in Abis. Am I right?
3.Please help me out to clarify my understanding of this example below : If I set MIN_PDCH (dedicated PDCH)=2, MAX_PDCH_High_LOAD=3, MAX_PDCH=8. It means, when 2 dedicated PDCH have been used, then other MSs can use other PDCHs, example 2 PDCHs (which mean 1 PDCH is in PDCH_HIGH_LOAD, 1 is dynamic PDCH). That 1 PDCH in PDCH_HIGH_LOAD can’t be used by the TCH, but 1 PDCH in PDCH dynamic, can be used by TCH (Suspend)when Traffic voice is high. Am I right?
Well, thanks again all experts in the world!
Paul13th April 2010 at 19:18 #62057pixGuest
sorry, i don’t have time to explain all those concepts.
but your problem with the blackberry user is weird. I doubt that what you have done (the new settings) are really helping. It is probably just a coincidence.
In RNO/NPO, can you check the Ater_congestion and DSP load & overload (per GPU) ? A bottleneck in those area could explain the subscriber problem.
each pdch which is “min pdch” is associated with 1 GCH.
all other PDCH are dynamically associated with their GCHs. Whether they are in max pdch highload or max pdch doesn’t change anything.
don’t forget that 1 PDCH can require up to 4.5 GCH to operatore in MCS-9. The high the MCS, the higher the number of GCH needed.
Decrease your MAX MCS to save on the Ater Ps and DSP load.
pix14th April 2010 at 03:06 #62058paulGuest
Thanks you for your response.
Well, that’s OK, i’m sorry also to ask you and all expert with such a long example and question.
Hopefully,If you have time, you could explain it to me briefly 🙂
If I shorten my question :
1. If TBF doesn’t resume, would it affect to the connection loss?
2. Is it okay to set MAX_PDCH higher than 40% of available TCH? From your explanation, it doesn’t matter to set MAX_PDCH higher than 40% if voice traffic is low and has enough Abis capacity(2 E1, with 1E1 only for Extra TS, or no Abis COngestion and Ater Congestion).
3. I Hope, my conclusion is right 🙂
O yeah, I’ve checked Ater & DSP load, no congestion happened either in Abis or Ater. DSP load still in a safe condition.
Okay, thank you Pix and All.
If you have time, please answer it briefly 🙂
Paul14th April 2010 at 06:09 #62059PixGuest
Here goes the big answers 🙂 let me know if that’s clear enough…
When the TBF is suspended, it means that it is actually “released”. In other words, the user has ONLY a TCH timeslot, and no PDCH at all.
At the end of voice call, a new TBF will be established (= resume).
During the voice call, the user cannot browse the internet anymore.
2) yes, you can set max pdch as high as you want, because the BSC will anyway allocate the “real” number of PDCH depending on the TCH usage. Even if you put max pdch very high, the “voice capacity” of the cell will not get congested.
well, this question is a little obscure. MIN PDCH are statically allocated. On each PDCH, there could be up to “MAX_TBF_PER_SPDCH” subscribers (users are multiplexed onto the same timeslot)
Each user can use up to “MAX_PDCH_PER_TBF” consecutive timeslots.
The MFS will allocate as many PDCH as possible before “multiplexing” users on the same PDCH. It can allocate up to max pdch timeslots.
when the voice usage gets high in the cell, the previously allocated PDCH are de-allocated. Only the last “max pdch high load” timeslots will remain allocated to the subscribers.
Users that were located on the preempted PDCH are not dropped : the MFS attempts to reallocate their TBF on the other PDCH. The throughput will decrease, but the connection remains available.
Note : only the MS that are “DTM capable” can support both PDCH and TCH at the same time. This is a B10 feature. Most MS are not DTM capable.
pix14th April 2010 at 11:16 #62060PaulGuest
I conclude :
1. The lost connection of internet has no relation with TBF resume/suspend.
2. It doesn’t matter if we set MAX_PDCH > 40% eventhough I just have 1 E1. It just a matter of throughput. If we allocate many PDCHs, and set the MAX MCS = 9, perhaps, with many subscribers, the probability to have MCS-9 is very low. The throughput is not only depend on PDCH allocated in BTS, but also the capacity of GCH in Abis. 🙂 ==> as long as no bottle neck in Ater/GPU.
3. Thanks, your answer really clear out my confuse. 🙂
Thanks A lot everybody. 🙂 This forum is very fascinating!
Paul14th April 2010 at 16:17 #62061pixGuest
all you said is good, except 1/
the suspend state means the internet connection is lost *during the voice call*
but ok, i understand what you meant : “in QoS stats, the suspend should not be considered as a drop” 🙂
glad I could be of some help,
have a good day,
pix15th April 2010 at 04:29 #62062paulGuest
Many great thanks to you! 🙂 It seems that you’re expert in ALU :):)