Bugzilla – Bug 2151
Redundancy version in uplink HARQ not generated properly
Last modified: 2017-11-16 13:22:09 UTC
When HARQ performs multiple uplink retransmissions, the redundancy version is expected to increase (0 to 3) but the traces show that it does not go beyond 1. Using a small scenario with 1 packet sent in the uplink and forcing the receiver to treat the packet as corrupted generated the following results: % time cellId IMSI RNTI layer mcs size rv ndi correct 112 1 1 1 0 28 2292 0 1 0 119 1 1 1 0 28 2292 1 0 0 126 1 1 1 0 28 2292 1 0 0 133 1 1 1 0 28 2292 1 0 0 The issue seems to be that receiver (eNodeB) reads the HARQ history via LteHarqPhy:: GetHarqProcessInfoUl using process ID 0, lte-spectrum-phy.cc:963, but the function LteHarqPhy:: UpdateUlHarqProcessStatus stores the new information at the end (position 7), lte-harq-phy.cc:188. Therefore if there is retransmission, the history will contain at most 1 transmission which can impact the performance of the HARQ soft combining process.
Created attachment 2089 [details] Test scenario To run the test, it is also necessary to modify the lte-spectrum-phy.cc to force packet corruption by modifying the function EndRxData at line 972 to: (*itTb).second.corrupt = true;
Created attachment 2115 [details] Proposed patch The patch ensures that the previous history is inserted before storing status of the new transmission. The revision number is now increasing as expected. % time cellId IMSI RNTI layer mcs size rv ndi correct 112 1 1 1 0 28 2292 0 1 0 119 1 1 1 0 28 2292 1 0 0 126 1 1 1 0 28 2292 2 0 0 133 1 1 1 0 28 2292 3 0 0
The patch is fine with me, the history of the HARQ block was lost when retransmitting.
Created attachment 2951 [details] proposed patch for Ul L1 sycnh Actually Zoraze found another problem on the patch, it was storing the history of all packets for ever and ever. The correct patch is this one in attachment.
Pushed to changeset 13176:3e32da1d3de6.