- This topic has 5 replies, 1 voice, and was last updated 10 years, 4 months ago by SHELDON.
5th May 2010 at 13:39 #62496safarGuest
here i have tbf release due to pcu reselection and ra reselection and i have high no in counter fludisc and flumove .
so can anybody plz explain exact meaning of this counter?
and if i activate loss free preemption then will this help?
because in loss free preemption llc will remain after tbf release for 10 sec so is it?5th May 2010 at 17:23 #62497SHELDONGuest
The counters are defined as follows:
“FLUDISC:Number of times the entire contents of a downlink buffer in the PCU were discarded due to an inter RA cell reselection or inter PCU cell reselection (i.e. Flush message received in PCU that deleted the contents of a PCU buffer).”
“FLUMOVE:Number of times the contents of a downlink buffer in the PCU were moved to another queue due to a flush message received in the PCU.”
I think you should look at your RA design. High values of these counters indicate many inter-RA cell reselections. You also mentioned inter-PCU cell reselection. How many PCUs do you have? What are the PCU utilizations?
I don’t believe implementing loss-free preemption will help. According to ericsson, loss free preemption applies in the following cases:
1.Preemption of essential PDCH
2.TBF setup failure
3.Intra cell handover of Dual Transfer Mode (DTM) connection
4.Mobile switches from DTM to Packet Switched only mode (CS call release)
5.BSS switches Abis transmission rate when Flexible Abis applies.
Hope this helps.
SHELDON7th May 2010 at 08:06 #62498safarGuest
ya buddy u are right i also go thr alex for same but i want to understand when this counter FLUDISC will increment i mean what happens actually when pcu buffer will be discarded while moving from one ra to another or one pcu to another pcu?
and i think if u see in alex with loss free preemption with this case ra and pcu reselction here tbf will not release immediately it will store llc frames in pcu abt 10 sec and in between if user try again then tbf will continue.
plz share if i am wrong.8th May 2010 at 10:05 #62499safarGuest
waiting for reply…9th May 2010 at 13:12 #62500safarGuest
Buddy where are u?10th May 2010 at 14:01 #62501SHELDONGuest
Once again, sorry for my delayed response.
When an MS is engaged in a downlink packet transfer, it’s data is kept in a buffer (or queue) on the PCU. Now if the MS reselects another cell, it sends a cell update message to the SGSN. When the SGSN notices that the mobile was already engaged in packet transfer, the SGSN sends a FLUSH message to the PCU of the old cell. The contents of this message can result in one of the following:
1. If the new cell belongs to the same RA as the old cell, then the PCU moves the contents of the buffer to a new buffer for the MS, and the counter FLUMOVE is incremented.
2. However, if the new cell is in a different RA, then the PCU discards the contents of the buffer, and FLUDISC is incremented.
I’ll say once again that I don’t believe implementing loss-free preemption will reduce the values of these counters.
Whenever you have an inter-RA cell reselection, the TBF is released, and a new one is setup in the new cell.
If you can get statistics on these counters on cell level, you should be able to identify the worst cells and see how you can redesign your RA.
Hope this helps.