[LENA] New CQI generation approach from GSoC 2014 LteFFR

[Saulo da Mata]

Hi everyone,

Last week, I pulled some updates from ns-3-dev repository, which include the GSoC 2014 LTE FFR merge.

Then, days after, I had to run a simulation script that I've been using in my research to reproduce some results that I published.

However, I could not reproduce the results that I got before the merge. The values of packet delay and packet loss ratio were quite higher than the previous ones.  

Looking for answers I observed that the average MCS value was lower in this new simulation when compared to the former one. Then, I concluded this new results were worse because the quality of the channel had decreased.

To make sure that the cause of the differences in the results was the LTE FFR merge, I got back to the changeset previous to the merge and repeated the simulations. As expected, I could reproduce the results that I got in the first place.

In this sense, I got a deeper look in the wiki page of the LTE FFR project. There, I found out that Gawlowicz implemented a new CQI generation approach. 

In week 4, he reported:

"Frequency reuse algorithms are used only for data channels and control channels are transmitted over entire cell bandwidth, o SINR value is lower for them and UE is served with lower MSC scheme. We have to find solution for that..."

Then, in week 6:

"During last discussion with my mentors, we agreed solution for CQI generation and I started to implement it."

And, finally, in week 7:

"I did not created tests during last week, because I spend more time on CQI generation. I implemented one solution, but after discussion with my mentors, we decided it should be changed and I spend more time to implement it once again in different way."

I also saw that he implemented a CQI generation test. I ran test.py and the test passed.

So, despite of the solution implemented by Gawlowicz, I'm getting a lower MCS value in my simulations.

In this context, I'd like to know if anyone else is also facing this kind of situation.

More details about my simulation script:

• I'm working with the LTE Uplink.
• I'm using a single cell scenario.
• I did not enable any FFR algorithm (from my readings, this is the default, right?).
• I'm using Evalvid Module as the application.
• Simulation stats were calculated with FlowMonitor. I also compared the results with Evalvid output files and LTE RLC Stats and I got similar results.
• I repeated the simulations 10 times with different seed values.
• The simulation used the default RR uplink scheduler and other 3 uplink schedulers that I implemented for my research. For all schedulers the average MCS value was lower after the merge.
• I placed different number of users in the cell (10, 20, 40, 60), using a 5MHz bandwidth.
• I did not attached my simulation script, since it uses custom applications that are not part of ns-3 official release. However, if necessary I can provide a script that works with the ns-3 official release.

Thanks!

--

Saulo da Mata

www.saulodamata.com.br

Federal University of Uberlândia - Brazil

[Tommaso Pecorella]

Hi Saulo,

sometimes removing a bug makes things appear worse, where they are just more realistic.

In your case, my LENA knowledge is not enough to decide if the current behaviour is the right one or not.

In any case, I think that Nicola is the best guy to take a look at this effect.

Cheers,

T.

[Saulo da Mata]

Hi Tommaso,

yes, this is precisely my doubt...if this worst behaviour is actually the more realistic one, so I think is important to use this newer version.

Let's see what Nicola or maybe Marco think about this...

Thanks for your comments.

Cheers,

--
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.

[Nicola Baldo]

Hi Saulo,

please see this section of the documentation, it has been updated to clarify how the new CQI calculation works and how to optionally revert use the previous calculation method instead:
http://www.nsnam.org/docs/models/html/lte-design.html#cqi-feedback

Nicola

[Saulo da Mata]

Hi Nicola,

Thanks for you answer...I took a look in the section of the documentation that you referred to, and, correct me if I'm wrong, but the new CQI generation approach "created for better utilization of data channel resources, when using Frequency Reuse algorithms" is valid for the downlink only, right? 

I mean, this new code did not change the uplink CQI generation that was in use before the merge of the LteFFR implementation, right?

I searched in the code for differences and to verify this hypothesis...

The structure of UlCqiFilter is prior to LteFFR. 

Then, I looked in the schedulers and I found the following lines:

m_ffrSapProvider->ReportUlCqiInfo (m_ueCqi); in method DoSchedUlTriggerReq.    (1)

and

m_ffrSapProvider->ReportUlCqiInfo (params); in method DoSchedUlCqiInfoReq       (2)

