--- a/src/lte/doc/source/lte-rlc-design.rst Fri Dec 09 16:55:14 2011 +0100
+++ b/src/lte/doc/source/lte-rlc-design.rst Fri Dec 09 18:51:32 2011 +0100
@@ -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 @@
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 @@
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 @@
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 @@
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 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.
+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.
-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.
+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.
-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 @@
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 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