Bug 2886

Summary: Uplink HARQ transmits from wrong HARQ buffer
Product: ns-3 Reporter: Jonathan Ling <jonathan.ling>
Component: lteAssignee: Biljana Bojović <bbojovic>
Status: RESOLVED FIXED    
Severity: normal CC: manuel.requena, ns-bugs, tomh
Priority: P3    
Version: ns-3.26   
Hardware: All   
OS: All   
Attachments: Test case and debugging support (w/o required fading file)

Description Jonathan Ling 2018-03-02 10:15:42 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.
Comment 1 Manuel Requena 2018-03-02 10:45:53 UTC 
Hi Jonathan, 
Please, could you provide a simple example to reproduce the issue?
Comment 2 Jonathan Ling 2018-03-02 16:35:42 UTC 
Created attachment 3071 [details]
Test case and debugging support (w/o required fading file)

Pls. find fading file in your email.
Comment 3 Jonathan Ling 2018-03-02 16:42:49 UTC 
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.
Comment 4 Jonathan Ling 2018-03-07 10:03:08 UTC 
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...
Comment 5 Manuel Requena 2018-03-07 11:06:53 UTC 
Which version of ns-3 are you using?
Recently, we solved some issues related to HARQ, could you use latest ns-3-dev?
Comment 6 Jonathan Ling 2018-03-09 17:11:24 UTC 
Was on ns-3.26.  Retesting on the development master, and seems to work OK!
Comment 7 Tom Henderson 2018-03-10 12:36:17 UTC 
(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).
Comment 8 Jonathan Ling 2018-03-22 11:58:46 UTC 
(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.