F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updated UE measurements documentation

Browse Source
This commit is contained in:
Budiarto Herman
2013-06-24 00:19:06 +03:00
parent 34558334e8
commit 0ef013fc85
3 changed files with 140 additions and 120 deletions
Download Patch File Download Diff File Expand all files Collapse all files

123
src/lte/doc/source/lte-design.rst
View File

@@ -2,13 +2,13 @@
++++++++++++++++++++++++++
Design Documentation
++++++++++++++++++++++++++
Design Documentation
++++++++++++++++++++
---------
--------
Overview
---------
--------
An overview of the LTE-EPC simulation model is depicted in
@@ -34,9 +34,9 @@ the figure :ref:`fig-epc-topology`. There are two main components:
.. _sec-design-criteria:
-----------------------
---------------
Design Criteria
-----------------------
---------------
LTE Model
@@ -159,16 +159,16 @@ The following design choices have been made for the EPC model:
.. _overall-architecture:
-----------------------
------------
Architecture
-----------------------
------------
LTE Model
++++++++++
LTE Model
+++++++++
@@ -455,9 +455,9 @@ the IsotropicAntennaModel is used for both eNBs and UEs.
\clearpage
----
---
PHY
----
---
Overview
@@ -776,9 +776,9 @@ where :math:`RSRP_i` is the RSRP of the neighbor cell :math:`i`, :math:`P_i(k)`
----------
HARQ
----------
----
HARQ
----
The HARQ scheme implemented is based on a incremental redundancy (IR) solutions combined with multiple stop-and-wait processes for enabling a continuous data flow. In detail, the solution adopted is the *soft combining hybrid IR Full incremental redundancy* (also called IR Type II), which implies that the retransmissions contain only new information respect to the previous ones. The resource allocation algorithm of the HARQ has been implemented within the respective scheduler classes (i.e., ``RrFfMacScheduler`` and ``PfFfMacScheduler``, refer to their correspondent sections for more info), while the decodification part of the HARQ has been implemented in the ``LteSpectrumPhy`` and ``LteHarqPhy`` classes which will be detailed in this section.
@@ -821,9 +821,9 @@ Finally, the HARQ engine is always active both at MAC and PHY layer; however, in
Interaction between HARQ and LTE protocol stack
------
MAC
------
---
MAC
---
Resource Allocation Model
@@ -1085,7 +1085,7 @@ For what concern the HARQ, PF implements the non adaptive version, which implies
Maximum Throughput (MT) Scheduler
----------------------------------
---------------------------------
The Maximum Throughput (MT) scheduler [FCapo2012]_ aims to maximize the overall throughput of eNB.
It allocates each RB to the user that can achieve the maximum achievable rate in the current TTI.
@@ -1122,7 +1122,7 @@ fairness to UEs in poor channel condition.
Throughput to Average (TTA) Scheduler
--------------------------------------
-------------------------------------
The Throughput to Average (TTA) scheduler [FCapo2012]_ can be considered as an intermediate between MT and PF.
The metric used in TTA is calculated as follows:
@@ -1347,9 +1347,9 @@ and the other entities.
\clearpage
----
RLC
----
---
RLC
---
@@ -1667,7 +1667,7 @@ with the difference that, following the specifications of [TS36322]_,
retransmission are not performed, and there are no STATUS PDUs.
Transmit operations in uplink
------------------------------
-----------------------------
The transmit operations in the uplink are similar to those of the
downlink, with the main difference that the Report_Buffer_Status is
@@ -1993,7 +1993,6 @@ based on UE measurements are planned only at a later stage).
UE RRC Measurements Model
+++++++++++++++++++++++++
UE RRC measurements support
---------------------------
@@ -2063,6 +2062,9 @@ The eNodeB RRC entity implements the configuration parameters and procedures
described in Section 5.5.2 of [TS36331]_, with the following simplifying
assumption:
- all UEs attached to the eNodeB will be configured the same way, i.e. there is
no support for configuring specific measurement for specific UE; and
- it is assumed that there is a one-to-one mapping between the PCI and the
E-UTRAN Global Cell Identifier (EGCI). This is consistent with the PCI
modeling assumptions described in :ref:`phy-ue-measurements`.
@@ -2082,6 +2084,8 @@ Users may customize the measurement configuration using several methods. More
details are explained in user documentation
(:ref:`sec-configure-ue-measurements`).
.. _sec-performing-measurements:
Performing measurements
-----------------------
@@ -2105,7 +2109,7 @@ where:
`filterCoefficent` provided by the ``QuantityConfig``;
:math:`k = 4` is the default value, but can be configured by setting the
`L3FilteringRsrpCoefficient` and `L3FilteringRsrqCoefficient` attributes in
`RsrpFilterCoefficient` and `RsrqFilterCoefficient` attributes in
``LteEnbRrc``.
Measurement reporting triggering
@@ -2117,13 +2121,9 @@ of [TS36331]_. When at least one trigerring condition from all the active
measurement configuration is fulfilled, the measurement reporting procedure (in
the next subsection) will be initiated.
There are 2 supported `triggerType`: periodical and event-based. In *periodical*
criterion, the reporting is simply triggered when the timer expires. The
periodicity of the timer can be selected from the options defined in
``enum reportInterval`` within ``LteRrcSap::ReportConfigEutra``.
While in *event-based* criterion, there are various events that can be selected,
which are briefly described in the table below:
3GPP defines two kinds of `triggerType`: periodical and event-based. At the
moment, only *event-based* criterion is supported. There are various events that
can be selected, which are briefly described in the table below:
.. table:: List of supported event-based triggering criteria
@@ -2148,6 +2148,15 @@ entering and leaving conditions in dB. In effect, it delays both conditions by
half of the specified dB. Similarly, *time-to-trigger* introduces delay to both
entering and leaving conditions, but as a unit of time.
*Periodical* type of reporting trigger is not supported, but can be easily
replicated using event-based trigger. This can be done by configuring the
measurement in such a way that the entering condition is always fulfilled, for
example by setting the threshold of Event A1 to zero (the minimum level).
As a result, the measurement report will be regularly triggered at every certain
interval, as determined by the `reportInterval` field within
``LteRrcSap::ReportConfigEutra``, therefore producing the same behaviour as
periodical reporting.
In contrast with 3GPP standard, the current model does not support cell-specific
configuration, which is defined in measurement object. As a consequence,
incorporating a list of black cells into the triggering process is not
@@ -2161,13 +2170,13 @@ Measurement reporting
This part handles the submission of measurement report from the UE RRC entity
to the serving eNodeB entity via RRC protocol. Several assumptions apply:
- `reportAmount` does *not* apply for event-based measurement (i.e. always
assumed to be infinite), but does apply for periodical measurement;
- `reportAmount` is *not* applicable (i.e. always assumed to be infinite);
- in measurement reports, the `reportQuantity` is always assumed to be `BOTH`,
i.e., both RSRP and RSRQ are always reported, regardless of the
`triggerQuantity`.
Handover
++++++++
@@ -2201,6 +2210,26 @@ The simulation user can set two parameters to control the handover decision:
- neighbourHandoverOffset, if the difference between the best neighbour RSRQ
and the serving cell RSRQ is greater or equal to the neighbourHandoverOffset
parameter, then the handover procedure is triggered for this UE.
.. _sec-custom-handover-algorithm:
Custom handover algorithm
-------------------------
When the existing handover algorithms are not flexible enough, (for instance,
the Strongest Cell handover algorithm is limited to Event A3 only), users may
develop a subclass of handover algorithm.
In the implementation, users may submit one or more UE measurements
configuration message to the eNodeB RRC entity via the Handover Algorithm SAP
interface (``AddUeMeasReportConfig``). Later during the simulation, the
requested measurement reports will be delivered using another method of Handover
Algorithm SAP interface (``ReportUeMeas``).
Note that the handover algorithm does not have to remember the `measId` of the
requested measurement configuration, because the eNodeB RRC will maintain a list
of the `measId` in question, and only submit the measurement reports which come
from the listed `measId`.
RRC sequence diagrams
@@ -2459,9 +2488,9 @@ The following RRC SAP have been implemented:
--------
---
NAS
--------
---
The focus of the LTE-EPC model is on the NAS Active state, which corresponds to EMM Registered, ECM connected, and RRC connected. Because of this, the following simplifications are made:
@@ -2502,12 +2531,12 @@ procedure.
-----------------
--
S1
-----------------
--
S1-U
+++++++++
S1-U
++++
The S1-U interface is modeled in a realistic way by encapsulating
data packets over GTP/UDP/IP, as done in real LTE-EPC systems. The
@@ -2663,7 +2692,7 @@ is sufficient to meet the QoS requirements of all bearers.
S1AP
+++++
++++
The S1-AP interface provides control plane interaction between the eNB
and the MME. In the simulator, this interface is modeled in an ideal
@@ -2690,9 +2719,9 @@ The S1-AP primitives that are modeled are:
---
X2
---
--
X2
--
The X2 interface interconnects two eNBs [TS36420]_. From a logical
point of view, the X2 interface is a point-to-point interface between
@@ -2941,9 +2970,9 @@ indication and Handover Report are not supported at this stage.
-----------------
---
S11
-----------------
---
The S11 interface provides control plane interaction between the SGW
and the MME using the GTPv2-C protocol specified in [TS29274]_. In the

