Huawei : Unscheduled TTI while at least 1 user has data in buffer

[kyokuman]

Hi,

To huawei experts, your help would be appreciated and rep will be given for any feedback

HSDPA.InactiveDataTtiRatio.Mean is a counter showing Average ratio of the time when at least one HSDPA user has data to transmit in the buffer but no HSDPA user transmits data at the physical layer.


I checked several networks, and the values are high, up to 60% on many cells, at the busy hour.

Do you have same behavior? What do you think about the root cause?

Counter is a ratio in PerMill, according to Hedex.

Is that possible that scheduling is that bad? What do you think about this?

Thanks for helping

[giegala]

Hi,

can you please confirm if the raw value reported in the counter is 60 or 600?

In HSUPA, nodeB send scheduling grants to UEs and UEs can use them, until they have nothing to send or until the grant is taken out. One possibility in your case could be that UEs do not decode correctly AGCH and/or RGCH in DL, due to too low power on the channels.

[kyokuman]

Hi Giegala!

Thanks for your interest in this! I'm glad to see at least someone answering it!

I confirm the value is 600 at BH on cell level! Please consider that I am talking about HSDPA here.

I have real doubts about the reliability of this counter, as many cells are showing 50% unscheduled TTI at the busy hour, which is very suspicious. And when I'm asking friends around the world, they have same values (more or less) in their huawei network!
Note that NSN has such counter as well, and it generally shows 0!


Thanks again

[giegala]

Hi,

sorry for mixing HSDPA and HSUPA. I do not have access to hw networks anymore, therefore i cannot check. If there is no mistake in how nodeb measures, the your values are really bad.

BTW, do you have Dual-carrier enabled?

[kyokuman]

Yes, DC is enabled.

Values are bad but it seems to be the case on all HW networks... Seems it does not bother anybody though...

[giegala]

Try switching off DC and check KPI. It could be that User is allocated 2 carriers, however there is not enough data in the buffer to schedule on both carriers (a very likely case, because most of the packets are small in smartphone application scenario), so only one carrier is used and carrier 2 is generating HSDPA.InactiveDataTtiRatio.Mean

[kyokuman]

Phemonemon is appearing on cells with DC disabled as well...

[giegala]

ok, so the reason must be elsewhere.

The only other reason for such stats, that i can think of is that all user data has been transmitted but not yet acknowledged by UE. The data still in NodeB buffer, but cannot be removed or scheduled, because it is waiting for ACK. However the counter values are just too high to believe such scenario.

Of course, the best is to open icare ticket onto HW. They are the best guys to find out the reason. Remember that some operators pay for icare tickets or have limited number of tickets per year. But other operators do not pay. Maybe your friends work for operator with free icare tickets.

[kyokuman]

Yes it could help, I will check with the operator.. Thanks for your help

[esoestemp]

Hi,

I don't really know whether you solved the case/discovered the true, but what you all think about the possibility for all the power to be occupied by R99 services(of course and common channels).
As far as I can remember the available power allocated for HSDPA is the rest available power: MaxTCP - Common channels - R99 power.
In such case it make sense to have high values of HSDPA.InactiveDataTtiRatio.Mean during BH.

Comparing to other vendors I found that case, I hope it could also help:
http://www.slashdocs.com/xuqiw/hsdpa-troughput-formula.html

Please share with us if you have any other new findings for explanation that case.

Regards