Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RLC AM does not work correctly #258

Open
eseglo opened this issue Feb 20, 2025 · 2 comments
Open

RLC AM does not work correctly #258

eseglo opened this issue Feb 20, 2025 · 2 comments

Comments

@eseglo
Copy link

eseglo commented Feb 20, 2025

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

@avarga
Copy link
Collaborator

avarga commented Feb 20, 2025

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.

@eseglo
Copy link
Author

eseglo commented Feb 20, 2025

Thanks. I did not read that comment. I will take a look at the module and come back if I am able to finish it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants