[LENA] Bug spotted in NS3 uplink scheduler.

[Vikram Chandrasekhar]

Hello NS3- Experts:

Inside the HARQ retransmission handling code of uplink scheduling, I noticed that the current implementation will result in an uplink HARQ retransmission occurring infinitely often.

Here are the bugs and my suggested fixes:

   1. First you check whether the number of reTx for a given HARQ ID >= 3, if so, you drop the HARQ process for that RNTI. However, the HARQ retransmission number does not get reset to 0 before dropping. My suggestion is to add the green highlighted code.

  if ((*itStat).second.at (harqId) >= 3){ (*itStat).second.at (harqId) = 0;   NS_LOG_DEBUG ("Max number of retransmissions reached (UL)-> drop process"); continue; }

2. Second, the current code always sets the HARQ retransmissions to zero. Specifically, I suggest commenting out the code that resets the # retransmissions to 0 as shown in green highlights.

// Update HARQ buffers with new HarqId

                (*itStat).second.at ((*itProcId).second) = (*itStat).second.at (harqId) + 1;

                // (*itStat).second.at (harqId) = 0;

[Marco Miozzo]

Hi Vikram,

the status 0 it does not represents a variable reset, while it means that a new HARQ block with RV equal to 0 (i.e., the first redundancy block) has been sent in that process, this is the reason of the implementation choice you found. This means that I'm not 100% sure you code might be correct according to the variable definitions.

The fact that a a maximum number of retx has been reached and the processes are blocked, has already been solved by refreshing the Harq process status list.

However, the implementation is far from being optimal, and it is a open to refinements.

Finally, for the bugs I would suggest to use bugzilla, which helps in managing and maintaining tracks of the bugs.
https://www.nsnam.org/bugzilla/

Best 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 quick response: much appreciated. I agree that the value "0" for a particular HARQ process within m_ulProcessHarqProcessStatus means that a new HARQ block with RV = 0 has been sent. Following your explanation, I realized that I had misunderstood how the HARQ process buffer statistics were being correctly updated on each TTI. Thanks again and I apologize for my misunderstanding :) 

However, I still am a bit confused as to how the entries and indexing of the array inside m_harqBufferStatus [for a given RNTI] is to be interpreted. Perhaps this issue I raise has been fixed in 3.20: there have been a few code changes in the UL scheduler between the version I use (3.18) and the current version (3.20).

Nevertheless, just so that I point out my confusion, let me explain below:

Let me explain below: Per lines 1491 - 1494 (copied and pasted below): for a given RNTI, as part of the retransmission handling code, whenever (*itStat).second.at(harqId) equals 3, the code always skips and proceeds to the next rnti (user). Thus the code never reaches line 1524 [wherein the code resets the timer value on that harqId to equal 0]. 

To summarize, whenever a certain UE has 3 retransmissions on a certain HARQ process ID [e.g. that user has poor channel conditions resulting in retransmissions happening very often], then that user's (*itStat).second.at(harqId) value always stays fixed at value 3. My question is whether this is the desired behavior? I am not sure it is. That is why I suggest that between lines 1492 and 1493, we set (*itStat).second.at(harqId) = 0.

Hope this clarifies.

Thank you,

Vikram.

if ((*itStat).second.at (harqId) >= 3)

1491  {

1492  NS_LOG_INFO ("Max number of retransmissions reached (UL)-> drop process");

1493  continue;

1494  }

1522  // Update HARQ buffers with new HarqId

1523  (*itStat).second.at ((*itProcId).second) = (*itStat).second.at (harqId) + 1;

1524  (*itStat).second.at (harqId) = 0;

1525  (*itHarq).second.at ((*itProcId).second) = dci;

1526  ret.m_dciList.push_back (dci);

[Marco Miozzo]

Hi Vikram,

Sorry for the confusion but I was mixing the DL and UL HARQ solutions. Yes, you are right that it seems that the HARQ process might get blocked.

