lte: Add RLF related documentation

doc/models/Makefile

@@ -178,6 +178,10 @@ SOURCEFIGS = \
 	$(SRC)/lte/doc/source/figures/lte-rlc-data-retx-dl.dia \
 	$(SRC)/lte/doc/source/figures/lte-rlc-data-txon-ul.dia \
 	$(SRC)/lte/doc/source/figures/lte-rlc-data-retx-ul.dia \
+	$(SRC)/lte/doc/source/figures/lte-test-rlf-one-enb.dia \
+	$(SRC)/lte/doc/source/figures/lte-test-rlf-two-enb.dia \
+	$(SRC)/lte/doc/source/figures/lena-radio-link-failure-one-enb.dia \
+	$(SRC)/lte/doc/source/figures/lena-radio-link-failure-two-enb.dia \
 	$(SRC)/lte/doc/source/figures/lte-epc-x2-entity-saps.dia \
 	$(SRC)/lte/doc/source/figures/ca-rrc-reconf.dia \
 	$(SRC)/lte/doc/source/figures/ca-lte-enb-net-device-changes.dia \
@@ -269,12 +273,20 @@ SOURCEFIGS = \
 	$(SRC)/lte/doc/source/figures/ca-test-example-ul.png \
 	$(SRC)/lte/doc/source/figures/ca-test-example-dl.pdf \
 	$(SRC)/lte/doc/source/figures/ca-test-example-dl.png \
+	$(SRC)/lte/doc/source/figures/lena-radio-link-failure-one-enb-thrput.png \
+	$(SRC)/lte/doc/source/figures/lena-radio-link-failure-two-enb-thrput.png \
 	$(SRC)/lte/doc/source/figures/lte-dl-power-control.dia \
 	$(SRC)/lte/doc/source/figures/lte-ffr-scheduling.dia \
 	$(SRC)/lte/doc/source/figures/lte-handover-campaign-rem.pdf \
 	$(SRC)/lte/doc/source/figures/lte-handover-campaign-rem.png \
 	$(SRC)/lte/doc/source/figures/lte-legacy-handover-algorithm.pdf \
 	$(SRC)/lte/doc/source/figures/lte-legacy-handover-algorithm.png \
+	$(SRC)/lte/doc/source/figures/lte-ue-context-removal-from-epc.pdf \
+	$(SRC)/lte/doc/source/figures/lte-ue-context-removal-from-epc.png \
+	$(SRC)/lte/doc/source/figures/lte-ue-context-removal-from-enb-stack.pdf \
+	$(SRC)/lte/doc/source/figures/lte-ue-context-removal-from-enb-stack.png \
+	$(SRC)/lte/doc/source/figures/lte-ue-procedures-after-rlf.pdf \
+	$(SRC)/lte/doc/source/figures/lte-ue-procedures-after-rlf.png \
 	$(SRC)/uan/doc/auvmobility-classes.dia \
 	$(SRC)/netanim/doc/figures/PacketStatistics.png \
 	$(SRC)/netanim/doc/figures/PacketStatistics.pdf \
@@ -407,6 +419,10 @@ IMAGES_EPS = \
 	$(FIGURES)/ca-enb-ctrl-plane.eps \
 	$(FIGURES)/ca-ue-data-plane.eps \
 	$(FIGURES)/ca-ue-ctrl-plane.eps \
+	$(FIGURES)/lte-test-rlf-one-enb.eps \
+	$(FIGURES)/lte-test-rlf-two-enb.eps \
+	$(FIGURES)/lena-radio-link-failure-one-enb.eps \
+	$(FIGURES)/lena-radio-link-failure-two-enb.eps \
 
 # rescale pdf figures as necessary
 $(FIGURES)/testbed.pdf_width = 5in
@@ -425,6 +441,7 @@ $(FIGURES)/lte-interference-test-scenario.pdf_width = 3in
 $(FIGURES)/epc-ctrl-arch.pdf_width = 8cm
 $(FIGURES)/epc-topology.pdf_width = 4in
 $(FIGURES)/epc-topology-x2-enhanced.pdf_width = 14cm
+$(FIGURES)/lena-radio-link-failure-one-enb.pdf_width = 10cm
 $(FIGURES)/lte-arch-data-rrc-pdcp-rlc.pdf_width = 3in
 $(FIGURES)/lte-epc-e2e-data-protocol-stack.pdf_width = 15cm
 $(FIGURES)/ff-mac-saps.pdf_width = 5in

src/lte/doc/Makefile

@@ -70,7 +70,10 @@ IMAGES_DIA = \
 	$(FIGURES)/ca-ue-ctrl-plane.dia \
 	$(FIGURES)/ca-rrc-reconf.dia \
 	$(FIGURES)/ca-lte-enb-net-device-changes.dia \
-	$(FIGURES)/ca-lte-ue-net-device-changes.dia
+	$(FIGURES)/ca-lte-ue-net-device-changes.dia \
+	$(FIGURES)/lte-test-rlf-one-enb.dia \
+	$(FIGURES)/lena-radio-link-failure-one-enb.dia \
+	$(FIGURES)/lena-radio-link-failure-two-enb.dia	
 
 # specify eps figures from which .png and .pdf figures need to be built
 
@@ -123,6 +126,9 @@ IMAGES_SEQDIAG = \
 	$(FIGURES)/ca-downlink-bsr.seqdiag \
 	$(FIGURES)/ca-setup-radio-bearer.seqdiag \
 	$(FIGURES)/ca-uplink-bsr.seqdiag \
+	$(FIGURES)/lte-ue-context-removal-from-epc.seqdiag \
+	$(FIGURES)/lte-ue-context-removal-from-enb-stack.seqdiag \
+	$(FIGURES)/lte-ue-procedures-after-rlf.seqdiag
 
 IMAGES_DOT = \
 	$(FIGURES)/lte-enb-rrc-states.dot \
@@ -179,6 +185,8 @@ IMAGES_NOBUILD = $(FIGURES)/fading_pedestrian.png \
 	$(FIGURES)/carrier-aggregation-mac-impact.png \
 	$(FIGURES)/ca-test-example-ul.png \
 	$(FIGURES)/ca-test-example-dl.png \
+	$(FIGURES)/lena-radio-link-failure-one-enb-thrput.png \
+	$(FIGURES)/lena-radio-link-failure-two-enb-thrput.png \
 	${IMAGES_SEQDIAG:.seqdiag=.png} \
 	${IMAGES_SEQDIAG:.seqdiag=.pdf} \
 	${IMAGES_DOT:.dot=.png} \

src/lte/doc/source/figures/lte-ue-context-removal-from-enb-stack.seqdiag

@@ -0,0 +1,14 @@
+
+diagram {
+
+LteEnbRrc;UeManager;EpcEnbApplication;"LteUeMac (All MACs)";Scheduler;"LteUePhy (All Phys)";LteSpectrumPhy;LteEnbComponentCarrierManager;RrcProtocol
+         
+LteEnbRrc ->> UeManager [label="CancelPendingEvents ()"];
+LteEnbRrc ->> "LteUeMac (All MACs)" [label="RemoveUe (rnti)"];
+"LteUeMac (All MACs)" ->> Scheduler [label="CschedUeReleaseReq (params)"];
+LteEnbRrc ->> "LteUePhy (All Phys)" [label="RemoveUe (rnti)"];
+"LteUePhy (All Phys)" ->> LteSpectrumPhy [label="RemoveExpectedTb (rnti)"];
+LteEnbRrc ->> EpcEnbApplication [label="UeContextRelease (rnti)"];
+LteEnbRrc ->> LteEnbComponentCarrierManager [label="RemoveUe (rnti)"];
+LteEnbRrc ->> RrcProtocol [label="RemoveUe (rnti)"];
+}

src/lte/doc/source/figures/lte-ue-context-removal-from-epc.seqdiag

@@ -0,0 +1,16 @@
+
+diagram {
+
+          LteEnbRrc; UeManager; EpcEnbApplication; EpcMmeApplication; EpcSgwApplication; EpcPgwApplication; UeInfo;
+         
+          LteEnbRrc ->> UeManager [label="RecvIdealUeContext\nRemoveRequest (rnti)"];
+          UeManager ->> EpcEnbApplication [label="DoSendReleaseIndication\n(Imsi, rnti, bearerId)"];
+          EpcEnbApplication ->> EpcMmeApplication [label="ErabReleaseIndication\n(imsi, rnti, erabToBeReleaseIndication)"];
+          EpcMmeApplication ->> EpcSgwApplication [label="DeleteBearerCommand"];
+          EpcSgwApplication ->> EpcPgwApplication [label="DeleteBearerCommand"];
+          EpcSgwApplication <<- EpcPgwApplication [label="DeleteBearerRequest"];
+          EpcMmeApplication <<- EpcSgwApplication [label="DeleteBearerRequest"];
+          EpcMmeApplication ->> EpcSgwApplication [label="DeleteBearerResponse"];
+          EpcSgwApplication ->> EpcPgwApplication [label="DeleteBearerResponse"];
+          EpcPgwApplication ->> UeInfo [label="RemoveBearer (epsBearerId)"];
+}

src/lte/doc/source/figures/lte-ue-procedures-after-rlf.seqdiag

@@ -0,0 +1,26 @@
+
+diagram {
+
+         EpcUeNas; LteUeRrc; "LteUeMac (all MACs)"; "LteUePhy (All Phys)"; LteUeComponentCarrierManager; LteEnbRrc;
+
+         
+         LteUeRrc ->> LteUeRrc [label="SwitchToState (CONNECTED_PHY_PROBLEM)"];
+         EpcUeNas <<- LteUeRrc [label="NotifyConnectionReleased ()"];
+         LteUeRrc ->> LteEnbRrc [label="SendIdealUeContext\nRemoveRequest(rnti)"];
+         EpcUeNas ->> EpcUeNas [label="Disconnect ()"];
+         EpcUeNas ->> EpcUeNas [label="SwitchToState (OFF)"];
+         EpcUeNas ->> LteUeRrc [label="Disconnect ()"];
+         LteUeRrc ->> LteUeRrc [label="LeaveConnectedMode ()"];
+         LteUeRrc ->> LteUeRrc [label="VarMeasReportListClear (measId)"];
+         LteUeRrc ->> LteUeRrc [label="CancelEnteringTrigger (measId, cellId)"];
+         LteUeRrc ->> LteUeComponentCarrierManager [label="Reset ()"];
+         LteUeRrc ->> "LteUeMac (all MACs)" [label="Reset ()"];
+         LteUeRrc ->> "LteUePhy (All Phys)" [label="Reset ()"];
+         LteUeRrc ->> LteUeRrc [label="SwitchToState (IDLE_START)"];
+         LteUeRrc ->> LteUeRrc [label="DoStartCellSelection (dlEarfcn)"];
+         LteUeRrc ->> "LteUePhy (All Phys)" [label="Only primary carrier PHY\nStartCellSearch (dlEarfcn)"];
+         LteUeRrc ->> LteUeRrc [label="SwitchToState (IDLE_CELL_SEARCH)"];
+         LteUeRrc ->> LteUeRrc [label="StorePrevious\nCellId (cellId)"];
+         LteUeRrc ->> LteUeRrc [label="DoSetTemporaryCellRnti (0)"];
+}
+

src/lte/doc/source/figures/lte-ue-rrc-states.dot

@@ -12,6 +12,7 @@ IDLE_RANDOM_ACCESS [shape="box",width=3]
 IDLE_CONNECTING [shape="box",width=3]
 CONNECTED_NORMALLY [shape="box",width=3]
 CONNECTED_HANDOVER [shape="box",width=3]
+CONNECTED_PHY_PROBLEM [shape="box",width=3]
 
 
 // Network attachment
@@ -35,4 +36,12 @@ IDLE_CONNECTING -> IDLE_CAMPED_NORMALLY [label="T300 expiry or\nrx RRC CONN\nREJ
 CONNECTED_NORMALLY -> CONNECTED_HANDOVER [label="rx RRC CONN RECONF\nwith MobilityCtrlInfo"]
 CONNECTED_HANDOVER -> CONNECTED_NORMALLY [label="random access\nsuccessful"]
 
+// RLF
+CONNECTED_NORMALLY -> CONNECTED_NORMALLY [label="N311 in-synch\nreceived"]
+CONNECTED_NORMALLY -> CONNECTED_PHY_PROBLEM [label="T310 expired"]
+CONNECTED_PHY_PROBLEM -> IDLE_START [label="NAS call to Disconnect"]
+
+//T300 expiration counter limit reached
+IDLE_CONNECTING -> CONNECTED_PHY_PROBLEM [label="T300 expiration\ncounter limit\nreached"]
+
 }

src/lte/doc/source/lte-design.rst

@@ -492,6 +492,7 @@ MAC to Channel delay
 
 To model the latency of real MAC and PHY implementations, the PHY model simulates a MAC-to-channel delay in multiples of TTIs (1ms). The transmission of both data and control packets are delayed by this amount.
 
+.. _sec-cqi-feedback:
 
 CQI feedback
 ++++++++++++
@@ -682,7 +683,9 @@ The model implemented uses the curves for the LSM of the recently LTE PHY Error
 
 The model can be disabled for working with a zero-losses channel by setting the ``PemEnabled`` attribute of the ``LteSpectrumPhy`` class (by default is active). This can be done according to the standard ns3 attribute system procedure, that is::
 
-  Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));  
+  Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));
+
+.. _sec-control-channles-phy-error-model:
 
 Control Channels PHY Error Model
 ++++++++++++++++++++++++++++++++
@@ -1986,27 +1989,11 @@ as implemented in the RRC UE entity.
 
    UE RRC State Machine
 
-It is to be noted that most of the states are transient, i.e., once
-the UE goes into one of the CONNECTED states it will never switch back
-to any of the IDLE states. This choice is done for the following reasons:
-
- - as discussed in the section :ref:`sec-design-criteria`, the focus
-   of the LTE-EPC simulation model is on CONNECTED mode
- - radio link failure is not currently modeled, as discussed in the
-   section :ref:`sec-radio-link-failure`, so an UE cannot go IDLE
-   because of radio link failure
- - RRC connection release is currently never triggered neither by the EPC
-   nor by the NAS
-
-Still, we chose to model explicitly the IDLE states, because:
-
- - a realistic UE RRC configuration is needed for handover, which is a
-   required feature, and in order to have a cleaner implementation it makes sense to
-   use the same UE RRC configuration also for the initial connection
-   establishment
- - it makes easier to implement idle mode cell selection in the
-   future, which is a highly desirable feature 
- 
+All the states are transient, however, the UE in "CONNECTED_NORMALLY" state will
+only switch to the IDLE state if the downlink SINR is below a defined threshold,
+which would lead to radio link failure :ref:`sec-radio-link-failure`.
+One the other hand, the UE would not be able switch to IDLE mode due to a handover
+failure, as mentioned in :ref:`sec-x2`.
 
 ENB RRC State Machine
 +++++++++++++++++++++
@@ -2068,7 +2055,7 @@ assumptions:
  
  - marking a cell as barred or reserved is not supported;
 
- - cell reselection is not supported, hence it is not possible for UE to camp to
+ - Idle cell reselection is not supported, hence it is not possible for UE to camp to
    a different cell after the initial camp has been placed; and
  
  - UE's Closed Subscriber Group (CSG) white list contains only one CSG identity.
@@ -2140,6 +2127,8 @@ the actual operating bandwidth of the network. SIB1 provides information
 necessary for cell selection evaluation (explained in the next section). And
 finally SIB2 is required before the UE is allowed to switch to CONNECTED state.
 
+.. _sec-cell-selection-evaluation:
+
 Cell Selection Evaluation
 -------------------------
 
@@ -2217,20 +2206,148 @@ Some implementation choices have been made in the RRC regarding the setup of rad
 
 Radio Link Failure
 ++++++++++++++++++
+In real LTE networks, Radio link failure (RLF) can happen due to several reasons.
+It can be triggered if a UE is unable to decode PDCCH due to poor signal quality,
+upon maximum RLC retransmissions, RACH problems and other reasons. 3GPP only
+specifies guidelines to detect RLF at the UE side, in [TS36331]_ and [TS36133]_.
+On the other hand, the eNB implementation is expected to be vendor specific.
+To implement the RLF functionality in ns-3, we have assumed the following
+simplifications:
 
-Since at this stage the RRC supports the CONNECTED mode only, Radio Link
-Failure (RLF) is not handled. The reason is that one of the possible
-outcomes of RLF (when RRC re-establishment is unsuccessful) is to
-leave RRC CONNECTED notifying the NAS of the RRC connection
-failure. In order to model RLF properly, RRC IDLE mode should be
-supported, including in particular idle mode cell (re-)selection.
+ * The RLF detection procedure at eNodeB is not implemented. **Instead, a direct
+   function call by using the SAP between UE and eNB RRC (for both ideal and real
+   RRC) is used to notify the eNB about the RLF**.
+ * No RRC connection re-establishment procedure is implemented, thus, the UE
+   directly goes to the IDLE state upon RLF. This is in fact as per the standard
+   [TS36331]_ sec 5.3.11.3, since, at this stage the LTE module does not support
+   the Access Stratum (AS) security.
 
-With the current model, an UE that experiences bad link quality and
-that does not perform handover (because of, e.g., no neighbor cells,
-handover disabled, handover thresholds misconfigured) will 
-just stay associated with the same eNB, and the scheduler will stop
-allocating resources to it for communications. 
+The above mentioned RLF specifications can be divided into the following two
+categories:
 
+ #. RLF detection
+ #. Actions upon RLF detection
+
+In the following, we will explain the RLF implementation in context of these
+two categories.
+
+RLF detection implementation
+----------------------------
+
+The RLF detection at the UE is implemented as per [TS36133]_, i.e., by monitoring
+the radio link quality based on the reference signals (which in the simulation
+is equivalent to the PDCCH) in the downlink. Thus, it is independent of the method
+used for the downlink CQI computation, i.e., *Ctrl* method and *Mixed method*.
+Moreover, when using FFR, especially for hard-FFR, and CQIs based on *Mixed method*,
+UEs might experience relatively good performance and RLF simultaneously. This is
+due to the fact that the interference in PDSCH is affected by the actual data
+transmissions on the specific RBs and the power control. Therefore, UEs might
+experience good SINR in PDSCH, while bad SINR in PDCCH channel. For more details
+about these methods please refer to :ref:`sec-cqi-feedback`. Also, it does not
+matter if the DL control error model is disabled, a UE can still detect the RLF
+since the SINR based on the control channel is reported to the LteUePhy class,
+using a callback hooked in LteHelper while installing a UE device.
+
+The RLF detection starts once the RRC connection is established between UE and 
+eNodeB, i.e., UE is in "CONNECTED_NORMALLY" state; upon which the RLF parameters
+are configured (see ``LteUePhy::DoConfigureRadioLinkFailureDetection``). In real
+networks, these parameters are transmitted by the eNB using IE UE-TimersAndConstants or
+RLF-TimersAndConstants. However, for the sake of simplification, in the simulator
+they are presented as the attributes of the LteUePhy and LteUeRrc classes. In
+LteUePhy class, CQI calculation is triggered for every downlink subframe received,
+and the average SINR value is measured across all resource blocks. For the RLF
+detection, these SINR values are averaged over a downlink frame and if the result
+is less than a defined threshold Qout (default: -5dB), the frame cannot be decoded
+(see``LteUePhy::RadioLinkFailureDetection``). The Qout threshold corresponds to 10%
+block error rate (BLER) of a hypothetical PDCCH transmission taking into account
+the PCFICH errors [R4-081920]_ (also refer to
+:ref:`sec-control-channles-phy-error-model`). Once, the UE is unable to decode
+20 consecutive frames, i.e., the Qout evaluation period (200ms) is reached, an
+out-of-sync indication is sent to the UE RRC layer (see ``LteUeRrc::DoNotifyOutOfSync``).
+Else, the counter for the unsuccessfully decoded frames is reset to zero. At the
+LteUeRrc, when the number of consecutive out-of-sync indications matches with the
+value of N310 parameter, the T310 timer is started and LteUePhy is notified to start
+measuring for in-sync indications (see ``LteUePhy::DoStartInSnycDetection``). We note
+that, the UE RRC state is not changed till the expiration of T310 timer. If the 
+resultant SINR values averaged over a downlink frame is greater than a defined
+threshold Qin (default: -3.8dB), the frame is considered to be successfully
+decoded. Qin corresponds to 2% BLER [R4-081920]_ of a hypothetical PDCCH transmission
+taking into account the PCFICH errors. Once the UE is able to decode 10
+consecutive frames, an in-sync indication is sent to the UE RRC layer
+(see ``LteUeRrc::DoNotifyInSync``). Else, the counter for the successfully decoded 
+frames is reset to zero. If prior to the T310 timer expiry, the number of
+consecutive in-sync indications matches with N311 parameter of LteUeRRC, the UE
+is considered back in-sync. At this stage, the related parameters are reset to
+initiate the radio link failure detection from the beginning
+(see ``LteUePhy::DoConfigureRadioLinkFailureDetection``). On the other hand, If the
+T310 timer expires, the UE considers that a RLF has occurred
+(see ``LteUeRrc::RadioLinkFailureDetected``).
+
+Actions upon RLF
+----------------
+
+Once the T310 timer is expired, a UE is considered to be in RLF; upon which the
+UE RRC:
+
+ * Sends a request to the eNB RRC to remove the UE context
+ * Moves to "CONNECTED_PHY_PROBLEM" state
+ * Notifies the UE NAS layer about the release of RRC connection.
+
+Then, after getting the notification from the UE RRC the NAS does the following:
+
+ * Delete all the TFTs
+ * Reset the bearer counter
+ * Restore the bearer list, which is used to activate the bearers for the next
+   RRC connection. This restoration of the bearers is achieved by maintaining an
+   additional list, i.e., m_bearersToBeActivatedListForReconnection in EpcUeNas
+   class
+ * Switch the NAS state to OFF by calling EpcUeNas::Disconnect
+ * Tells the UE RRC to disconnect
+
+The UE RRC, upon receiving the call to disconnect from the EpcUeNas class,
+performs the action as specified by [TS36331]_ 5.3.11.3, and finally leaves the
+connected state, i.e., its RRC state is changed from "CONNECTED_PHY_PROBLEM" to
+"IDLE_START" to perform cell selection as shown in figures :ref:`fig-lte-ue-rrc-states`
+and :ref:`fig-lte-ue-procedures-after-rlf`.
+
+At this stage, the LTE module does not support the paging functionality, therefore,
+to allow a UE to read SIB2 message after camping on a suitable cell after RLF, a
+work around is used in ``LteUeRrc::EvaluateCellForSelection`` method. As per this
+workaround, the UE RRC invokes the call to ``LteUeRrc::DoConnect`` method, which
+enables the UE to switch its state from "IDLE_CAMPED_NORMALLY" to "IDLE_WAIT_SIB2",
+thus, allowing it to perform the random access.
+
+.. _fig-lte-ue-procedures-after-rlf:
+
+.. figure:: figures/lte-ue-procedures-after-rlf.*
+   :scale: 95 %
+   :align: center
+
+   UE procedures after radio link failure
+
+The eNB RRC, after receiving the notification from the UE RRC starts the procedure
+of UE context deletion, which also involves the deletion of the UE context removal
+from the EPC :ref:`fig-lte-ue-context-removal-from-epc` and the eNB stack
+:ref:`fig-lte-ue-context-removal-from-enb-stack`. We note that, the UE context
+at the MME is not removed since, bearers are only added at the start of a
+simulation in MME, and cannot be added again unless scheduled for addition
+during a simulation.
+
+.. _fig-lte-ue-context-removal-from-epc:
+
+.. figure:: figures/lte-ue-context-removal-from-epc.*
+   :scale: 80 %
+   :align: center
+
+   UE context removal from EPC
+
+.. _fig-lte-ue-context-removal-from-enb-stack:
+
+.. figure:: figures/lte-ue-context-removal-from-enb-stack.*
+   :scale: 80 %
+   :align: center
+
+   UE context removal from eNB stack
 
 .. _sec-ue-measurements:
 
