updated LTE-EPC design documentation
This commit is contained in:
Nicola Baldo
@@ -11,7 +11,7 @@ Overall Architecture
|
||||
-----------------------
|
||||
|
||||
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 @@ the following subsections.
|
||||
.. 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 @@ which deal respectively with the eNB and the UE.
|
||||
|
||||
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 @@ UE.
|
||||
|
||||
|
||||
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 @@ the figure :ref:`lte-arch-data-rrc-pdcp-rlc`.
|
||||
|
||||
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 @@ Architecture
|
||||
|
||||
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 @@ following operations:
|
||||
|
||||
#. 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 @@ MAC headers specified by 3GPP.
|
||||
|
||||
|
||||
|
||||
---
|
||||
RLC
|
||||
---
|
||||
------------
|
||||
RLC and PDCP
|
||||
------------
|
||||
|
||||
.. .. include:: lte-rlc-design.rst
|
||||
.. include:: lte-rlc-design.rst
|
||||
|
||||
|
||||
|
||||
@@ -666,7 +670,7 @@ the notification of transmission opportunities notified by the MAC.
|
||||
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 @@ resources based on the characteristics of each Radio Bearer which are
|
||||
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 @@ implementations (RLC/UM or RLC/AM).
|
||||
|
||||
|
||||
|
||||
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 @@ discussed in [Ofcom2.6GHz]_.
|
||||
|
||||
|
||||
|
||||
-------
|
||||
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 @@ where :math:`S_{sample}` is the size in bytes of the sample (e.g., 8 in case of
|
||||
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 @@ A few notes on the above diagram:
|
||||
|
||||
|
||||
|
||||
~~~~~~~~~~~~~~~~~
|
||||
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
|
||||
++++++++++++++++++
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -1,23 +1,18 @@
|
||||
.. include:: replace.txt
|
||||
|
||||
|
||||
****************
|
||||
RLC Layer Design
|
||||
****************
|
||||
|
||||
Overview
|
||||
++++++++
|
||||
|
||||
UM/AM RLC Entities
|
||||
==================
|
||||
|
||||
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 @@ with all the other entities and services in the protocol stack:
|
||||
|
||||
|
||||
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 @@ RLC Service Interface
|
||||
|
||||
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 @@ MAC Service Interface
|
||||
|
||||
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 @@ The following list specifies which service primitives are provided by the MAC se
|
||||
|
||||
|
||||
Interactions between entities and services
|
||||
==========================================
|
||||
++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Transmit operations in downlink
|
||||
-------------------------------
|
||||
@@ -189,7 +184,7 @@ RLC and MAC) and the eNB (MAC) in uplink when data PDUs must be retransmitted by
|
||||
|
||||
|
||||
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 @@ 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**: 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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user