Bugzilla – Bug 1757
RLC AM not using NACK_SN
Last modified: 2015-04-16 12:16:07 UTC
Posted by Brett on ns-3-users: https://groups.google.com/d/msg/ns-3-users/6BtxeEHu9t8/-y8TrhjVkBcJ My name is Brett and I have a question about how negative acknowledgments work in the RLC layer Acknowledge Mode in the LENA LTE module. I am using ns-3.17 with LENA version M5. I ran a simple simulation using Acknowledge Mode and with errors turned off (using default ns3::LteSpectrumPhy::DataErrorModelEnabled "false" and default ns3::LteSpectrumPhy::CtrlErrorModelEnabled "false"). I reviewed the log file created from lte-rlc-am.cc and I found that my status PDUs had the NACK_SN field set to 1023. From what I could tell no RLC PDUs had been lost. Also the status PDU was sending a NACK of 1023 even when I had only transmitted a few PDUs. I was unsure why this would be so I looked at the code. After examining the file lte-rlc-am-header.cc I see that it looks like the variable m_nackSn is set by default to 0xffff but does not appear to be modified afterwards. I checked the LENA documentation on RLC layer Acknowledge Mode and in the Unsupported Features section I did not see anything that mentioned NACKs were not currently supported. Is there something that I am missing on how NACKs work in RLC AM or is there something that I do not know about how to properly enable RLC AM? In my example simulation I just used the default setting ns3::LteEnbRrc::EpsBearerToRlcMapping "RlcAmAlways" to enable RLC AM.
A fix this bug is discussed here: https://www.nsnam.org/bugzilla/0 development repository for the fix: http://code.nsnam.org/nbaldo/ns-3-lena-rlc-am-nack/
Finally managed to finalize and push the dev branch with the fix, the latest changeset is 77244b8e7046
for the record, the thread for the discussion of the fix was this one: https://groups.google.com/forum/#!searchin/ns-3-users/RLC$20AM$20/ns-3-users/CEfmMX3IRBw/1WQqnxtg7YYJ (the previous URL was incorrect)