@@ -2743,8 +2860,9 @@ interaction with the other layers.
 There are several timeouts related to this procedure, which are listed in the
 following Table :ref:`tab-rrc-connection_establishment_timer`. If any of these
 timers expired, the RRC connection establishment procedure is terminated in
-failure. In this case, the upper layer (UE NAS) will immediately attempt to
-retry the procedure until it completes successfully.
+failure. At the UE side, if T300 timer has expired a consecutive
+*connEstFailCount* times on the same cell it performs the cell selection again.
+Else, the upper layer (UE NAS) will immediately attempt to retry the procedure.
 
 .. _tab-rrc-connection_establishment_timer:
 
@@ -2755,7 +2873,7 @@ retry the procedure until it completes successfully.
    |            |          | starts     | stops       | duration | expired    |
    +============+==========+============+=============+==========+============+
    | Connection | eNodeB   | New UE     | Receive RRC | 15 ms    | Remove UE  |
-   | request    | RRC      | context    | CONNECTION  |          | context    |
+   | request    | RRC      | context    | CONNECTION  | (Max)    | context    |
    | timeout    |          | added      | REQUEST     |          |            |
    +------------+----------+------------+-------------+----------+------------+
    | Connection | UE RRC   | Send RRC   | Receive RRC | 100 ms   | Reset UE   |
@@ -2774,6 +2892,27 @@ retry the procedure until it completes successfully.
    +------------+----------+------------+-------------+----------+------------+
 
 
+**Note:** The value of connection request timeout timer at the eNB RRC should 
+not be higher than the T300 timer at UE RRC. It is to make sure that the UE 
+context is already removed at the eNB, once the UE will perform cell selection
+upon reaching the *connEstFailCount* count. Moreover, at the time of writing
+this document the :ref:`sec-cell-selection-evaluation` does not include
+the :math:`Qoffset_{temp}` parameter.
+
+.. _tab-rrc-connection_establishment_counter:
+
+.. table:: Counters in RRC connection establishment procedure
+
+   +------------------+----------+------------------+-----------+------------------------------+---------------------+
+   | Name             | Location | Msg              | Monitored | limit not reached            | Limit reached       |
+   |                  |          |                  | by        |                              |                     |
+   +------------------+----------+------------------+-----------+------------------------------+---------------------+
+   | ConnEstFailCount | eNB MAC  | RachConfigCommon | UE RRC    | Increment the local counter. |                     |
+   |                  |          | in SIB2, HO REQ  |           | Invalided the prev SIB2 msg, | Reset the local     |
+   |                  |          | and HO Ack       |           | and try random access        | counter and Perform |
+   |                  |          |                  |           | with the same cell.          | cell selection.     |
+   +------------------+----------+------------------+-----------+------------------------------+---------------------+
+
 
 .. _sec-rrc-connection-reconfiguration:
 

src/lte/doc/source/lte-testing.rst

@@ -1118,7 +1118,7 @@ particular RRC message of choice during the first connection
 attempt. The error is obtained by temporarily moving the UE to a far
 away location; the time of movement has been determined empirically
 for each instance of the test case based on the message that it was
-desired to be in error.  the test case checks that at least one of the following
+desired to be in error. The test case checks that at least one of the following
 conditions is false at the time right before the UE is moved back to
 the original location:
 
@@ -1126,10 +1126,6 @@ the original location:
  - the UE context at the eNB is present
  - the RRC state of the UE Context at the eNB is CONNECTED_NORMALLY
   
-Additionally, all the conditions of the
-``LteRrcConnectionEstablishmentTestCase`` are evaluated - they are
-espected to be true because of the NAS behavior of immediately
-re-attempting the connection establishment if it fails.
  
 
 Initial cell selection
@@ -1626,3 +1622,79 @@ simulation scenario can be configured with different EARFCNs and Bandwidths. For
 the number of times the hooked trace source ``SCarrierConfigured`` get triggered. As, it reflects how many UEs 
 got attached to their respective eNB. If the count is not equal to the number of UEs in the scenario, the test fails, 
 which could be the result of improper UE configuration.
