[LENA] uplink cqi timers

[Vikram Chandrasekhar]

Hi NS3-Experts,

I noticed the following data structures m_ueCqi and m_ueCqiTimers maintained within scheduler. Looking at the data structures, the uplink CQI (SINR) for each UE is maintained on a per-RBG basis whereas the UL CQI-timer value for each UE is only stored as a scalar. Then, is it correct understanding that the schedulers do not consider how stale the SINR values have gotten on an individual RB? In other words, if the UE has received an uplink grant on RB1 more recently than RB2 then the measured CQI (SINR) on RB1 is more reliable compared to RB2.

I would have expected that the UE timer values should have been stored on a per-RBG basis so that the scheduler can know how reliable the stored CQI is for an individual RB.

Some clarification would be greatly appreciated.

thank you,

Vikram

  /*

  * Map of UEs' UL-CQI per RBG

  */

  std::map <uint16_t, std::vector <double> > m_ueCqi;

  /*

  * Map of UEs' timers on UL-CQI per RBG

  */

  std::map <uint16_t, uint32_t> m_ueCqiTimers;

[Marco Miozzo]

Hi Vikram,

sorry for the late reply.
As highlighted in previous posts, the scheduler implementations are not intended to be as the most complete ones, especially considering the fact that the standard does not define any behavior on this respect.

Your proposal sounds interesting; however its implication from scheduling perspective is far from be trivial (e.g., how we can define reliability in terms of RBs? it depends on fading, mobility, interference and as you suggested on the time the report has been received). This is the main the reason of this implementation assumption, in LENA we tried to put only standard solutions, well known algorithms or trivial solutions (e.g., use the worst CQI value when TBs are made of several RBs). I know this might be suboptimal in many cases, but this was a requirement of the LENA project.
Concluding, I consider that it is definitely interesting to have this kind of functionality even its application it is not trivial. On this matter, if you are aware of any standard or well know literature solution,  it would even better, since it might be directly included.
Contributions are welcome!

Regards,

marco.

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Vikram Chandrasekhar]

Hi Marco,

Thanks for your detailed reply. I understand and completely agree the constraints within which the LENA code was developed, so I guess it was preferred to have a simple solution namely a single ulCqi timer per UE. Anyway, the LENA code is such high-quality (thanks to you and the other CTTC folks) that I am happy to add and make more changes.

Here is the changes I did. I do not mean to suggest that LENA also modify the code in the above manner (you might have performance issues in mind when taking the cqiTimer to be one scalar per UE) :-)

First I make the variable m_ueCqiTimer as a vector of uint32_t per the following :

 std::map <uint16_t, std::vector<uint32_t> > m_ueCqiTimers;

Second, I modified the method DoSchedUlCqiInfoReq () so that whenever a new vector of SINR is returned from the PHY to the MAC, only the RB on which the SINR is modified, and their timer values are initialized to m_cqiTimersThreshold. This way, whenever the RefreshUlCqiMaps () method is invoked within the scheduler, only the resource blocks whose corresponding timer values have expired are deleted.

Thanks again, Marco!

- Vikram

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/e8vIy2xb8Vw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.