Bug 1757

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.