Bug 1935 - Bug in Uplink Scheduler regarding HARQ retransmission handling
Bug in Uplink Scheduler regarding HARQ retransmission handling
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: lte
ns-3.20
PC Mac OS
: P5 normal
Assigned To: Nicola Baldo
: bug
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-06-20 10:13 EDT by Vikram Chandrasekhar
Modified: 2014-09-02 11:24 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vikram Chandrasekhar 2014-06-20 10:13:14 EDT
In the method PfFfMacScheduler::DoSchedUlTriggerReq, in lines 1491 - 1494 (copied and pasted below), I found the following bug. This bug occurs in my version of NS3 (ver 3.18), but is also reproducible in the latest version (3.20).

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. 


 1490  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);


Suggested Fix: Between lines 1492 and 1493, we set (*itStat).second.at(harqId) = 0.
          

Alternative fix proposed by Marco Miazzo:

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.
Comment 1 Marco Miozzo 2014-06-26 07:47:43 EDT
Bug fixed in ns-3-dev in all the uplink HARQ scheduler implementation according to Marco Miozzo's alternative version, see changeset:   10821:9d3ffeb97587.