You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
there are a number of problems with the operation of RLC AM. I will try to summarize them:
The throughput is extremely low. This is what happens: when the LteRlcAm receives a new SDU it uses AmTxQueue::enqueu() which fragments the PDU, using a default fragment size of 30B. This module informs the MAC but only passes the first fragmented PDU. Therefore, the MAC creates a BSR for the size of that PDU, that is 30B, and it receives a grant for that size, and that is. The UE will keep receiving grants of about that size every ms (or less, that depends on the numerology) and it will be sending the fragments every tick. A single TCP segment may take 20 fragments. The throughput stays at around 240Kbps, even if there is a single UE at the BS and no background UE.
A potential solution is to inform the MAC about the total size of the SDU and it will create a BSR for that size and usually be granted the bytes. But then the problem is in AmTxQueue::sendPdus. If the MAC asks for a SDU, whose size is equal to the total size, this method only sends a PDU with the fragment size. So let us say that the MAC has been granted 600B, this method only sends 30B. And there is no way the MAC asks for more PDUs until the grant is filled or this method sends all the fragments. What is worse is that the scheduler, removes the SDU from the MAC virtual buffers. It acts as if the full SDU has been transmitted but only a fragment has been sent. So we are as in the case above and in the end, we again have a very low throughput.
If you just increase the fragment size, let us say to 600B, more problems appear. In AmTxQueue::sendPdus, very often the MACs asks for SDU with less size, in that case, it tries to informs the MAC with an "empty packet" of 1 bit. But the length of the packet is not actually empty, only the header is. In fact, when the MAC bufferize the packet, it considers it a full SDU and puts it in the buffer. The result is that the SDUs are actually sent twice. But, at some point a MRW packet is generated, which will be actually empty. This results in the MAC always asking for a SDU whose size is lower than the actual one and the RLC AM always sending an empty packet. Nothing is ever sent again.
All of this can be tested just using a single BS with one UE with a TCPClientApp and a TCPSink in a server.
So, after the above, my first question is: Is this module finished or is it a work in progress? Should we use RLC AM in our simulations?
Second question: any idea on how to solve it? I think that the AmTxQueue::sendPdus() method should send all the PDUs until completing the size asked by the MAC, which is what the UmTxEntity::rlcPduMake() does.
Kind regards
The text was updated successfully, but these errors were encountered:
RLC AM is an incomplete implementation. In v1.3, the NED comment of the LteRlc module mentions that only Unacknowledged Mode (UM) is implemented. I believe it is not currently actively worked on, and improvements would be welcome.
Hi,
there are a number of problems with the operation of RLC AM. I will try to summarize them:
All of this can be tested just using a single BS with one UE with a TCPClientApp and a TCPSink in a server.
So, after the above, my first question is: Is this module finished or is it a work in progress? Should we use RLC AM in our simulations?
Second question: any idea on how to solve it? I think that the AmTxQueue::sendPdus() method should send all the PDUs until completing the size asked by the MAC, which is what the UmTxEntity::rlcPduMake() does.
Kind regards
The text was updated successfully, but these errors were encountered: