--- a/src/lte/doc/source/lte-design.rst Fri Dec 02 13:55:22 2011 +0100
+++ b/src/lte/doc/source/lte-design.rst Fri Dec 02 19:15:37 2011 +0100
@@ -11,7 +11,7 @@
-----------------------
The overall architecture of the LENA simulation model is depicted in
- the figure :ref:`fig-epc-topology`. There are two main conmponents:
+the figure :ref:`fig-epc-topology`. There are two main conmponents:
* the LTE Model. This model includes the LTE Radio Protocol
stack (RRC, PDCP, RLC, MAC, PHY). These entities reside entirely within the
@@ -33,7 +33,9 @@
.. figure:: figures/epc-topology.*
:align: center
- Overall architecture of the LTE-EPC simulation model
+ Overall architecture of the LTE-EPC simulation model
+
+
@@ -134,6 +136,7 @@
Lower LTE radio protocol stack architecture for the UE
+
The LTE lower radio stack model includes in particular the PHY and the MAC layers;
additionally, also the Scheduler is included (which is commonly
associated with the MAC layer). The most important difference between
@@ -146,7 +149,7 @@
The second part is the upper LTE radio stack, which is represented in
-the figure :ref:`lte-arch-data-rrc-pdcp-rlc`.
+the figure :ref:`fig-lte-arch-data-rrc-pdcp-rlc`.
.. _fig-lte-arch-data-rrc-pdcp-rlc:
@@ -155,6 +158,7 @@
Architecture of the upper LTE radio stack
+
This part includes the RRC, PDCP and RLC protocols. The architecture
in this case is very similar between the eNB and the UE: in fact, in
both cases there is a single MAC instance and a single RRC instance,
@@ -235,7 +239,7 @@
The focus of the EPC model is currently on the EPC data plane. To
understand the architecture of this model, we first look at Figure
-:ref:`fig-epc-e2e-data-protocol-stack` representation of the
+:ref:`fig-lte-epc-e2e-data-protocol-stack` representation of the
end-to-end LTE-EPC protocol stack, as it is
implemented in the simulator. From the figure, it is evident that the
biggest simplification introduced in the EPC model for the data plane
@@ -370,11 +374,11 @@
#. it retrieves the RBID from the corresponding Tag in the packet;
#. it determines the corresponding EPS Bearer instance and GTP-U TEID by
- leveraging on the one-to-one mapping between S1-U bearers and Radio
- Bearers;
+ leveraging on the one-to-one mapping between S1-U bearers and Radio
+ Bearers;
#. it adds a GTP-U header on the packet, with the determined TEID;
#. it sends the packet to the SGW/PGW node via the UDP socket
- connected to the S1-U point-to-point net device.
+ connected to the S1-U point-to-point net device.
At this point, the packet contains the S1-U IP, UDP and GTP headers in
addition to the original end-to-end IP header. When the packet is
@@ -646,11 +650,11 @@
----
-RLC
----
+------------
+RLC and PDCP
+------------
-.. .. include:: lte-rlc-design.rst
+.. include:: lte-rlc-design.rst
@@ -666,7 +670,7 @@
In other words, RLC/SM simulates saturation conditions, i.e., it
assumes that the RLC buffer is always full and can generate a new PDU
whenever notified by the scheduler. In fact, the "SM" in the name of
-the model stands for "Saturation Mode").
+the model stands for "Saturation Mode".
RLC/SM is used for simplified simulation scenarios in which only the
LTE Radio model is used, without the EPC and hence without any IP
@@ -680,8 +684,8 @@
specified upon the creation of each Bearer at the start of the
simulation.
- As for schedulers designed to work with real-time QoS
-traffic with delay constraints, RLC/SM is probably not an appropriate choice.
+As for schedulers designed to work with real-time QoS
+traffic that has delay constraints, RLC/SM is probably not an appropriate choice.
This is because the absence of actual RLC SDUs (replaced by the artificial
generation of Buffer Status Reports) makes it not possible to provide
the Scheduler with meaningful head-of-line-delay information, which is
@@ -692,6 +696,30 @@
+PDCP
+++++
+
+The reference document for the specification of the PDCP entity is
+[TS36323]_. With respect to this specification, the PDCP model
+implemented in the simulator supports only the following features:
+
+ * transfer of data (user plane or control plane);
+ * maintenance of PDCP SNs;
+
+The following features are currently not supported:
+
+ * header compression and decompression of IP data flows using the ROHC protocol;
+ * in-sequence delivery of upper layer PDUs at re-establishment of lower layers;
+ * duplicate elimination of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM;
+ * ciphering and deciphering of user plane data and control plane data;
+ * integrity protection and integrity verification of control plane data;
+ * timer based discard;
+ * duplicate discarding.
+
+
+
+
+
---
RRC
---
@@ -763,9 +791,9 @@
--------
-Channel
--------
+-----------------------
+Channel and Propagation
+-----------------------
The LTE module works with the channel objects provided by the Spectrum module, i.e., either SingleModelSpectrumChannel or MultiModelSpectrumChannel. Because of these, all the propagation models supported by these objecs can be used within the LTE module.
@@ -876,9 +904,9 @@
hence :math:`N_{scenarios} = 3`. All traces have :math:`T_{trace} = 10` s and :math:`RB_{NUM} = 100`. This results in a total 24 MB bytes of traces.
-~~~~~~~
+-------
Helpers
-~~~~~~~
+-------
Two helper objects are use to setup simulations and configure the
variosu components. These objects are:
@@ -915,38 +943,4 @@
-~~~~~~~~~~~~~~~~~
-Sequence Diagrams
-~~~~~~~~~~~~~~~~~
-In this section we provide some sequence diagram that illustrate some important interactions among the components of the LTE module.
-
-
-Physical Layer
-++++++++++++++
-
-TODO: add diagram showing interference calculation
-
-
-RLC buffer status report
-++++++++++++++++++++++++
-
-These sequence diagrams represent how the RLC buffer status is updated in the different cases of the downlink and the uplink.
-
-For the downlink:
-
-.. seqdiag:: rlc_buffer_status_report_downlink.seqdiag
-
-
-For the uplink:
-
-.. seqdiag:: rlc_buffer_status_report_uplink.seqdiag
-
-
-
-
-Propagation Models
-++++++++++++++++++
-
-
-
--- a/src/lte/doc/source/lte-references.rst Fri Dec 02 13:55:22 2011 +0100
+++ b/src/lte/doc/source/lte-references.rst Fri Dec 02 19:15:37 2011 +0100
@@ -32,6 +32,8 @@
.. [TS36322] 3GPP TS 36.322 "E-UTRA Radio Link Control (RLC) protocol specification"
+.. [TS36323] 3GPP TS 36.323 "E-UTRA Packet Data Convergence Protocol (PDCP) specification"
+
.. [TS36.101] 3GPP TS 36.101 "E-UTRA User Equipment (UE) radio transmission and reception"
.. [TS36.213] 3GPP TS 36.213 "E-UTRA Physical layer procedures"
--- a/src/lte/doc/source/lte-rlc-design.rst Fri Dec 02 13:55:22 2011 +0100
+++ b/src/lte/doc/source/lte-rlc-design.rst Fri Dec 02 19:15:37 2011 +0100
@@ -1,23 +1,18 @@
.. include:: replace.txt
-****************
-RLC Layer Design
-****************
-
-UM/AM RLC Entities
-==================
+Overview
+++++++++
-The RLC entity is specified in the 3GPP technical specification [TS36322]_. We implement two of the
-three types of RLC entities: UM RLC entity and AM RLC entity.
+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 following figure shows the implementation model of the RLC entities and its relationship
-with all the other entities and services in the protocol stack:
+Figure :ref:`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.
.. figure:: figures/lte-rlc-implementation-model.*
@@ -25,15 +20,15 @@
Service Interfaces
-==================
+++++++++++++++++++
PDCP Service Interface
----------------------
The PDCP service interface is divided into two parts:
- * ``PdcpSapProvider`` service part is provided by the PDCP layer and used by the upper layer and
- * ``PdcpSapUser`` service part is provided by the upper layer and used by the PDCP layer.
+ * the ``PdcpSapProvider`` part is provided by the PDCP layer and used by the upper layer and
+ * the ``PdcpSapUser`` part is provided by the upper layer and used by the PDCP layer.
PDCP Service Primitives
^^^^^^^^^^^^^^^^^^^^^^^
@@ -55,10 +50,10 @@
The RLC service interface is divided into two parts:
- * ``RlcSapProvider`` service part is provided by the RLC layer and used by the upper PDCP layer and
- * ``RlcSapUser`` service part is provided by the upper PDCP layer and used by the RLC layer.
+ * the ``RlcSapProvider`` part is provided by the RLC layer and used by the upper PDCP layer and
+ * the ``RlcSapUser`` part is provided by the upper PDCP layer and used by the RLC layer.
-The UM/AM RLC entities provide the same RLC service interface to the upper PDCP layer.
+Both the UM and the AM RLC entities provide the same RLC service interface to the upper PDCP layer.
RLC Service Primitives
^^^^^^^^^^^^^^^^^^^^^^
@@ -80,8 +75,8 @@
The MAC service interface is divided into two parts:
- * ``MacSapProvider`` service part is provided by the MAC layer and used by the upper RLC layer and
- * ``MacSapUser`` service part is provided by the upper RLC layer and used by the MAC layer.
+ * the ``MacSapProvider`` part is provided by the MAC layer and used by the upper RLC layer and
+ * the ``MacSapUser`` part is provided by the upper RLC layer and used by the MAC layer.
MAC Service Primitives
^^^^^^^^^^^^^^^^^^^^^^
@@ -109,7 +104,7 @@
Interactions between entities and services
-==========================================
+++++++++++++++++++++++++++++++++++++++++++
Transmit operations in downlink
-------------------------------
@@ -189,7 +184,7 @@
AM data transfer
-================
+++++++++++++++++
The processing of the data transfer in the AM RLC entity is explained in section 5.1.3 of [TS36322]_.
In this section we describe some details of the implementation of the RLC entity.
@@ -199,15 +194,15 @@
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**: 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.
- * Transmitted PDUs Buffer, it is the queue of transmitted RLC PDUs for which an ACK/NACK has not
+ * **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.
- * Retransmission Buffer, it is the queue of RLC PDUs which are considered for retransmission
+ * **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.