From 7f812323095f7a2b6310dd8788d145465bbbb64c Mon Sep 17 00:00:00 2001 From: Budiarto Herman Date: Tue, 2 Jul 2013 10:23:16 +0300 Subject: [PATCH] Preliminary design and user documentation of LTE initial cell selection --- src/lte/doc/source/lte-design.rst | 85 +++++++++++++++++++++++- src/lte/doc/source/lte-user.rst | 106 ++++++++++++++++++++++++++++++ 2 files changed, 190 insertions(+), 1 deletion(-) diff --git a/src/lte/doc/source/lte-design.rst b/src/lte/doc/source/lte-design.rst index 895683bbc..22027caf7 100644 --- a/src/lte/doc/source/lte-design.rst +++ b/src/lte/doc/source/lte-design.rst @@ -1857,11 +1857,13 @@ The RRC model implemented in the simulator provides the following functionality: - generation (at the eNB) and interpretation (at the UE) of System Information (in particular the Master Information Block and, at the - time of this writing, only System Information Block Type 2) + time of this writing, only System Information Block Type 1 and 2) + - initial cell selection - RRC connection establishment procedure - RRC reconfiguration procedure, supporting the following use cases: + reconfiguration of the SRS configuration index + reconfiguration of the PHY TX mode (MIMO) + + reconfiguration of UE measurements + data radio bearer setup + handover - RRC connection re-establishment, supporting the following use @@ -1943,6 +1945,87 @@ represented in Figure :ref:`fig-lte-enb-rrc-states`. ENB RRC State Machine for each UE +Broadcast of System Information ++++++++++++++++++++++++++++++++ + +System information blocks are broadcasted by eNodeB to all attached UEs at +predefined time intervals. The supported system information blocks are: + + - Master Information Block (MIB) + Contains parameters related to the PHY layer, generated during cell + configuration and broadcasted every 10 ms (but 40 ms in Section 5.2.1.2 of + [TS36331]_) as a control message. + + - System Information Block Type 1 (SIB1) + Contains information regarding network access, broadcasted every 80 ms + via RRC protocol. + + - System Information Block Type 2 (SIB2) + Contains UL- and RACH-related settings, scheduled to transmit via RRC + protocol at 16 ms after cell configuration, and then repeats every 80 ms. + +Reception of system information is detrimental to the transition of UE RRC +state. SIB1 is necessary for switching from `IDLE_CELL_SELECTION` to +`IDLE_WAIT_SYSTEM_INFO`. After that, MIB and SIB2 are required to switch to +`IDLE_CAMPED_NORMALLY`. + + +.. _sec-initial-cell-selection: + +Initial Cell Selection +++++++++++++++++++++++ + +UE in `IDLE_CELL_SELECTION` state, e.g. in the beginning of simulation, will +actively seek a suitable cell to attach to. + +UE will perform the selection among the surrounding eNodeBs based on several +criteria: + + - Rx level criterion; + + - quality criterion; + + - public land mobile network (PLMN), a.k.a. the network operator; and + + - closed subscriber group (CSG). + +The first pair of criteria, Rx level and quality, are based on measured cell +RSRP :math:`Q_{rxlevmeas}` and RSRQ :math:`Q_{qualmeas}`, respectively. These +measurements are collected by the PHY layer, as described in +:ref:`phy-ue-measurements`. In order to pass the criteria, both values must be +higher than required minimum RSRP and RSRQ, which can also be expressed as +below: + +.. math:: + + Q_{rxlevmeas} - Q_{rxlevmin} > 0 + +.. math:: + + Q_{qualmeas} - Q_{qualmin} > 0 + +where :math:`Q_{rxlevmin}` and :math:`Q_{qualmin}` are determined by each +eNodeB, and are obtainable by UE from SIB1. + +The last pair of criteria, PLMN and CSG, are simple numbers associated with each +eNodeB and UE. When these information are set to values beside their default +values, for example to simulate an environment with multiple network operators, +UE will restrict its cell selection attempts to target only eNodeBs with the +same PLMN ID and CSG ID. The default value of zero disables these criteria. +Section :ref:`sec-network-attachment` of user documentation provides more +details on multi-operator simulation. + +When at least one suitable cells are found, the UE will choose the strongest one +(based on RSRP) and connect to it. This is done by issuing a contention-based +random access, followed by `RRCConnectionRequest`, thereby promptly switching +from IDLE mode to CONNECTED mode. Hence, `cell reselection` procedure is *not* +supported in this version of LTE module. (What happen if the eNodeB rejects the +connection request?) + +On the other hand, when no suitable cell is found, the UE will stay in +`IDLE_CELL_SELECTION` state, and repeat the cell selection attempt again when +PHY layer provides another set of measurements. + Radio Admission Control +++++++++++++++++++++++ diff --git a/src/lte/doc/source/lte-user.rst b/src/lte/doc/source/lte-user.rst index 5a06b80db..74066b679 100644 --- a/src/lte/doc/source/lte-user.rst +++ b/src/lte/doc/source/lte-user.rst @@ -39,6 +39,8 @@ of practical examples. +.. _sec-basic-simulation-program: + Basic simulation program ------------------------ @@ -912,6 +914,110 @@ That's all! You can now start your simulation as usual:: +.. _sec-network-attachment: + +Network Attachment +------------------ + +As shown in the example in section :ref:`sec-basic-simulation-program`, +attaching a UE to an eNodeB is done by calling ``LteHelper::Attach`` function. +There are other methods of attachment as well, and this section will go through +each of them. + +Manual attachment +***************** + +This method uses the ``LteHelper::Attach`` function mentioned above, which had +been the only available method in earlier versions of LTE module. It is +typically invoked before the simulation begins:: + + lteHelper->Attach (ueDevs, enbDev); // attach one or more UEs to a single eNodeB + +``LteHelper::InstallEnbDevice`` and ``LteHelper::InstallUeDevice`` functions +must have been called before attaching. In an EPC-enabled simulation, it is also +required to have IPv4 properly pre-installed in the UE. + +This method is very simple, but requires you to know exactly which UE belongs to +to which eNodeB before the simulation begins. This can be difficult when the UE +initial position is randomly determined by the simulation script. + +In real life, UE will automatically evaluate certain criteria and select the +best cell to attach to, without manual intervention from the user. Obviously +this is not the case in this ``LteHelper::Attach`` function. The other network +attachment methods use more `automatic` approach to network attachment, as will +be described next. + +Attachment based on distance +**************************** + +Normally, UE aims to attach to the cell with the best received signal level +(i.e. the `strongest cell`). In order to determine the strongest cell, the +distance between the UE and the eNodeB may be used as a simple (at least from +simulator point of view) and sometimes practical indicator. + +The ``LteHelper::AttachToClosestEnb`` function exists for this purpose. It takes +a ``NetDeviceContainer`` of UEs and another ``NetDeviceContainer`` of eNodeB, +and invokes an ``LteHelper::Attach`` to each UE and its closest eNodeB. + +Note that this function does *not* take into account the direction and beamwidth +of the eNodeB receiver antenna. This can be problematic in scenarios such as +three-sectorized cells, where multiple eNodeBs must share the same exact +location. + +One trick to mitigate this issue in a three-sectorized cell is to use the +``LteHexGridEnbTopologyHelper`` helper class to setup the eNodeB position and +antenna direction. Each eNodeB within the same site will be positioned a bit +away from the center of the site by a very small offset. This offset is by +default 50 cm, but can be configured by the `SectorOffset` attribute. This small +nudge will slightly vary the distance between the eNodeBs and the UE, making the +eNodeB with the right antenna direction more favorable for +``LteHelper::AttachToClosestEnb`` function. + +These functions are invoked before simulation begins, as shown in the example +below (adapted from ``src/lte/examples/lena-dual-stripe.cc`` example):: + + Ptr topologyHelper = CreateObject (); + topologyHelper->SetAttribute ("InterSiteDistance", DoubleValue (500)); + topologyHelper->SetAttribute ("SectorOffset", DoubleValue (0.5)); + topologyHelper->SetAttribute ("SiteHeight", DoubleValue (30)); + topologyHelper->SetAttribute ("MinX", DoubleValue (0)); + topologyHelper->SetAttribute ("MinY", DoubleValue (0)); + topologyHelper->SetAttribute ("GridWidth", UintegerValue (1)); + topologyHelper->SetLteHelper (lteHelper); + NetDeviceContainer enbDevs = topologyHelper->SetPositionAndInstallEnbDevice (enbNodes); + + lteHelper->SetEnbAntennaModelType ("ns3::ParabolicAntennaModel"); + lteHelper->SetEnbAntennaModelAttribute ("Beamwidth", DoubleValue (70)); + lteHelper->AttachToClosestEnb (ueDevs, enbDevs); + +Attachment based on received signal +*********************************** + +Sometimes distance does not make a correct criterion for determining the +strongest cell, for instance when the channel condition is fluctuating +because of the addition of fading or shadowing. In these kind of cases, +network attachment should be based on the received signal. + +Such method in the current LTE module is implemented in the `initial cell +selection` process. It is automatically triggered by the UE when the previously +described network attachment methods are not invoked. + +In more details, it works as follow. When a UE starts the simulation without +being attached to any eNodeB, it will spend some time to measure the signal +strength of the surrounding cells, choose the one with the strongest RSRP, and +then attempt to attach to it. + +Even more details can be found in section :ref:`sec-initial-cell-selection` of +design documentation. + +Multi-operator environment +************************** + +An interesting use case of the initial cell selection process is to setup a +simulation environment with multiple network operators. (To be added later). + + + .. _sec-configure-ue-measurements: Configure UE measurements