Bugzilla – Bug 1438
lena-simple-epc with am mode
Last modified: 2012-12-18 05:17:21 EST
I found some issue with rlc protocol in the ns3 lena project(http://lena.cttc.es/hg/lena/). I executed lena-simple-epc with am mode added in lena-simple-epc.cc as follows: lteHelper->SetAttribute ("EpsBearerToRlcMapping", EnumValue (LteHelper::RLC_AM_ALWAYS)); The result shows that no RxPDU is recieved at the PDCP layer both UL and DL direction. DlPdcpStats.txt % start end CellId IMSI RNTI LCID nTxPDUs TxBytes nRxPDUs RxBytes delay stdDev min max PduSize stdDev min max 0 0.25 1 1 1 1 3 3162 0 0 0 0 0 0 0 0 0 0.25 2 2 1 1 3 3162 0 0 0 0 0 0 0 0 0.25 0.5 1 1 1 1 2 2108 0 0 0 0 0 0 0 0 0.25 0.5 2 2 1 1 2 2108 0 0 0 0 0 0 0 0 0.5 0.75 1 1 1 1 3 3162 0 0 0 0 0 0 0 0 0.5 0.75 2 2 1 1 3 3162 0 0 0 0 0 0 0 0 0.75 1 1 1 1 1 2 2108 0 0 0 0 0 0 0 0 0.75 1 2 2 1 1 2 2108 0 0 0 0 0 0 0 0 ... UlPdcpStats.txt % start end CellId IMSI RNTI LCID nTxPDUs TxBytes nRxPDUs RxBytes delay stdDev min max PduSize stdDev min max 0 0.25 0 1 1 1 6 6324 0 0 0 0 0 0 0 0 0 0.25 0 2 1 1 6 6324 0 0 0 0 0 0 0 0 0.25 0.5 0 1 1 1 4 4216 0 0 0 0 0 0 0 0 0.25 0.5 0 2 1 1 4 4216 0 0 0 0 0 0 0 0 0.5 0.75 0 1 1 1 6 6324 0 0 0 0 0 0 0 0 0.5 0.75 0 2 1 1 6 6324 0 0 0 0 0 0 0 0 0.75 1 0 1 1 1 4 4216 0 0 0 0 0 0 0 0 0.75 1 0 2 1 1 4 4216 0 0 0 0 0 0 0 0 ... The trace log shows that rlc protocol was stalled by sending control pdu (RLC_ACK) each other at every transmit opportunity. Actually, the flag "m_statusPduRequested" is not cleard anywhere. I think the flag should be cleard after the control pdu was transmitted like as follows: ------------------------------------------------------------------------- diff -r 406ee7fcd79d src/lte/model/lte-rlc-am.cc --- a/src/lte/model/lte-rlc-am.cc Fri May 18 15:44:06 2012 +0200 +++ b/src/lte/model/lte-rlc-am.cc Sat May 26 22:35:55 2012 +0900 @@ -186,6 +186,8 @@ params.lcid = m_lcid; m_macSapProvider->TransmitPdu (params); + m_statusPduRequested = false; + m_statusPduBufferSize = 0; return; } else if ( m_retxBufferSize > 0 ) -------------------------------------------------------------------------- After applying avobe patch, nRxPDUs become equal to nTxPDUs. It seems to work well. DlPdcpStats.txt % start end CellId IMSI RNTI LCID nTxPDUs TxBytes nRxPDUs RxBytes delay stdDev min max PduSize stdDev min max 0 0.25 1 1 1 1 6 6324 6 6324 0.0441662 0.0523085 0.00399904 0.118 1054 0 1054 1054 0 0.25 2 2 1 1 6 6324 6 6324 0.0441661 0.0523085 0.00399896 0.118 1054 0 1054 1054 0.25 0.5 1 1 1 1 4 4216 4 4216 0.0104995 0.00750611 0.00399904 0.017 1054 0 1054 1054 0.25 0.5 2 2 1 1 4 4216 4 4216 0.0104995 0.00750616 0.00399896 0.017 1054 0 1054 1054 0.5 0.75 1 1 1 1 6 6324 6 6324 0.0104995 0.00712092 0.00399904 0.017 1054 0 1054 1054 0.5 0.75 2 2 1 1 6 6324 6 6324 0.0104995 0.00712096 0.00399896 0.017 1054 0 1054 1054 0.75 1 1 1 1 1 4 4216 4 4216 0.0104995 0.00750611 0.00399904 0.017 1054 0 1054 1054 0.75 1 2 2 1 1 4 4216 4 4216 0.0104995 0.00750616 0.00399896 0.017 1054 0 1054 1054 ... UlPdcpStats.txt % start end CellId IMSI RNTI LCID nTxPDUs TxBytes nRxPDUs RxBytes delay stdDev min max PduSize stdDev min max 0 0.25 1 1 1 1 6 6324 6 6324 0.0466667 0.0513835 0.013 0.113 1054 0 1054 1054 0 0.25 2 2 1 1 6 6324 6 6324 0.0466667 0.0513835 0.013 0.113 1054 0 1054 1054 0.25 0.5 1 1 1 1 4 4216 4 4216 0.013 0 0.013 0.013 1054 1054 1054 0.25 0.5 2 2 1 1 4 4216 4 4216 0.013 0 0.013 0.013 1054 1054 1054 0.5 0.75 1 1 1 1 6 6324 6 6324 0.013 0 0.013 0.013 1054 1054 1054 0.5 0.75 2 2 1 1 6 6324 6 6324 0.013 0 0.013 0.013 1054 1054 1054 0.75 1 1 1 1 1 4 4216 4 4216 0.013 0 0.013 0.013 1054 1054 1054 0.75 1 2 2 1 1 4 4216 4 4216 0.013 0 0.013 0.013 1054 1054 1054 ... Thanks, Kazu
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.