PDA

View Full Version : Question How can I increase 64 QAM usage?



ltecity
2013-03-13, 07:11 PM
How I increase 64 QAM usage in the Network?

We have good CQI,94% of cells getting CQI >25.

But 64 QAM utilization very less.

Any controlling para in E// system.

electron
2013-03-13, 08:02 PM
You can increase hsMeasurmentPowerOffset parameter from 80 to 130 (maximum) but some how your re transmission can increase but practically it helps to utilize more 64QAM


How I increase 64 QAM usage in the Network?

We have good CQI,94% of cells getting CQI >25.

But 64 QAM utilization very less.

Any controlling para in E// system.

Handover24
2013-03-18, 06:53 PM
Another way is to cover better users...onhly a user in excellent radio conditions could use this modulation so try also with tilt adjustment.

babak1349
2013-03-19, 12:29 AM
Hello,
When CQI is better than 25 the 64 QAM will be used But it will be allocated when there is data to be transferred , If the scheduler doesn't have data or has small amount of data in buffer So allocating the high MCS would not make any sense
So you need to check
1) Iub limiting, if it is high, it means you have capacity problem on Iub
2) Do you have EUL activated ?
3) Have you checked in nodeB if 64QAM and Enhanced Layer 2 are licensed and activated ? please note 64QAM doesn't work WITHOUT Enhanced Layer 2 Feature
4) Have you checked if for all cells in Hsdsch (edw:/alex?fn=15554-CXC1727601_7-V1Uen.A.96.html) MO, enhancedL2Support and qam64Support are set to TRUE?



Best Regards

How I increase 64 QAM usage in the Network?

We have good CQI,94% of cells getting CQI >25.

But 64 QAM utilization very less.

Any controlling para in E// system.

