|
Bugzilla – Full Text Bug Listing |
| Summary: | Retransmissions on layer 1 in MIMO are not handled properly | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Zoraze Ali <zorazeali> |
| Component: | lte | Assignee: | Biljana Bojović <bbojovic> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | mmiozzo, ns-bugs, zorazeali |
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
Patch and Logs from MAC and PHY layer
Alternative patch operating at the scheduler test Patch for Pf scheduler |
||
Great work! I propose an alternative solution, tackling the problem at the source (i.e., the scheduler that is not generating the structures in the correct way). Moreover, I did not get the reason behind the changes in PHY layer. Created attachment 2623 [details]
Alternative patch operating at the scheduler
The proposed patch should be extended to all schedulers.
Hi Marco, just a comment regarding lte-enb-phy patch. Zoraze added this patch so that we can easier reproduce that issue. The patch that he proposes is in Layer1ReTx.patch. Do you agree with this patch? Thanks, Biljana If I got the whole picture, the naming is quite ambiguous. The Layer1 patch (for the LteEnbMac) is for solving the error. To this respect, I'm proposing an alternative patch, which should solve the issue at the source (the scheduler that is not generating properly the RLC PDU structure), since in my opinion solving the bug in LteEnbMac code maintains the original error and leaves room for future ones. I did not get the aim of the other patch (DciWithDataLog). Created attachment 2626 [details]
test Patch for Pf scheduler
Hi Marco, Sorry for the ambiguity, following is the description of the patches, Layer1ReTx.patch : This patch is for lte-enb-mac.cc to solve the error. DciWithoutDataLog.patch : This patch is for lte-enb-phy.cc to put an assert for the conditions when there is a downlink DCI without data. I think having downlink DCIs without data is an abnormal condition. Regarding your proposal i think this also could be the way. As per my knowledge of the code this is all happening specifically between the lines 1011 till 1023 in pf-ff-mac-scheduler.cc. Here we are only pushing the elements in rlcPduListPerLc for the layer whose PDU need to be retransmitted. To solve this problem, we should create an object of RlcPduListElement_s with the pdu size of zero for the layer on which we do not need retransmission. For example, RlcPduListElement_s emptyElement; emptyElement.m_logicalChannelIdentity=(*itRlcPdu).second.at (j).at (dci.m_harqProcess).at (k).m_logicalChannelIdentity; emptyElement.m_size=0; rlcPduListPerLc.push_back (emptyElement); I am attaching these changes as a patch here. BR, Zoraze Hi Zoraze, could you please clarify to me the patch that you uploaded? I see that it is like extended Marco's patch, but I didn't get why we need to explicitly initialize logicalChannelIdentity and m_size. I think they would anyway be set to zero. Do we need them later in the code? Thanks, Biljana Hi Biljana, I think LCIDs are used to differentiate among EPS bearers and by default zero LCID is used for CCCH Common Control Channel (CCCH). So, even though if there is no retransmission on one layer LCID should be consistent. Marco can give more input on this. Kind regards, Zoraze (In reply to Zoraze Ali from comment #8) > Hi Biljana, > > I think LCIDs are used to differentiate among EPS bearers and by default > zero LCID is used for CCCH Common Control Channel (CCCH). So, even though if > there is no retransmission on one layer LCID should be consistent. Marco can > give more input on this. > > Kind regards, > Zoraze I agree with Zoraze to have all the structures consistent. Leave the LCID to 0 might generate ambiguity with the SRB0 traffic, which is the signalling bearer that uses LCID 0. Ok, thanks, I will apply it, test it and let you know. Pushed in changeset 52fdcfe0d220. |
Created attachment 2621 [details] Patch and Logs from MAC and PHY layer Hi, I have noticed that layer 1 (MIMO) retransmissions are not properly handled in lte-enb-mac.cc. From the scheduler side, it get scheduled but packet is never retrieved by lte-enb-mac.cc from HARQ buffer. Luckily, this behaviour is reproducible through lena-dual-stripe.cc from ns3-dev for normal LTE by running as follows, ./waf --run="lena-dual-stripe --epc=1 --ns3::LteEnbRrc::DefaultTransmissionMode=2 --simTime=2 --epcUl=0 --RngRun=1" To have a complete picture i suggest you to enable the Mac and phy traces. In DlTxPhyStats.txt at 275 msec it shows the transmission of a retransmitted TB by cellId 12 to Imsi 3 at layer 1, but it is never received by the receiver. The reason behind is the for loop in LteEnbMac::DoSchedDlConfigInd (FfMacSchedSapUser::SchedDlConfigIndParameters ind) function in lte.enb-mac.cc. Currently, the loop runs over the m_rlcPduList which in normal MIMO transmissions contains two RlcPduListElement(s) for each layer. In case of retransmission on one of the layer, it contains only one RlcPduListElement and eventually this loop exists after checking the retransmission only for layer 0. I am attaching the patch to solve this issue please have a look. I am also attaching the traces together with the patch for lte-enb-phy.cc to quit the simulation in case of this behavior for debugging purpose. Kind regards, Zoraze