LENA: TCP-RLC Acknowledged Mode (AM)

615 views
Skip to first unread message

Rocio

unread,
Jul 18, 2012, 4:06:01 AM7/18/12
to ns-3-...@googlegroups.com
Hi all!!

I have
a problem when I use TCP and RLC Acknowledged Mode (AM). And that is: when in a TCP connection change the RLC-UM to RLC-AM, the throughput 
decreases much. Why should this be?

I attach the code and the DlRlcStats.txt.

Thank you very much in advance!!

Regards,

Rocío.
my-lena-simple-epc-tcp.cc
DlRlcStats.txt

Rocio

unread,
Jul 18, 2012, 7:44:57 AM7/18/12
to ns-3-...@googlegroups.com
Hi again!

I would like to correct my previous email. In my TCP connection with RLC-AM this connection does not get to set. Every time try to set the connection but it doesn,t get. ¿What is happening?

Sorry, the previous DlRlcStats.txt is not correct. Now, I attach the correct one. Sorry!!

Thanks again!

Rocío.


DlRlcStats.txt

Kazu

unread,
Jul 23, 2012, 10:39:57 AM7/23/12
to ns-3-...@googlegroups.com
Hi rocio.

At first, I thought that the behavior was due to the issue below:

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 ?

Best regards, 
KAZU.

-----------------------------------------------------------------------
Using the latest lena source code from http://lena.cttc.es/hg/lena/ ,
A segmentation fault occurred at "LteRlcAm::DoReceivePdu".
So, I commented out the source code below in attached patch.

@@ -656,17 +680,17 @@ LteRlcAm::DoReceivePdu (Ptr<Packet> p)
-                  m_retxBuffer.front ().m_pdu->PeekPacketTag (retxQueueHolTimeTag);
+//                  m_retxBuffer.front ().m_pdu->PeekPacketTag (retxQueueHolTimeTag);

lte-rlc-am.cc.patch

Rocio

unread,
Jul 29, 2012, 11:51:57 AM7/29/12
to ns-3-...@googlegroups.com
Thank you very much Kazu!

Sorry for my ignorance, how I apply a path?

Thanks in advance!!

Regards,

Rocío.

Massoudi Radhouene

unread,
Jul 29, 2012, 8:52:53 PM7/29/12
to ns-3-...@googlegroups.com
hi how patch lte-rlc

2012/7/29 Rocio <rocio...@hotmail.com>

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/3bBClSW-2rMJ.

To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

Kazu

unread,
Jul 30, 2012, 5:35:14 AM7/30/12
to ns-3-...@googlegroups.com
Hi Rocío.

Try patch command as follow:
$patch < lte-rlc-am.cc.patch

or, edit lte-rlc-am.cc manually.

Best regards, 
KAZU.


2012年7月30日月曜日 0時51分57秒 UTC+9 Rocio:

Massoudi Radhouene

unread,
Jul 30, 2012, 7:07:05 AM7/30/12
to ns-3-...@googlegroups.com

add this code in former code?
2012/7/30 Kazu <kazuyuki...@gmail.com>
--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/qKXfNo3VbQQJ.

Massoudi Radhouene

unread,
Jul 30, 2012, 1:10:16 PM7/30/12
to ns-3-...@googlegroups.com
please give me class lte-rlc-am.cc with patch

2012/7/30 Massoudi Radhouene <radhou...@gmail.com>

Kazu

unread,
Jul 30, 2012, 9:56:21 PM7/30/12
to ns-3-...@googlegroups.com
Sorry for the late relpy.
Please try below
code .