Mdaf
2013-03-19, 05:55 AM
Hello, in addition to the above you need to check the % of the UEs that supports 64qam (based on cat #) and to utilize the 64qam these UEs that support 64qam should be in excellent rf conditions.

fon909
2013-11-27, 02:27 PM
We are facing the same problem in our network. However, all the above solutions recommended are checked and found to be correct. We are still lagging far behind on 64QAM usage, is there any other solution that can be looked into.


Thanks.

babak1349
2013-11-27, 03:00 PM
We are facing the same problem in our network. However, all the above solutions recommended are checked and found to be correct. We are still lagging far behind on 64QAM usage, is there any other solution that can be looked into.


Thanks.
I am wondering if you check it with drive test in the stationary state and good radio conditions?
If you are looking at statistics it would be very dependent on user activities and user profile in HLR
So suggestion is to do it only through drive test.... please bear in mind your UE must support 64 QAM as well
as you mentioned in your post your CQI must be above 25

cheers

kemesach85
2014-01-04, 05:04 AM
I think that you should check the information in Core Network. It may set a limitation of data download rate. This limitation will reduce %64 QAM usage

We are facing the same problem in our network. However, all the above solutions recommended are checked and found to be correct. We are still lagging far behind on 64QAM usage, is there any other solution that can be looked into.


Thanks.

electron
2014-01-04, 01:20 PM
There is no correlation to core network about modulation scheme assignment.Most probably fon99 insisting about low 64QAM on their network because he has made benchmarking with competitors who are using onther vendors equipment (Huawei or ZTE i guess) there are some differences of 64QAM assignment for these vendors rather than others . If let me know what are the vendors and how u suspect your network 64QAM is lacking i might give you some other idea to correlate the problem.


Cheers
I think that you should check the information in Core Network. It may set a limitation of data download rate. This limitation will reduce %64 QAM usage

ppsec123
2014-01-06, 09:16 AM
As far as I know, 64QAM is in pure correlation to your SINR and RSRP. If your pilot pollution is low and single strong servers are present, then 64QAM will be high assuming rest of the standard parameters have been set correctly.

firstmaxim
2014-08-05, 03:12 AM
The best option would be to set the scheduler to Max C/I. But then this would create disgrunted customers at the cell edge. As a trade off between round robin and Max C/I, we will opt for Proportional Fair Scheduler settings. Huawei calls it Advanced PF Throughput.

babak1349
2014-08-05, 03:41 AM
There is no correlation to core network about modulation scheme assignment.Most probably fon99 insisting about low 64QAM on their network because he has made benchmarking with competitors who are using onther vendors equipment (Huawei or ZTE i guess) there are some differences of 64QAM assignment for these vendors rather than others . If let me know what are the vendors and how u suspect your network 64QAM is lacking i might give you some other idea to correlate the problem.


Cheers

hello,
indirectly the core network can have impact. Imagine you have very good radio conditions and all resources available but in HLR profile ( I add to this TN QOS, nwtwork QOS, APN and so on)...you have the peak rate of 512 kbit/s so the maximum throughput you can get is 512 kbits
now the data is buffered in nodeB and scheduler based on available resources and CQI and the amount of data in buffer making decision about TBS size so even if you have all resources available and also hspa related features, but not much data in buffer, scheduler doesn't allocate the maximum available resources, it allocates what is required ( on demand)
it does make sense because simply , there might be another user which can use the other resources
The scheduler functionality really could be vendor based I heard for example in nokia couple of years ago, the nodeB scheduler was allocating hsdpa resources to a specific Hsdpa user and the rest had to wait. I meant there was no parallel hsdpa users connected .each time only one user was served

hope my comments can help


BR

electron
2014-08-05, 04:31 AM
Hi Babak,

You mentioned interesting correlation but i am in doubt about maximum peak rate and modulation scheme selection. Yes, i agree with you about HLR and SGSN and GGSN profile setting for user peak rate but even through having maximum peak 512Kb/s still scheduler is independent for transport block size and assignment of modulation type.Actually there is a table hard coded in RNC i have its structure how RNC correlate this assignment by RxQual and TF .

Regarding Nokia, maybe it is same as E/// about multiple HS-SCCH which actually is optional feature.Maybe in Nokia also it was not activated that's why just 1 user could be scheduled upon a time.


Cheers
hello,
indirectly the core network can have impact. Imagine you have very good radio conditions and all resources available but in HLR profile ( I add to this TN QOS, nwtwork QOS, APN and so on)...you have the peak rate of 512 kbit/s so the maximum throughput you can get is 512 kbits
now the data is buffered in nodeB and scheduler based on available resources and CQI and the amount of data in buffer making decision about TBS size so even if you have all resources available and also hspa related features, but not much data in buffer, scheduler doesn't allocate the maximum available resources, it allocates what is required ( on demand)
it does make sense because simply , there might be another user which can use the other resources
The scheduler functionality really could be vendor based I heard for example in nokia couple of years ago, the nodeB scheduler was allocating hsdpa resources to a specific Hsdpa user and the rest had to wait. I meant there was no parallel hsdpa users connected .each time only one user was served

hope my comments can help


BR

babak1349
2014-08-07, 04:21 AM
Hi Electron,
Hope you are doing well.
I don't thikn RNC is involved about TBS selection. (Maybe just RLC size) scheduler is nodeB and scheduler makes decision about TBS
If you look at the UE category description in 3GPP it might be more clear about how scheduler selects the TBS
User is reporting only CQI, then according UE capability and CQI, and available codes,... scheduler chooses the TBS size (we should add data in buffer as well, but let assume that is not limitation)
So based on the proposed 3GPP table the TBS size will be selected
As an example if your CQI is below 25, no 64QAM will be available for user, so TBS size will decreases
now there is vendor defined process how to correlate the TBS size with other affecting criteria ... again an example,,,, E******* has defined a "measure" which is named Achievable RX quality and based on calculated value the TBS will be chosen it has a formula based on CQI and available HS Power and other criteris and a offset.... (it does consider impact of power availability ) YOu can read it in Alex. there is also nodeB trace can give you a better view (super trace is the name)

In those cases any vendor should respect the 3Gpp standard other wise they might have problem with some UEs... for example UE may not support 8 HS codes and it can support 10 or 15 codes according 3gpp... so in this case scheduler can not allocate 8 codes

best regards

Now

electron
2014-08-07, 12:00 PM
Hi Babak,


Thanks, Yes you are right mistakenly i wrote RNC it is RBS as you corrected. 3 hard coded table based on RxQual is the key point. Reference is HSDPA User plane in Alex topic 9.2.2 . Let's take a glance. I have table information as well i will try to find it and share here. Anyway i guess our opinion is just different related to higher modulation scheme assignment and maximum allowed throughput profile. I guess the best way to prove it is just try some scenario in lab . As soon as i get enough time i will cross check it .


Cheers


Hi Electron,
Hope you are doing well.
I don't thikn RNC is involved about TBS selection. (Maybe just RLC size) scheduler is nodeB and scheduler makes decision about TBS
If you look at the UE category description in 3GPP it might be more clear about how scheduler selects the TBS
User is reporting only CQI, then according UE capability and CQI, and available codes,... scheduler chooses the TBS size (we should add data in buffer as well, but let assume that is not limitation)
So based on the proposed 3GPP table the TBS size will be selected
As an example if your CQI is below 25, no 64QAM will be available for user, so TBS size will decreases
now there is vendor defined process how to correlate the TBS size with other affecting criteria ... again an example,,,, E******* has defined a "measure" which is named Achievable RX quality and based on calculated value the TBS will be chosen it has a formula based on CQI and available HS Power and other criteris and a offset.... (it does consider impact of power availability ) YOu can read it in Alex. there is also nodeB trace can give you a better view (super trace is the name)

In those cases any vendor should respect the 3Gpp standard other wise they might have problem with some UEs... for example UE may not support 8 HS codes and it can support 10 or 15 codes according 3gpp... so in this case scheduler can not allocate 8 codes

best regards

Now