Bugzilla – Bug 2886
Uplink HARQ transmits from wrong HARQ buffer
Last modified: 2018-03-22 11:58:46 UTC
When uplink HARQ is triggered, sends the wrong data, i.e. the data from the previous TTI. Tested with RR and PF schedulers. As a result, eventually the RLC AM, recognizes this and at approximately t_reorder, a RLC retransmission is triggered. Looking at augmented trace from SpectrumPhy (RxEndOk and RxEndError): // Time, RLC Delay, RLC SN, Frame, SubFrame 0.152 0.00471 5 16 3 Error 0.156 0.00471 6 16 7 0.157 0.00471 7 16 8 0.158 0.00471 8 16 9 0.159 0.00571 8 16 10 Retransmission 0.163 0.00471 9 17 4 Let me know if this is sufficient details... Regarding a fix, I need help, as many things about the implementation are unfamiliar to me.
Hi Jonathan, Please, could you provide a simple example to reproduce the issue?
Created attachment 3071 [details] Test case and debugging support (w/o required fading file) Pls. find fading file in your email.
Hi Manual, Seems there is nothing simple in NS-3. Thanks very much for looking at this. I've attached a test case which generates uplink UDP packets at regular intervals. To generate the errors a custom fading trace was generated with correlated shadow & fast fading. There's a bunch of tracing support in lte-common.h, lte-enb-mac.cc, spectrum-phy.cc Anyway to run: ../waf --run "harq --dlTestApp=false --ulTestApp=true --fadingModel=fading_trace_shadow_30kmph.fad --ns3::LteRlcAm::ReorderingTimer=100ms --interPacketInterval=30ms" phyErrorDelay and phyOkDelay, should be generated, and the same as in the attachment.
The situation appears to arise, when data is not continuously being set. In such case the HARQ process id, does not get incremented in UE-MAC, it also doesn't get incremented for re-tx. Perhaps mismatch with the scheduler ? Work around is to send short dummy packets continuously. Noticed that Packet tags are now being dropped...
Which version of ns-3 are you using? Recently, we solved some issues related to HARQ, could you use latest ns-3-dev?
Was on ns-3.26. Retesting on the development master, and seems to work OK!
(In reply to Jonathan Ling from comment #6) > Was on ns-3.26. Retesting on the development master, and seems to work OK! Please check and close this issue if it is resolved in the ns-3.28 code (release candidate available for testing).
(In reply to Tom Henderson from comment #7) > (In reply to Jonathan Ling from comment #6) > > Was on ns-3.26. Retesting on the development master, and seems to work OK! > > Please check and close this issue if it is resolved in the ns-3.28 code > (release candidate available for testing). This bug is same as #2152, and the patch pushed in on 11/16 seems correct. As it is in ns-3.28, issue is closed.