void
LteRlcAm::DoNotifyTxOpportunity (uint32_t bytes, uint8_t layer)
{
  NS_LOG_FUNCTION (this << m_rnti << (uint32_t) m_lcid << bytes);
 
  if (bytes <= 2)
    {
      // Stingy MAC: Header fix part is 2 bytes, we need more bytes for the data
      NS_LOG_LOGIC ("TX opportunity too small = " << bytes);
      return;
    }

  if ( m_statusPduRequested && ! m_statusProhibitTimer.IsRunning () )
    {
      NS_LOG_LOGIC ("Sending STATUS PDU");

      Ptr<Packet> packet = Create<Packet> ();
      LteRlcAmHeader rlcAmHeader;
      rlcAmHeader.SetControlPdu (LteRlcAmHeader::STATUS_PDU);
      rlcAmHeader.SetAckSn (m_vrR);

      NS_LOG_LOGIC ("RLC header: " << rlcAmHeader);
      packet->AddHeader (rlcAmHeader);

      // Send RLC PDU to MAC layer
      LteMacSapProvider::TransmitPduParameters params;
      params.pdu = packet;
      params.rnti = m_rnti;
      params.lcid = m_lcid;

      m_macSapProvider->TransmitPdu (params);

// -----!!!!!! Here !!!!!!!------>
      // for Bugzilla Bug 1438
      m_statusPduRequested = false;
      m_statusPduBufferSize = 0;

      // Send Buffer Status Report again
      if( m_txonBufferSize > 0 || m_retxBufferSize > 0 )
       {
         LteMacSapProvider::ReportBufferStatusParameters r;
         r.rnti = m_rnti;
         r.lcid = m_lcid;
         if( m_txonBufferSize < 1000 )
          {
           r.txQueueSize = 1000;
         }else{
           r.txQueueSize = m_txonBufferSize;
          }
         r.txQueueHolDelay = 0;
         r.retxQueueSize = m_retxBufferSize;
         r.retxQueueHolDelay = 0;
         r.statusPduSize = m_statusPduBufferSize;
         m_macSapProvider->ReportBufferStatus (r);
       }
// <-----------------

      return;
    }
  else if ( m_retxBufferSize > 0 )
    {
      NS_LOG_LOGIC ("Sending data from Retransmission Buffer");
     
      Ptr<Packet> packet = m_retxBuffer.at (m_vtA.GetValue ()).m_pdu->Copy ();
.....


Best regards,
KAZU



2012年7月31日火曜日 2時10分16秒 UTC+9 ra ma:
please give me class lte-rlc-am.cc with patch

2012/7/30 Massoudi Radhouene <radhou...@gmail.com>

add this code in former code?

2012/7/30 Kazu <kazuyuki...@gmail.com>
Hi Rocío.

Try patch command as follow:
$patch < lte-rlc-am.cc.patch

or, edit lte-rlc-am.cc manually.

Best regards, 
KAZU.


2012年7月30日月曜日 0時51分57秒 UTC+9 Rocio:
Thank you very much Kazu!

Sorry for my ignorance, how I apply a path?

Thanks in advance!!

Regards,

Rocío.

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/qKXfNo3VbQQJ.

To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+unsubscribe@googlegroups.com.

Massoudi Radhouene

unread,
Jul 30, 2012, 10:40:05 PM7/30/12
to ns-3-...@googlegroups.com
don't work 

2012/7/31 Kazu <kazuyuki...@gmail.com>
To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/L-lWUH055JsJ.

To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.

Rocio

unread,
Aug 2, 2012, 11:07:48 AM8/2/12
to ns-3-...@googlegroups.com
Hi again!!

This path don't work. I get the same result as before. Why??

Thanks!!

Best regards,

Rocío.

Kazu

unread,
Aug 2, 2012, 11:40:29 AM8/2/12
to ns-3-...@googlegroups.com
Hi Rocío.

Thank you very much for trying it.
Could you give me your file bellow?
I'll try it again. 

lte-rlc-am.cc  (after applying the patch)
my-lena-simple-epc-tcp.cc (your main scenario file)


Also, adding following code into my-lena-simple-epc-tcp.cc, you can get some logs.
LogComponentEnable ("LteRlcAm", LOG_LEVEL_ALL);

This helps understanding the problem.


Best regards,  
Kazu


2012年8月3日金曜日 0時07分48秒 UTC+9 Rocio:

Rocio

unread,
Aug 2, 2012, 1:17:18 PM8/2/12
to ns-3-...@googlegroups.com
Hi Kazu.

Thank you very very much for your help!
I attach the files.
I hope you can help me.

Best regards,

Rocío.
my-lena-simple-epc-tcp.cc
lte-rlc-am.cc

Kazu

unread,
Aug 2, 2012, 9:51:38 PM8/2/12
to ns-3-...@googlegroups.com
Hi, Rocío.

Please change
distance value to  the same value as your original file first attached in this report.

double distance = 30.0;
->
double distance = 500.0;

Then, try it again.

Thanks,
Kazu.

Rocio

unread,
Aug 3, 2012, 6:33:13 AM8/3/12
to ns-3-...@googlegroups.com
Hi Kazu!

I try it with distance=500m but the results are not correct. I attach the DlRlcStats.txt.

Thank you very much for your time and your help.

Best regards,

Rocío.
DlRlcStats.txt

Kazu

unread,
Aug 3, 2012, 7:16:36 AM8/3/12
to ns-3-...@googlegroups.com
Hi, Rocío.

Before applying the patch, there were only 64 byte data from start time 2 to end time 2,25 in  DlRlcStats.txt 
But, after applying the patch, there are many data from start time 2 to end time 5.
It seems getting better.

Hasn't TCP connection got to set yet ?
It looks like another problem.

What is your expected result ?


2012年8月3日金曜日 19時33分13秒 UTC+9 Rocio:

Rocio

unread,
Aug 3, 2012, 11:27:24 AM8/3/12
to ns-3-...@googlegroups.com
Hi Kazu.

What I don't understand is why the number of PDUs received is greater than the number of PDUs transmitted. This is abnormal behavior, right?

Thank you very much!!!

Rocío.

Kazu

unread,
Aug 3, 2012, 5:26:51 PM8/3/12
to ns-3-...@googlegroups.com
Hi, Rocío. 

How about DlPdcpStats.txt ?
If the number of PDUs received is equal to the number of PDUs transmitted in DlPdcpStats.txt,
I think the behavior comes from re-transmission of AM RLC entity.

If the number of PDUs received is also greater than the number of PDUs transmitted in DlPdcpStats.txt,
It is strange behavior.

Thank you very much.

Best regards, 
KAZU.


2012年8月4日土曜日 0時27分24秒 UTC+9 Rocio:

Rocio

unread,
Aug 6, 2012, 12:33:45 PM8/6/12
to ns-3-...@googlegroups.com
Ok Kazu!!
Thank you very much for your help and your time!!!

Best regards,

Rocío.

Rocio

unread,
Sep 25, 2012, 5:55:38 AM9/25/12
to ns-3-...@googlegroups.com
Hi Kazu again!

I still have problems in the TCP connection with RLC-AM. In my project I'm studying the performance of the RLC-AM protocol. I'm changing the distance of Ue and Enb and then I study the results. The problem is that with a distance value of 50m - 150m everything is correct, i.e. the connection is set, but if the distance value is out of that range the connection is not set. Can you help me?? I attach my main scenario file and the DlRlcStats.txt.

Thank you very much!

Best regards,

Rocío.
my-lena-simple-epc-tcp.cc
DlRlcStats.txt

Nicola Baldo

unread,
Sep 25, 2012, 9:49:28 AM9/25/12
to ns-3-...@googlegroups.com
Can you attach also DlMacStats.txt?

Rocio

unread,
Sep 26, 2012, 4:40:49 AM9/26/12
to ns-3-...@googlegroups.com
Of course!

Thank you Nicola.

Regards,

Rocío.
DlMacStats.txt

Kazu

unread,
Sep 27, 2012, 3:03:08 AM9/27/12
to ns-3-...@googlegroups.com
Hi Rocío, Nicola.

I got the same results.
When distance is 150, TCP connection is set.
But, if distance is 230, the connection is not set.

Logs show that UL resource is not assigned though UE sent the same Buffer Status Report.


Distance = 150 --> OK
-----------------------------------------------------
...
LteRlcAm:DoTransmitPdcpPdu(0x2004aea0, 1, 1, 42)
Txon Buffer: New packet added
NumOfBuffers = 1
txonBufferSize = 42
Send ReportBufferStatus: 42, 0, 0, 0, 4                 !!!!!!
LteRlcAm:DoNotifyTxOpportunity(0x2004aea0, 1, 1, 85)    !!!!!! <--- OK
Sending STATUS PDU
RLC header: Len=2 D/C=0 ACK_SN=1 NACK_SN=1023
...
-----------------------------------------------------


Distance = 230 --> NG
-----------------------------------------------------
...
LteRlcAm:DoTransmitPdcpPdu(0x2004aea0, 1, 1, 42)
Txon Buffer: New packet added
NumOfBuffers = 1
txonBufferSize = 42
Send ReportBufferStatus: 42, 0, 0, 0, 4                !!!!!!!
...
...
-----------------------------------------------------


Also, I got the same results with RLC "UM" Mode.
So, I think that this is eNodeB MAC Scheduler isuue.
Unfortunately, I am not familiar with MAC Scheduler.
I am now studying the behavior of MAC Scheduler and PHY layer.

Best regards,
Kazu.


2012年9月26日水曜日 17時40分49秒 UTC+9 Rocio:

Nicola Baldo

unread,
Sep 27, 2012, 4:04:52 AM9/27/12
to ns-3-...@googlegroups.com
Looking at DlMacStats, I think the UE is just out of range.

Nicola

Rocio

unread,
Sep 27, 2012, 4:21:20 AM9/27/12
to ns-3-...@googlegroups.com
Hi Nicola and Kazu.

Then, you think that distance=150m is the cell edge, right? But I am not sure because with distance=150m the CQI=13 and therefore we have good channel conditions and the connection should be set, right? Any ideas?

Thanks!!

Rocío.

Nicola Baldo

unread,
Sep 28, 2012, 10:55:36 AM9/28/12
to ns-3-...@googlegroups.com


On Thursday, September 27, 2012 10:21:20 AM UTC+2, Rocio wrote:
Then, you think that distance=150m is the cell edge, right? But I am not sure because with distance=150m the CQI=13 and therefore we have good channel conditions and the connection should be set, right?


I didn't say that the edge is exactly at 150m. You should try more values between 150 and 230 to get a better estimate of where the cell edge is.

Nicola

Rocio

unread,
Oct 10, 2012, 4:00:02 AM10/10/12
to ns-3-...@googlegroups.com
Ok Nicola.
Thank you very much Nicola and Kazu!

Best regards,

Rocío.
Reply all
Reply to author
Forward
0 new messages