+
+
+Radio link failure Test
+-----------------------
+
+The test suite ``lte-radio-link-failure`` is a system test, which tests the
+radio link failure functionality using Ideal and Real RRC protocols.
+In particular, it tests the following to verify the Radio link
+Failure (RLF) implementation. 
+
+ #. The state and the configuration of the UE while it is connected to the eNB.
+ #. The state of the UE while T310 timer is running at the UE.
+ #. The number of out-of-sync and in-synch indications received.
+ #. The state of the UE before the simulation end.
+ #. The UE context existence at the eNB before the simulation end.
+
+This test simulates only one static UE with EPC performing downlink and uplink
+communication in the following two scenarios: 
+
+One eNB using Ideal and Real RRC
+################################
+
+
+.. _fig-lte-test-rlf-one-enb:
+
+.. figure:: figures/lte-test-rlf-one-enb.*
+   :align: center
+
+   RLF scenario with one eNB
+
+In this scenario, the UE is initially placed near to the eNB, and on the
+following instances above conditions are verified against the expected outcome.
+
+**At 0.3 sec:**  It verifies that the UE is well connected, i.e., it is in
+"CONNECTED_NORMALLY" state, and is attached to the eNB with cell id 1. It also
+checks for the match between the configuration of the UE and the UE context at
+the eNB, e.g., IMSI, bandwidth, D/UL EARFCN, number of bearers and the bearer IDs.
+The miss match would result in the test suite failure.
+
+**At 0.4 sec:** The UE jumps far away from the eNB, which causes the DL SINR at
+the UE to fall below -5 dB. In result, the UE PHY after monitoring the SINR for
+20 consecutive frames will send a notification to the UE RRC. In this test, the
+N310 counter is set to 1; thus, the UE RRC will start the T310 (set to 1 sec)
+timer upon the first notification from the PHY layer.  
+
+**At 1 sec:** At this stage, it is expected that the T310 timer is still running,
+and the UE is connected to the eNB. 
+
+**Upon RLF:** It is expected that the UE RRC will start the T310 timer upon reaching
+the configured, i.e., N310 = 1 number of notification from the eNB. The RRC will
+receive no in-sync indication since the UE stays at far away position.
+
+**Before the end of simulation:**  The expected behavior is that the UE state
+will be in "IDLE_CELL_SEARCH" since there is no eNB available where it has jumped.
+Moreover, the deletion of the UE context from the eNB is also verified.
+
+Two eNBs using Ideal and Real RRC
+#################################
+
+
+.. _fig-lte-test-rlf-two-enb:
+
+.. figure:: figures/lte-test-rlf-two-enb.*
+   :align: center
+
+   RLF scenario with two eNBs
+
+In this scenario, the only difference is the addition of a second eNB near the
+position where the UE jumps away. Therefore, except the outcome before the end 
+of the simulation, all the outcomes are similar to that we expected in the first
+scenario.  
+
+**Before the end of simulation:**  It is expected that the UE after the RLF will
+connect to the second eNB, i.e., it will be in "CONNECTED_NORMALLY" state, and
+its context exists in the second eNB.
+

src/lte/doc/source/lte-user.rst

@@ -427,6 +427,10 @@ And finally, in UL and DL reception files the parameters included are:
   10. New Data Indicator flag
   11. Correctness in the reception of the TB
 
+**Note:** The traces generated by simulating the scenarios involving the RLF
+will have a discontinuity in time from the moment of the RLF event until the UE
+connects again to an eNB.    
+
 
 Fading Trace Usage
 ------------------
@@ -2410,6 +2414,130 @@ figures are generated. An example to run this test suite is shown in figures:
    Example of CA test performance in the downlink 
 
 
