LENA: TCP-RLC Acknowledged Mode (AM)

[Rocio]

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.

[Rocio]

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.

[Kazu]

Hi rocio.

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 ?

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);

[Rocio]

Thank you very much Kazu!

Sorry for my ignorance, how I apply a path?

Thanks in advance!!

Regards,

Rocío.

[Massoudi Radhouene]

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]

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]

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]

please give me class lte-rlc-am.cc with patch

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

[Kazu]

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]

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]

Hi again!!

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

Thanks!!

Best regards,

Rocío.

[Kazu]

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]

Hi Kazu.

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

Best regards,

Rocío.

[Kazu]

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]

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.

[Kazu]

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]

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]

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]

Ok Kazu!!
Thank you very much for your help and your time!!!

Best regards,

Rocío.

[Rocio]

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.

[Nicola Baldo]

Can you attach also DlMacStats.txt?

[Rocio]

Of course!

Thank you Nicola.

Regards,

Rocío.

[Kazu]

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]

Looking at DlMacStats, I think the UE is just out of range.

Nicola

[Rocio]

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]

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]

Ok Nicola.
Thank you very much Nicola and Kazu!

Best regards,

Rocío.