UCELLLDRULTTICREDITSFRESTHD parameter ?

[fahmi]

Dear Huawei experts,

I need some clarification about UCELLLDRULTTICREDITSFRESTHD parameter :

• What is the concrete meaning of this parameter ?
• The actual value range are (8SF4, 7SF4, 6SF4, 5SF4, 4SF4, 3SF4, 2SF4, SF4, SF8, SF16, SF32, SF64, SF128, SF256) : what is the meaning of these values ?
• How to choose between these values ?

BR,
Fahmi

[giegala]

Hi,

check out "HSUPA TTI Selection" document from WCDMA RAN1x.0 Feature Documentation library. It is about 2ms to 10ms TTI switching at high CE load

[fahmi]

Thanks giegala,

ok, when activating the 2ms TTI in RAN 12, we faced a CE congestion despite the CE utilization is < 60%.
Huawei recommends to change the parameter ULTTICREDITSFRESTHD=8SF4 (default value SF8)and it works very well.

I cannot understand two things :

1. how to interpret 8SF4 (the meaning of 8) !!
2. how could 8SF4 uses less CE than SF8 !!

Please find in the attachment the Huawei description of the solution.
Waiting for your comments.

Warning on Admitted CE Congestion on the RNC Side After the HSUPA 2 ms Feature is Activated.rar

[giegala]

Hi,

1. 8SF4 = 8xSF4 -> NodeB should start 2ms->10ms TTI switching when idle CE in the cell is below the setting. from CE table (huawei) doc i see that it would be 8CE *8*SF4 = 64CE
2. SF8 uses 4CE, while 8SF4 = 64. Because switching is started when remaining CE is below the threshold. So, 8SF4 setting will start 2ms switching to 10ms earlier that sf8 setting

i would suggest you to use ULTTICREDITSFRESTHD in command UNODEBLDR (instead of UCELLLDR). Because latter will work only when you have dedicated CE per cell. In most cases you will have CE group that shares CE across several cells and parameter in UCELLLDR will not work. [ i have found it the hard way]

CE admission congestion happens, because of 2 reasons:
1. when Dynamic CE is used, RNC does not know how much exactly CE are consumed in nodeB, it would estimate from configured RABs in the cell. It will consider that 2ms TTI will use more CE. In normal condition (when you have many smartphones with 2ms TTI capability) RNC will consider that you have more CE used up, that it is actually.
2. i have suspicion that CE counter in NodeB gives you average values, instead of maximum. So, exact consumption of CE is not known.

Reps are appreciated

[fahmi]

Dear giegala,

Very nice explanation .


Could you please tell me why 2ms TTI will use more CE than 10 ms ?

and in such a case (ULTTICREDITSFRESTHD = 8SF4 instead of SF8), don't you see that we will push users to be 10ms and not 2ms especially with limited UL CE and here we may not take advantage of the HSUPA 2 ms TTI feature activation ??

Do you know any huawei counters that measure the proportion of 2ms and 10ms users.

By the way, I checked the ULTTICREDITSFRESTHD in command UNODEBLDR and it was already set to 8SF4.

BR,
Fahmi

[giegala]

Hi,

Could you please tell me why 2ms TTI will use more CE than 10 ms ?

2ms TTI uses more CE, because maximum SF is SF4. For 10ms maximum SF is SF32 -> from Huawei CE description. And probably based on that RNC considers that 2ms uses more CE than 10ms.

and in such a case (ULTTICREDITSFRESTHD = 8SF4 instead of SF8), don't you see that we will push users to be 10ms and not 2ms especially with limited UL CE and here we may not take advantage of the HSUPA 2 ms TTI feature activation ??

correct observation. But in general it is better to give more user lower throughput services, that to give high throughput to few, and leave the rest without anything.

Do you know any huawei counters that measure the proportion of 2ms and 10ms users.

In R14 and R13 there are, like VS.HSUPA.Mean.User.tti2ms . More counters have been added in R14. I do not know about R12. Search for counters containing strings "2ms", "10ms" and "TTI" in M2000.

In nodeB counters you should find VS.HSUPA.2msPDU.tti.num and VS.HSUPA.10msPDU.tti.num

Regards