+Radio link failure example
+--------------------------
+
+The example *lena-radio-link-failure.cc* is an example to simulate the RLF
+functionality. In particular, it simulates only one moving UE using *Ideal* or *Real*
+RRC protocol with EPC performing downlink and uplink communication in two
+scenarios shown in :ref:`lena-radio-link-failure-one-enb` and
+:ref:`lena-radio-link-failure-two-enb`
+
+.. _lena-radio-link-failure-one-enb:
+
+.. figure:: figures/lena-radio-link-failure-one-enb.*
+   :align: center
+   
+   Scenario A: Radio link failure example with one eNB
+
+We note that, the RLF detection is enabled by default, which can be disabled by
+configuring the ``LteUePhy::EnableRlfDetection`` to false, e.g.,::
+
+ Config::SetDefault ("ns3::LteUePhy::EnableRlfDetection", BooleanValue (false));
+
+In this example, to study the impact of a RLF on the user's quality of experience,
+we compute an instantaneous (i.e., every 200 ms) DL throughput of the UE, and
+writes it into a file for plotting purposes. For example, to simulate the "Scenario
+A" with *Ideal* and *Real* RRC protocol a user can use the following commands::
+
+  Ideal RRC:
+  ./waf --run "lena-radio-link-failure 
+  --numberOfEnbs=1 --useIdealRrc=1 
+  --interSiteDistance=1200 --n310=1 --n311=1 
+  --t310=1 --enableCtrlErrorModel=1 
+  --enableDataErrorModel=1 --simTime=25"
+
+  Real RRC:
+  ./waf --run "lena-radio-link-failure 
+  --numberOfEnbs=1 --useIdealRrc=0 
+  --interSiteDistance=1200 --n310=1 --n311=1 
+  --t310=1 --enableCtrlErrorModel=1 
+  --enableDataErrorModel=1 --simTime=25"
+
+After running the above two commands, we can use a simple gnuplot script to plot
+the throughput as shown in the Figure :ref:`fig-lena-radio-link-failure-one-enb-thrput`
+, e.g., ::
+
+ set terminal png
+ set output  "lena-radio-link-failure-one-enb-thrput.png"
+ set multiplot
+ set xlabel "Time [s]"
+ set ylabel "Instantaneous throughput UE [Mbps]"
+ set grid
+ set title "LTE RLF example 1 eNB DL instantaneous throughput"
+ plot "rlf_dl_thrput_1_eNB_ideal_rrc" using ($1):($2) with linespoints
+ title 'Ideal RRC' linestyle 1 lw 2 lc rgb 'blue', "rlf_dl_thrput_1_eNB_real_rrc"
+ using ($1):($2) with linespoints title 'Real RRC' linestyle 2 lw 2 lc rgb 'red'
+
+ unset multiplot
+
+.. _fig-lena-radio-link-failure-one-enb-thrput:
+
+.. figure:: figures/lena-radio-link-failure-one-enb-thrput.png
+   :align: center
+   
+   Downlink instantaneous throughput of UE in scenario A
+
+In this scenario, when using the *Ideal* RRC the UE after the RLF will connect
+and disconnect from the eNB several times. This is because it can
+synchronize (i.e., start reading system information) with an eNB at a low
+RSRP level, which is default to -140 dBm (see QRxLevMin attribute of eNB RRC).
+It enables the UE to start the random access procedure with the eNB. With the 
+*Ideal* RRC, the UE can complete the random access without any errors, since
+all the RRC messages are exchanged ideally between the eNB and the UE.
+However, soon after the connection establishment, it ends up in RLF due to the
+poor channel quality. On the other hand, with the *Real* RRC the UE after the RLF
+will not be able to complete the random access procedure due to the poor channel
+conditions, thus, will not be able to establish the connection with the eNB.
+Therefore, in both the cases the UE throughput drops to zero as shown in the
+Figure :ref:`fig-lena-radio-link-failure-one-enb-thrput`.
+
+
+.. _lena-radio-link-failure-two-enb:
+
+.. figure:: figures/lena-radio-link-failure-two-enb.*
+   :align: center
+   
+   Scenario B: Radio link failure example with two eNBs
+
+Similarly, to simulate the "Scenario B" with *Ideal* and *Real* RRC protocol
+following commands can be used::
+
+  Ideal RRC:
+  ./waf --run "lena-radio-link-failure 
+  --numberOfEnbs=2 --useIdealRrc=1 
+  --interSiteDistance=1200 --n310=1 --n311=1 
+  --t310=1 --enableCtrlErrorModel=1 
+  --enableDataErrorModel=1 --simTime=25"
+
+  Real RRC:
+  ./waf --run "lena-radio-link-failure 
+  --numberOfEnbs=2 --useIdealRrc=0 
+  --interSiteDistance=1200 --n310=1 --n311=1 
+  --t310=1 --enableCtrlErrorModel=1 
+  --enableDataErrorModel=1 --simTime=25"
+
+Figure :ref:`fig-lena-radio-link-failure-two-enb-thrput`, shows the throughput
+in "Scenario B". We note that in this scenario the handover algorithm is not used.
+As expected, with *Ideal* RRC protocol the UE after the RLF can complete
+the random access procedure with the second eNB. Interestingly, the DL SINR after
+the connection establishment is not low enough to trigger the RLF, but it is
+low enough to impact the DL control reception for some TBs, which in turn causes
+loss of data. It can be observed from the slightly unstable throughput of the UE
+after connecting to the second eNB. On the other hand, with *Real* RRC the UE faces
+problems in connection establishment phase due to the loss of RRC messages, in
+particular, the RRC connection request from the UE. This is the reason why the
+UE throughput after the RLF remains zero for a more extended period as compared
+to the *ideal* RRC protocol.  
+
+.. _fig-lena-radio-link-failure-two-enb-thrput:
+
+.. figure:: figures/lena-radio-link-failure-two-enb-thrput.png
+   :align: center
+   
+   Downlink instantaneous throughput of UE in scenario B
+
+
 
 Troubleshooting and debugging tips
 ---------------------------------------------------
@@ -2429,7 +2557,7 @@ output is as expected. In detail:
 
  * then check packet transmissions on the data plane, starting by
    enabling the log components LteUeNetDevice and the
-   EpcSgwPgwApplication, then EpcEnbApplication, then moving down the
+   EpcSgwApplication, EpcPgwApplication and EpcEnbApplication, then moving down the
    LTE radio stack (PDCP, RLC, MAC, and finally PHY). All this until
    you find where packets stop being processed / forwarded.