These lines are not present in all schedulers. This seems odd to me since all schedulers implement the uplink function in a Round Robin fashion. They are all the same in this aspect, then, why this diference? 

Anyway, I tried to track this method to see what it does. As I'm not setting any FFR algorithm, then the default choice selects the LteFrNoOpAlgorithm, which in practice "does nothing and is equivalent to disabling FFR". The ReportUlCqiInfo of this class says:

void

LteFrNoOpAlgorithm::DoReportUlCqiInfo (std::map <uint16_t, std::vector <double> > ulCqiMap)

{

  NS_LOG_FUNCTION (this);

  NS_LOG_WARN ("Method should not be called, because it is empty");

}

Well, in summary, if the new CQI generation approach affects only the downlink CQI generation, then my results should not present huge differences, before and after the merge of LteFFR, since I'm using the uplink.

Am I missing something here?

Thanks.

Cheers,

--

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.

[Nicola Baldo]

Hi Saulo, see inline

On Tuesday, September 23, 2014 3:57:40 PM UTC+2, Saulo da Mata wrote:

Hi Nicola,

Thanks for you answer...I took a look in the section of the documentation that you referred to, and, correct me if I'm wrong, but the new CQI generation approach "created for better utilization of data channel resources, when using Frequency Reuse algorithms" is valid for the downlink only, right? 

I mean, this new code did not change the uplink CQI generation that was in use before the merge of the LteFFR implementation, right?

yes you're right
 

I searched in the code for differences and to verify this hypothesis...

The structure of UlCqiFilter is prior to LteFFR. 

Then, I looked in the schedulers and I found the following lines:

m_ffrSapProvider->ReportUlCqiInfo (m_ueCqi); in method DoSchedUlTriggerReq.    (1)

and

m_ffrSapProvider->ReportUlCqiInfo (params); in method DoSchedUlCqiInfoReq       (2)

These lines are not present in all schedulers. This seems odd to me since all schedulers implement the uplink function in a Round Robin fashion. They are all the same in this aspect, then, why this diference? 

good point. This happened probably because we agreed with Piotr that only a subset of the (DL) schedulers were to be modified to support FFR. But for uplink since it's always the same RR implementation the code should be the same.

 

Anyway, I tried to track this method to see what it does. As I'm not setting any FFR algorithm, then the default choice selects the LteFrNoOpAlgorithm, which in practice "does nothing and is equivalent to disabling FFR". The ReportUlCqiInfo of this class says:

void

LteFrNoOpAlgorithm::DoReportUlCqiInfo (std::map <uint16_t, std::vector <double> > ulCqiMap)

{

  NS_LOG_FUNCTION (this);

  NS_LOG_WARN ("Method should not be called, because it is empty");

}

Well, in summary, if the new CQI generation approach affects only the downlink CQI generation, then my results should not present huge differences, before and after the merge of LteFFR, since I'm using the uplink.

ok but you are using the NoOp algorithm so the call to ReportUlCqiInfo shall be irrelevant.

Am I missing something here?

upink power control was also added by Piotr as part of the GSoC work, see the docs here:
http://www.nsnam.org/docs/models/html/lte-design.html#uplink-power-control

 

 

[Saulo da Mata]

Hi Nicola,

thanks for the help...I read the uplink power control documentation. Then, I repeated the test enabling/disabling this functionality, but the situation was the same.

Intrigued with this problem, I revised other parts of my script and I found an error when I was deploying the users (see attachment). I thought that I was deploying the users inside the rectangle in Figure (a), but actually I was deploying inside the rectangle of Figure (b). Consider the eNB in the origin. It was an error in the initialization of the Steady State mobility model. This particular arrangement cause the difference in the CQI experienced by the users before and after the GSoC2014 merge. I'm not sure why this happened.

Anyway, I tested with other PositionAllocators and MobilityModels and the results seems to be the same for both versions of the code. Only for that particular deployment I got substantial differences (Average MCS: 22 vs 13).

Since I corrected the error and I'm not using that weird deployment in (b), I decided to move on and stopped trying to find out why that happened.

Thanks for your time and attention.

--

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.

[Nicola Baldo]

Glad you fixed your problem, and thanks for reporting! If a similar issue appears again, we already have some good information from where to start further investigations.