55
src/lte/doc/source/lte-testing.rst
View File

@@ -2,8 +2,8 @@
+++++++++++++++++++++++++++
Testing Documentation
+++++++++++++++++++++++++++
Testing Documentation
+++++++++++++++++++++
Overview
@@ -195,7 +195,7 @@ contains separate values for uplink and downlink.
UE Measurements Tests
-----------------------------
---------------------
The test suite `lte-ue-measurements`` provides system tests recreating an
inter-cell interference scenario identical of the one defined for `lte-interference`` test-suite. However, in this test the quantities to be tested are represented by RSRP and RSRQ measurements performed by the UE in two different points of the stack: the source, which is UE PHY layer, and the destination, that is the eNB RRC.
@@ -215,7 +215,7 @@ The tables below are the complete list of cases for testing the UE measurements
configuration function. Note that the asterisks mark means that the case
consists of 4 subcases: plain, with hysteresis, with time-to-trigger, or both.
.. table:: UE measurement configuration test cases with constant measurement,
.. table:: UE measurement configuration test cases with piecewise configuration,
1 eNodeB, and 1 static UE
====== ================== ===========================
@@ -231,7 +231,7 @@ consists of 4 subcases: plain, with hysteresis, with time-to-trigger, or both.
8 Periodical 480 ms *TBD*
====== ================== ===========================
.. table:: UE measurement configuration test cases with constant measurement,
.. table:: UE measurement configuration test cases with piecewise configuration,
2 eNodeB, and 1 static UE
====== ================== ===========================
@@ -258,22 +258,18 @@ consists of 4 subcases: plain, with hysteresis, with time-to-trigger, or both.
The above list is implemented as 3 ``TestCase`` classes associated with
``LteUeMeasConfigTestSuite`` (*lte-ue-meas-config* test suite). These test cases
only verifies the timing accuracy of the measurement reports. The contents of
the report itself are not verified. The verification of the content is left to
the existing ``LteUeMeasurementsTestSuite``. The following assumptions are used:
RSRP report quantity, ideal RRC protocol.
verify the timing and RSRP accuracy of the measurement reports. The following
assumptions are used: ideal RRC protocol, and no layer 3 filtering.
Constant measurement configuration
++++++++++++++++++++++++++++++++++
Piecewise configuration
+++++++++++++++++++++++
In the constant measurement cases, the UE will have the same measurement
In the piecewise configuration case, the UE will have the same measurement
configuration throughout the simulation. The tests will attempt to provoke
entering and leaving conditions at different time in the simulation by dropping
and restoring the transmission power of the serving cell (on/off Tx Power) in an
alternating way. The period of the the drops and restorations will be
progressively increased, as illustrated in Figure :ref:`fig-tx-power-timing`
below. The 200 ms period in the beginning is allocated to wait for the first
report from UE PHY.
entering and leaving conditions at different time in the simulation by moving
the UE to different locations, thus varying the received power, as
illustrated in Figure :ref:`fig-tx-power-timing` below. The 200 ms period in the
beginning is allocated to wait for the first report from UE PHY.
.. _fig-tx-power-timing:
@@ -282,25 +278,10 @@ report from UE PHY.
Period of Tx Power on and off in constant measurement test case
The motivation behind the on/off Tx power approach is to introduce drastic
change which will guarantee the triggering of entering or leaving condition of
the tested event. By performing drastic changes, the test can be run within
shorter amount of time. However, the Layer 1 and Layer 3 filtering will still
produce some smoothing effect and must be taken into account. "Teleporting" the
UE between two fixed locations (very near and very far away from the eNodeB) can
also be considered as an alternative to the on/off Tx power approach.
The constructor definition of the ``TestCase`` classes will be as below::
LteUeMeasurementsConstantTestCase1 (LteRrcSap::ReportConfigEutra config,
std::vector<Time> expectedOccurrences);
LteUeMeasurementsConstantTestCase2 (LteRrcSap::ReportConfigEutra config,
std::vector<Time> expectedOccurrences);
The input `config` will be passed as it is to the
``LteEnbRrc::AddUeMeasReportConfig`` function during the simulation setup.
``TestSuite`` will be responsible to create the correct `config` for each
``TestCase``.
The motivation behind the *"teleport"* is to introduce drastic change which will
guarantee the triggering of entering or leaving condition of the tested event.
By performing drastic changes, the test can be run within shorter amount of
time.
The case with 2 eNodeB (the second test case) exists for testing event-based
triggering which is determined by neighbouring cells.

