revise RLC design docs
This commit is contained in:
Nicola Baldo
@@ -4,19 +4,24 @@
|
||||
Overview
|
||||
++++++++
|
||||
|
||||
The RLC entity is specified in the 3GPP technical specification [TS36322]_, and comprises three different types of RLC: Transparent Mode (TM), Unacknowledge Mode (UM) and Acknowledged Mode (AM). We implement only the UM and the AM RLC entities.
|
||||
The RLC entity is specified in the 3GPP technical specification
|
||||
[TS36322]_, and comprises three different types of RLC: Transparent
|
||||
Mode (TM), Unacknowledge Mode (UM) and Acknowledged Mode (AM). We
|
||||
implement only the UM and the AM RLC entities.
|
||||
|
||||
The RLC entities provide the RLC service interface to upper PDCP layer and the MAC service interface
|
||||
to lower MAC layer. The RLC entities use the PDCP service interface from upper PDCP layer and
|
||||
the MAC service interface from lower MAC layer.
|
||||
The RLC entities provide the RLC service interface to the upper PDCP layer and the MAC service interface
|
||||
to the lower MAC layer. The RLC entities use the PDCP service interface from the upper PDCP layer and
|
||||
the MAC service interface from the lower MAC layer.
|
||||
|
||||
Figure :ref:`fig-lte-rlc-implementation-model` shows the implementation model of the RLC entities and its relationship
|
||||
Figure :ref:`fig-lte-rlc-implementation-model` shows the
|
||||
implementation model of the RLC entities and its relationship
|
||||
with all the other entities and services in the protocol stack.
|
||||
|
||||
|
||||
.. _fig-lte-rlc-implementation-model:
|
||||
|
||||
.. figure:: figures/lte-rlc-implementation-model.*
|
||||
:width: 800px
|
||||
|
||||
Implementation Model of PDCP, RLC and MAC entities and SAPs
|
||||
|
||||
@@ -112,45 +117,67 @@ Interactions between entities and services
|
||||
Transmit operations in downlink
|
||||
-------------------------------
|
||||
|
||||
The following sequence diagram shows the interactions between the different entities (RRC, PDCP,
|
||||
AM RLC, MAC and MAC scheduler) of the eNB in downlink when data PDUs are sent by the upper layers.
|
||||
The following sequence diagram shows the interactions between the
|
||||
different entities (RRC, PDCP, AM RLC, MAC and MAC scheduler) of the
|
||||
eNB in the downlink to perform data communications.
|
||||
|
||||
Figure 1 shows how upper layers send data PDUs and how the data flow is processed by the different
|
||||
entities/services of the LTE protocol stack. We will explain in detail only the processing related
|
||||
to the AM RLC entity.
|
||||
Figure :ref:`fig-lte-rlc-data-txon-dl` shows how the upper layers send
|
||||
data PDUs and how the data flow is processed by the different
|
||||
entities/services of the LTE protocol stack. We will explain in detail
|
||||
only the processing related to the AM RLC entity, which is the most
|
||||
complex.
|
||||
|
||||
.. _fig-lte-rlc-data-txon-dl:
|
||||
|
||||
.. figure:: figures/lte-rlc-data-txon-dl.*
|
||||
:width: 800px
|
||||
|
||||
Sequence diagram of data PDU transmission in downlink
|
||||
|
||||
The PDCP entity calls the Transmit_PDCP_PDU service primitive in order to send a data PDU. The AM RLC
|
||||
entity processes this service primitive according to the AM data transfer procedures defined in
|
||||
The PDCP entity calls the ``Transmit_PDCP_PDU service primitive`` in
|
||||
order to send a data PDU. The AM RLC entity processes this service
|
||||
primitive according to the AM data transfer procedures defined in
|
||||
section 5.1.3 of [TS36322]_.
|
||||
|
||||
The simplified pseudocode of the processing of this service primitive follows:
|
||||
When the ``Transmit_PDCP_PDU`` service primitive is called, the AM RLC
|
||||
entity performs the following operations:
|
||||
|
||||
* Put the data SDU in the Transmission Buffer.
|
||||
* Compute the size of the buffers. How the size of buffers is computed is explained in detail hereafter.
|
||||
* Call Report_Buffer_Status service primitive of the eNB MAC entity in order to notify the eNB MAC
|
||||
entity the sizes of the buffers of the AM RLC entity. Then, the eNB MAC entity updates the buffer
|
||||
status in the MAC scheduler using the SchedDlRlcBufferReq service primitive.
|
||||
* Compute the size of the buffers (how the size of buffers is
|
||||
computed will be explained afterwards).
|
||||
* Call the ``Report_Buffer_Status`` service primitive of the eNB
|
||||
MAC entity in order to notify to the eNB MAC
|
||||
entity the sizes of the buffers of the AM RLC entity. Then, the
|
||||
eNB MAC entity updates the buffer status in the MAC scheduler
|
||||
using the SchedDlRlcBufferReq service primitive of the FF MAC
|
||||
Scheduler API.
|
||||
|
||||
Afterwards, when the MAC scheduler decides some data can be sent, the MAC entity notifies it to the
|
||||
RLC entity, i.e. it calls the Notify_Tx_Opportunity service primitive, then the AM RLC entity does
|
||||
the following:
|
||||
Afterwards, when the MAC scheduler decides that some data can be sent,
|
||||
the MAC entity notifies it to the RLC entity, i.e. it calls the
|
||||
``Notify_Tx_Opportunity`` service primitive, then the AM RLC entity
|
||||
does the following:
|
||||
|
||||
* Create (concatenate/segment) data PDU from the SDUs in the Transmission Buffer.
|
||||
* Move the data PDU from the Transmission Buffer to the Transmitted PDUs Buffer.
|
||||
* Update state variables according section 5.1.3.1.1 of [TS36322]_.
|
||||
* Call Transmit_PDU in order to send the data PDU to the MAC entity.
|
||||
* Create a single data PDU by segmenting and/or concatenating the
|
||||
SDUs in the Transmission Buffer.
|
||||
* Move the data PDU from the Transmission Buffer to the
|
||||
Transmitted PDUs Buffer.
|
||||
* Update state variables according section 5.1.3.1.1 of
|
||||
[TS36322]_.
|
||||
* Call the ``Transmit_PDU`` primitive in order to send the data
|
||||
PDU to the MAC entity.
|
||||
|
||||
Retransmission in downlink
|
||||
--------------------------
|
||||
|
||||
The following sequence diagram shows the interactions between the different entities (AM RLC, MAC
|
||||
and MAC scheduler) of the eNB in downlink when data PDUs must be retransmitted by the AM RLC entity.
|
||||
The sequence diagram of Figure :ref:`fig-lte-rlc-data-retx-dl` shows
|
||||
the interactions between the different entities (AM RLC, MAC and MAC
|
||||
scheduler) of the eNB in downlink when data PDUs must be retransmitted
|
||||
by the AM RLC entity.
|
||||
|
||||
.. _fig-lte-rlc-data-retx-dl:
|
||||
|
||||
.. figure:: figures/lte-rlc-data-retx-dl.*
|
||||
:width: 500px
|
||||
|
||||
Sequence diagram of data PDU retransmission in downlink
|
||||
|
||||
@@ -164,24 +191,35 @@ Retransmission Buffer.
|
||||
Transmit operations in uplink
|
||||
-----------------------------
|
||||
|
||||
The following sequence diagram shows the interactions between the different entities of the UE (RRC,
|
||||
PDCP, RLC and MAC) and the eNB (MAC and Scheduler) in uplink when data PDUs are sent by the upper
|
||||
layers.
|
||||
The sequence diagram of Figure :ref:`fig-lte-rlc-data-txon-ul` shows
|
||||
the interactions between the different entities of the UE (RRC, PDCP,
|
||||
RLC and MAC) and the eNB (MAC and Scheduler) in uplink when data PDUs
|
||||
are sent by the upper layers.
|
||||
|
||||
.. _fig-lte-rlc-data-txon-ul:
|
||||
|
||||
.. figure:: figures/lte-rlc-data-txon-ul.*
|
||||
:width: 800px
|
||||
|
||||
Sequence diagram of data PDU transmission in uplink
|
||||
|
||||
It is similar to the sequence diagram in downlink. But in this case the Report_Buffer_Status is sent
|
||||
from the UE MAC to the MAC Scheduler in the eNB over the air using the control channel.
|
||||
It is similar to the sequence diagram in downlink; the main difference
|
||||
is that in this case the Report_Buffer_Status is sent from the UE MAC
|
||||
to the MAC Scheduler in the eNB over the air using the control
|
||||
channel.
|
||||
|
||||
Retransmission in uplink
|
||||
------------------------
|
||||
|
||||
The following sequence diagram shows the interactions between the different entities of the UE (AM
|
||||
RLC and MAC) and the eNB (MAC) in uplink when data PDUs must be retransmitted by the AM RLC entity.
|
||||
The sequence diagram of Figure :ref:`fig-lte-rlc-data-retx-ul` shows
|
||||
the interactions between the different entities of the UE (AM RLC and
|
||||
MAC) and the eNB (MAC) in uplink when data PDUs must be retransmitted
|
||||
by the AM RLC entity.
|
||||
|
||||
.. _fig-lte-rlc-data-retx-ul:
|
||||
|
||||
.. figure:: figures/lte-rlc-data-retx-ul.*
|
||||
:width: 500px
|
||||
|
||||
Sequence diagram of data PDU retransmission in uplink
|
||||
|
||||
@@ -197,19 +235,20 @@ Management of buffers in transmit operations
|
||||
|
||||
The AM RLC entity manages 3 buffers:
|
||||
|
||||
* **Transmission Buffer**: it is the RLC SDU queue. The AM RLC entity enqueues the SDU in the
|
||||
Transmission Buffer, when it receives a SDU in the TransmitPdcpPdu service primitive from the
|
||||
upper PDCP entity.
|
||||
* **Transmission Buffer**: it is the RLC SDU queue.
|
||||
When the AM RLC entity receives a SDU in the TransmitPdcpPdu service primitive from the
|
||||
upper PDCP entity, it enqueues it in the Transmission Buffer. We
|
||||
put a limit on the RLC buffer size and just silently drop SDUs
|
||||
when the buffer is full.
|
||||
|
||||
* **Transmitted PDUs Buffer**: it is the queue of transmitted RLC PDUs for which an ACK/NACK has not
|
||||
been received yet. The AM RLC entity also puts a copy of the transmitted PDU in the
|
||||
Transmitted PDUs Buffer, when it sends a PDU to the MAC entity.
|
||||
been received yet. When the AM RLC entity sends a PDU to the MAC
|
||||
entity, it also puts a copy of the transmitted PDU in the Transmitted PDUs Buffer.
|
||||
|
||||
* **Retransmission Buffer**: it is the queue of RLC PDUs which are considered for retransmission
|
||||
(i.e., they have been NACKed). The AM RLC entity moves this PDU to the Retransmission Buffer,
|
||||
when it retransmits a PDU from the Transmitted Buffer.
|
||||
|
||||
We put a limit on the RLC buffer size and just silently drop SDUs when the buffer is full.
|
||||
|
||||
Calculation of the buffer size
|
||||
------------------------------
|
||||
@@ -217,20 +256,26 @@ Calculation of the buffer size
|
||||
The Transmission Buffer contains RLC SDUs. A RLC PDU is one or more SDU segments plus an RLC header.
|
||||
The size of the RLC header of one RLC PDU depends on the number of SDU segments the PDU contains.
|
||||
|
||||
The Buffer size reported in the Report_Buffer_Size is calculated as the data size in the
|
||||
Transmission Buffer plus an estimation of the RLC header size.
|
||||
The 3GPP standard (section 6.1.3.1 of [TS36321]_) says clearly that,
|
||||
for the uplink, the RLC and MAC headers are not considered in the
|
||||
buffer size that is to be report as part of the Buffer Status Report.
|
||||
For the downlink, the behavior is not specified. Neither [FFAPI]_ specifies
|
||||
how to do it. Our RLC model works by assuming that the calculation of
|
||||
the buffer size in the downlink is done exactly as in the uplink,
|
||||
i.e., not considering the RLC and MAC header size.
|
||||
|
||||
The estimation is calculated assuming one fixed RLC header per SDU in the Transmission Buffer.
|
||||
This estimation avoids unnecessary segmentation of the SDUs in the Transmission Buffer if the MAC
|
||||
layer notifies transmission opportunities big enough.
|
||||
We note that this choice affects the interoperation with the
|
||||
MAC scheduler, since, in response to the
|
||||
``Notify_Tx_Opportunity`` service primitive, the RLC is expected to
|
||||
create a PDU of no more than the size requested by the MAC, including
|
||||
RLC overhead. Hence, unneeded fragmentation can occur if (for example)
|
||||
the MAC notifies a transmission exactly equal to the buffer size
|
||||
previously reported by the RLC. We assume that it is left to the Scheduler
|
||||
to implement smart strategies for the selection of the size of the
|
||||
transmission opportunity, in order to eventually avoid the inefficiency
|
||||
of unneeded fragmentation.
|
||||
|
||||
On the other side, if the MAC layer notifies small transmission opportunities, then segmentation
|
||||
arises and the periodicity of the Report_Buffer_Status operation provides a better estimation for
|
||||
the buffer size.
|
||||
|
||||
The exact value of the buffer size can never be calculated. It depends on the number of SDUs in the
|
||||
Transmission Buffer, and the number of transmission opportunities the MAC entity gives to the
|
||||
RLC entity. And this number is totally unknown.
|
||||
|
||||
Concatenation and Segmentation
|
||||
------------------------------
|
||||
@@ -243,16 +288,17 @@ The segmentation and concatenation for the SDU queue of the AM RLC entity follow
|
||||
as the same procedures of the UM RLC entity but there are new state variables (see section 7.1) only
|
||||
present in the AM RLC entity.
|
||||
|
||||
It is noted that according to the 3GPP specs, there is no concatenation for the Retransmission Buffer.
|
||||
It is noted that, according to the 3GPP specs, there is no concatenation for the Retransmission Buffer.
|
||||
|
||||
Re-segmentation
|
||||
---------------
|
||||
|
||||
Initially, we start without re-segmentation of the retransmission buffer. We just wait for a big
|
||||
enough transmission opportunity. An ASSERT is triggered if smalls transmission opportunities are
|
||||
The current model of the AM RLC entity does not support the
|
||||
re-segmentation of the retransmission buffer. Rather, the AM RLC
|
||||
entity just expects to receive a big enough transmission
|
||||
opportunity. An assertion fails if a too small transmission opportunity is
|
||||
received.
|
||||
|
||||
Afterwards, we will evaluate if it is feasible to implement it, or it is too complex.
|
||||
|
||||
Unsupported features
|
||||
--------------------
|
||||
@@ -266,6 +312,6 @@ We do not support the following procedures of [TS36322]_ :
|
||||
|
||||
We do not support any of the additional primitives of RLC SAP for AM RLC entity. In particular:
|
||||
|
||||
* no SDU discard notified by PDCP (maybe we can consider it for M5, if needed)
|
||||
* no SDU discard notified by PDCP
|
||||
* no notification of successful / failed delivery by AM RLC entity to PDCP entity
|
||||
|
||||
|
||||
Reference in New Issue
Block a user