However, exploiting the synchronization behavior of the UL HARQ process I would go with something like this

      // store DCI for HARQ_PERIOD
      uint8_t harqId = 0;
      if (m_harqOn == true)
        {               
          std::map <uint16_t, uint8_t>::iterator itProcId;
          itProcId = m_ulHarqCurrentProcessId.find (uldci.m_rnti);
          if (itProcId == m_ulHarqCurrentProcessId.end ())
            {
              NS_FATAL_ERROR ("No info find in HARQ buffer for UE " << uldci.m_rnti);
            }
          harqId = (*itProcId).second;
          std::map <uint16_t, UlHarqProcessesDciBuffer_t>::iterator itDci = m_ulHarqProcessesDciBuffer.find (uldci.m_rnti);
          if (itDci == m_ulHarqProcessesDciBuffer.end ())
            {
              NS_FATAL_ERROR ("Unable to find RNTI entry in UL DCI HARQ buffer for RNTI " << uldci.m_rnti);
            }
          (*itDci).second.at (harqId) = uldci;
          // Update HARQ process status (RV 0)
          std::map <uint16_t, UlHarqProcessesStatus_t>::iterator itStat = m_ulHarqProcessesStatus.find (uldci.m_rnti);
          if (itStat == m_ulHarqProcessesStatus.end ())
            {
              NS_LOG_ERROR ("No info find in HARQ buffer for UE (might change eNB) " << uldci.m_rnti);
            }
          (*itStat).second.at (harqId) = 0;
        }

Which implies to update the process when is actually used.

Best regards,
marco.

On Thu, Jun 19, 2014 at 10:10 PM, Vikram Chandrasekhar <cvi...@gmail.com> wrote:

Hi Marco,

Thanks for your quick response: much appreciated. 

I agree that the value "0" for a particular HARQ process within m_ulProcessHarqProcessStatus means that a new HARQ block with RV = 0 has been sent. At the same time, I notice that any value x > 0 represents the number of retransmission attempts made for that HARQ process. 

Following your explanation, I realized that I had misunderstood how the HARQ process buffer statistics were being correctly updated on each TTI. Thanks again and I apologize for my misunderstanding :)

However, I still am a bit confused as to how the entries and indexing of the array inside m_harqBufferStatus [for a given RNTI] is to be interpreted.

Let me explain below: Per lines 1491 - 1494 (copied and pasted below): for a given RNTI, as part of the retransmission handling code, whenever (*itStat).second.at(harqId) equals 3, the code always skips and proceeds to the next rnti (user). Thus the code never reaches line 1524 [wherein the code resets the timer value on that harqId to equal 0]. 

To summarize, whenever a certain UE has 3 retransmissions on a certain HARQ process ID [e.g. that user has poor channel conditions resulting in retransmissions happening very often], then that user's (*itStat).second.at(harqId) value always stays fixed at value 3. My question is whether this is the desired behavior? I am not sure it is. That is why I suggest that between lines 1492 and 1493, we set (*itStat).second.at(harqId) = 0.

I shall file this issue as a bug as well.

Hope this clarifies.

Thank you,

Vikram.

if ((*itStat).second.at (harqId) >= 3)

1491  {

1492  NS_LOG_INFO ("Max number of retransmissions reached (UL)-> drop process");

1493  continue;

1494  }

1522  // Update HARQ buffers with new HarqId

1523  (*itStat).second.at ((*itProcId).second) = (*itStat).second.at (harqId) + 1;

1524  (*itStat).second.at (harqId) = 0;

1525  (*itHarq).second.at ((*itProcId).second) = dci;

1526  ret.m_dciList.push_back (dci);

--
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/Bz9Ox1uVpC8/unsubscribe.
To unsubscribe from this group and all its topics, 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 the response. I shall file this issue within Bugzilla. 

Quick Question: In your suggestion I noticed you do not "continue" when the value of (*itStat).second.at(harqId) >= 3? I guess this has to do with you using a newer version in NS3?

thanks

Vikram

[Vikram Chandrasekhar]

Hi Marco and other LENA experts:

Filed this issue in bugzilla:

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1935.

- Vikram