82
src/lte/doc/source/lte-user.rst
View File

@@ -2,8 +2,8 @@
+++++++++++++++++++++++++++++++++
User Documentation
+++++++++++++++++++++++++++++++++
User Documentation
++++++++++++++++++
Background
@@ -137,8 +137,8 @@ Here is the minimal simulation program that is needed to do an LTE-only simulati
For how to compile and run simulation programs, please refer to [ns3tutorial]_.
Configuration of LTE model parameters
--------------------------------------
Configuration of LTE model parameters
-------------------------------------
All the relevant LTE model parameters are managed through the ns-3
attribute system. Please refer to the [ns3tutorial]_ and [ns3manual]_
@@ -503,7 +503,7 @@ The simulator provide natively three fading traces generated according to the co
Excerpt of the fading trace included in the simulator for an urban scenario (speed of 3 kmph).
Mobility Model with Buildings
Mobility Model with Buildings
-----------------------------
We now explain by examples how to use the buildings model (in particular, the ``MobilityBuildingInfo`` and the ``BuildingPropagationModel`` classes) in an ns-3 simulation program to setup an LTE simulation scenario that includes buildings and indoor nodes.
@@ -934,11 +934,14 @@ Direct configuration in eNodeB RRC entity
*****************************************
Users may add their custom UE measurement configuration by creating a new
``LteRrcSap::ReportConfigEutra`` and pass it to the
``LteRrcSap::ReportConfigEutra`` instance and pass it to the
``LteEnbRrc::AddUeMeasReportConfig`` function. The function will return the
``measId`` which identifies the configuration. The user can capture the produced
measurement reports by listening to the existing
``LteEnbRrc::RecvMeasurementReport`` trace.
``measId`` (measurement identity) which is a unique reference of the
configuration in the eNodeB instance. This function must be called before the
simulation begins. The measurement configuration will be active in all UEs
attached to the eNodeB throughout the duration of the simulation. During the
simulation, user can capture the measurement reports produced by the UEs by
listening to the existing ``LteEnbRrc::RecvMeasurementReport`` trace source.
The structure `ReportConfigEutra` is in accord with 3GPP specification.
Definition of the structure and each member field can be found in Section 6.3.5
@@ -948,7 +951,6 @@ The code sample below configures Event A1 RSRP measurement to every eNodeB
within the container ``devs``::
LteRrcSap::ReportConfigEutra config;
config.triggerType = LteRrcSap::ReportConfigEutra::EVENT;
config.eventId = LteRrcSap::ReportConfigEutra::EVENT_A1;
config.threshold1.choice = LteRrcSap::ThresholdEutra::THRESHOLD_RSRP;
config.threshold1.range = 41;
@@ -972,6 +974,11 @@ within the container ``devs``::
MakeCallback (&RecvMeasurementReportCallback));
}
Note that thresholds are expressed as range. In the example above, the range 41
for RSRP corresponds to -100 dBm. The conversion from and to range is due to
Section 9.1.4 and 9.1.7 of [TS36133]_. The ``EutranMeasurementMapping`` class
has several static functions that can be used for this purpose.
The corresponding callback function would have a definition similar as below::
void
@@ -981,12 +988,36 @@ The corresponding callback function would have a definition similar as below::
uint16_t rnti,
LteRrcSap::MeasurementReport measReport);
The ``LteRrcSap::MeasurementReport`` argument contains the ``measId``, which can
be used to tell whether the report is intended for her.
This method will register the callback function as a consumer of UE
measurements. In the case where there are more than one consumers in the
simulation (e.g. handover algorithm), the measurements intended for other
consumers will also be captured by this callback function. Users may utilize the
the ``measId`` field, contained within the ``LteRrcSap::MeasurementReport``
argument of the callback function, to tell which measurement configuration has
triggered the report.
Note that thresholds are expressed as range. In the example above, the range 41
for RSRP corresponds to -100 dBm. The conversion from and to range is due to
Section 9.1.4 and 9.1.7 of [TS36133]_.
In general, this mechanism prevents one consumer to unknowingly intervene with
another consumer's reporting configuration.
Note that only the reporting configuration part (i.e.
``LteRrcSap::ReportConfigEutra``) of the UE measurements parameter is open for
consumers to configure, while the other parts are kept hidden. The
intra-frequency limitation is the main motivation behind this API implementation
decision:
- there is only one, unambiguous and definitive *measurement object*, thus
there is no need to configure it;
- *measurement identities* are kept hidden because of the fact that there is
one-to-one mapping between reporting configuration and measurement identity,
thus a new measurement identity is set up automatically when a new reporting
configuration is created;
- *quantity configuration* is configured elsewhere, see
:ref:`sec-performing-measurements`; and
- *measurement gaps* are not supported, because it is only applicable for
inter-frequency settings;
Configuring existing handover algorithm
***************************************
@@ -1070,27 +1101,6 @@ You can find more info about events A2 and A4 in Subsections 5.5.4.3 and 5.5.4.5
of [TS36331]_.
.. _sec-custom-handover-algorithm:
Custom handover algorithm
*************************
When the existing handover algorithms are not flexible enough, (for instance,
the Strongest Cell handover algorithm is limited to Event A3 only), users may
develop a subclass of handover algorithm.
In the implementation, users may submit one or more UE measurements
configuration message to the eNodeB RRC entity via the Handover Algorithm SAP
interface (``AddUeMeasReportConfig``). Later during the simulation, the
requested measurement reports will be delivered using another method of Handover
Algorithm SAP interface (``ReportUeMeas``).
Note that the handover algorithm does not have to remember the `measId` of the
requested measurement configuration, because the eNodeB RRC will maintain a list
of the `measId` in question, and only submit the measurement reports which come
from the listed `measId`.
Handover traces
***************