Bugzilla – Bug 1935
Bug in Uplink Scheduler regarding HARQ retransmission handling
Last modified: 2014-09-02 11:24:07 UTC
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.
Bug fixed in ns-3-dev in all the uplink HARQ scheduler implementation according to Marco Miozzo's alternative version, see changeset: 10821:9d3ffeb97587.