Bugzilla – Full Text Bug Listing |
Summary: | lena-simple-epc with am mode | ||
---|---|---|---|
Product: | ns-3 | Reporter: | Kazuyuki.Morioka |
Component: | lte | Assignee: | Manuel Requena <manuel.requena> |
Status: | ASSIGNED --- | ||
Severity: | normal | CC: | manuel.requena, moijes12, nicola, ns-bugs |
Priority: | P5 | ||
Version: | pre-release | ||
Hardware: | All | ||
OS: | All | ||
Attachments: | trace log |
Description
Kazuyuki.Morioka
2012-05-26 10:18:10 EDT
Hi Kazuyuki, thank you very much for the detailed bug report. Manuel, do you think the proposed patch is ok to apply? The bug is still present even after the latest fixes that were pushed. I originally thought that the behavior was due to the use of the RR scheduler, but I just tried it, and I get exactly the same symptoms when the PF scheduler is used. So I would say that the problem is not in the scheduler. Manuel, I am assigning the bug to you in order to check the proposed patch. Created attachment 1411 [details]
trace log
Hi Nicola, thank you for your reply.
I think this issue is a simple bug in rlc layer, not a mac scheduler.
I enabled log components as follows and got an attached log.
"LogComponentEnable ("LteRlcAm", LOG_LEVEL_ALL);"
The log says that the same rlc control pdu(RLC ACK) was sent again and again.
According to 3GPP TS 36.322, rlc entity gives priority to control pdu rather than data pdu.
This is implemented in lena source code using variable named "m_statusPduRequested".
I searched "m_statusPduRequested" in the source code.
[morioka@vostro lte]$ grep "m_statusPduRequested" */*.* -rn
model/lte-rlc-am.cc:46: m_statusPduRequested = false;
model/lte-rlc-am.cc:144: if ( m_statusPduRequested && ! m_statusProhibitTimer.IsRunning () )
model/lte-rlc-am.cc:176: if ( m_statusPduRequested && ! m_statusProhibitTimer.IsRunning () )
model/lte-rlc-am.cc:643: m_statusPduRequested = true;
model/lte-rlc-am.cc:676: if ( m_statusPduRequested && ! m_statusProhibitTimer.IsRunning () )
model/lte-rlc-am.h:89: bool m_statusPduRequested;
The variable is set to "true" at model/lte-rlc-am.cc:643 when status pdu was triggered.
But the variable is not cleared anywhere except constructor(model/lte-rlc-am.cc:46).
This is why the same control pdu was sent again and again.
I think the variable should be cleared after the control pdu was transmitted.
Please check this issue from rlc protocol point of view.
Thanks, Kazu
I am re-posting here an email by Kazu on ns-3-users which is relevant to this bug (original at https://groups.google.com/d/msg/ns-3-users/7RQOM59XmQw/TFQmLJJoDMIJ ) > At first, I thought that the behavior was due to the issue below: > https://www.nsnam.org/bugzilla/show_bug.cgi?id=1438 > > But, the problem is present even after applying the patch. Analyzing > the log file, the behavior looks as follows: > -------------------------------------------------------------------- > [eNB] LteRlcAm:DoTransmitPdcpPdu(0x2196d30, 1, 1, 42) <--- Maybe, > TCP:SYN. Send ReportBufferStatus: 42, 0, 0, 0, 0 <--- Request > 42 bytes assignment. LteRlcAm:DoNotifyTxOpportunity(0x2196d30, 1, 1, > 2196) <--- Assigned 2196 bytes. Sending data from Transmission > Buffer ... > > [UE] LteRlcAm:DoTransmitPdcpPdu(0x219d150, 1, 1, 42) <--- Maybe, > TCP:SYN/ACK. Send ReportBufferStatus: 42, 0, 0, 0, 4 <--- Data > PDU:42 bytes + RLC ACK:4 bytes. > LteRlcAm:DoNotifyTxOpportunity(0x219d150, 1, 1, 621) <--- Assigned > 621 bytes. Sending STATUS PDU <--- (*) > > LteRlc:~LteRlc(0x2196d30) LteRlc:~LteRlc(0x219d150) <--- End. > -------------------------------------------------------------------- > > (*) As above log shows, UE could not send 42 bytes of Data > PDU(TCP:SYN/ACK). This seems due to the limitations of current lena > implementation: > > 1.6.4 AM data transfer in LTE Simulator Documentation. "The AM RLC > entity generates and sends exactly one RLC PDU for each transmission > opportunity even if it is smaller than the size reported by the > transmission opportunity. So for instance, if a STATUS PDU is to be > sent, then only this PDU will be sent in that transmission > opportunity." > > Furthermore, because "periodicBSR-Timer" and "retxBSR-Timer" in 3GPP > TS 36.321 are not implemented so far, UE can not send > BufferStatusReports any more. So, MAC shceduler can't assign > resources and the Data PDU(TCP:SYN/ACK) remains in the RLC buffer. > > One solution of this matter is that UE sends BufferStatusReport again > after sending STATUS PDU. By applying attached patch, it seems work > well. > > I think that essential solution of this matter is to implement > "periodicBSR-Timer" and "retxBSR-Timer" or multiple RLC PDUs in one > MAC PDU. Is there anyone who plans to implement the functions in the > near future ? Hi The /src/lte/model/ff-mac-csched-sap.h and .cc seems to have been written against the small cell group's LTE MAC Scheduler Interface specification. The periodicBSR-Timer and the retxBSR-Timer are contained in the 3GPP 36.331 and 36.321. Should these timer changes still be made to ff-mac-csched.sap ? Please pardon me for my ignorance. I am new and only trying work on a few issues. Hi All Any updates on this ? I can work on it with some guidance. |