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

Updated UE measurements and initial cell selection documentation

Browse Source
This commit is contained in:
Budiarto Herman
2013-07-28 08:17:35 +03:00
parent b4c068cfbb
commit 697755b1fe
8 changed files with 219 additions and 127 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/models/Makefile
View File

@@ -181,8 +181,10 @@ SOURCEFIGS = \
$(SRC)/lte/doc/source/figures/nas-attach.pdf \
$(SRC)/lte/doc/source/figures/lte-enb-rrc-states.png \
$(SRC)/lte/doc/source/figures/lte-ue-rrc-states.png \
$(SRC)/lte/doc/source/figures/lte-handover-algorithm.png \
$(SRC)/lte/doc/source/figures/lte-enb-rrc-states.pdf \
$(SRC)/lte/doc/source/figures/lte-ue-rrc-states.pdf \
$(SRC)/lte/doc/source/figures/lte-handover-algorithm.pdf \
$(SRC)/uan/doc/auvmobility-classes.dia \
$(SRC)/stats/doc/Stat-framework-arch.png \
$(SRC)/stats/doc/Wifi-default.png \

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

@@ -1,23 +1,25 @@
digraph LteRrcStates {
IDLE_CELL_SELECTION [shape="box",width=5]
IDLE_WAIT_SYSTEM_INFO [shape="box",width=5]
IDLE_CAMPED_NORMALLY [shape="box",width=5]
IDLE_RANDOM_ACCESS [shape="box",width=5]
IDLE_CONNECTING [shape="box",width=5]
CONNECTED_NORMALLY [shape="box",width=5]
CONNECTED_HANDOVER [shape="box",width=5]
IDLE_CELL_SELECTION [shape="box",width=4]
IDLE_WAIT_SYSTEM_INFO [shape="box",width=4]
IDLE_CAMPED_NORMALLY [shape="box",width=4]
IDLE_RANDOM_ACCESS [shape="box",width=4]
IDLE_CONNECTING [shape="box",width=4]
CONNECTED_NORMALLY [shape="box",width=4]
CONNECTED_HANDOVER [shape="box",width=4]
IDLE_CELL_SELECTION -> IDLE_WAIT_SYSTEM_INFO [label="eNB CellId enforced by upper layers"]
IDLE_CELL_SELECTION -> IDLE_WAIT_SYSTEM_INFO [label="cell ID enforced\nby upper layers"]
IDLE_CELL_SELECTION -> IDLE_CAMPED_NORMALLY [label="cell selection\nsuccessful"]
IDLE_WAIT_SYSTEM_INFO -> IDLE_CAMPED_NORMALLY [label="rx MIB + SIB2"]
IDLE_CAMPED_NORMALLY -> IDLE_RANDOM_ACCESS [label="connection request by upper layers"]
IDLE_RANDOM_ACCESS -> IDLE_CONNECTING [label="random access successful"]
IDLE_RANDOM_ACCESS -> IDLE_CAMPED_NORMALLY [label="random access failure"]
IDLE_CAMPED_NORMALLY -> IDLE_RANDOM_ACCESS [label="connection request\nby upper layers"]
IDLE_RANDOM_ACCESS -> IDLE_CONNECTING [label="random access\nsuccessful"]
IDLE_RANDOM_ACCESS -> IDLE_CAMPED_NORMALLY [label="random access\nfailure",
style=dashed] // dashed because this has not been implemented yet
IDLE_CONNECTING -> CONNECTED_NORMALLY [label="rx RRC CONN SETUP"]
IDLE_CONNECTING -> IDLE_CAMPED_NORMALLY [label="rx RRC CONN REJECT"]
CONNECTED_NORMALLY -> CONNECTED_HANDOVER [label="rx RRC CONN RECONF with MobilityCltrInfo"]
CONNECTED_HANDOVER -> CONNECTED_NORMALLY [label="random access successful"]
IDLE_CONNECTING -> IDLE_CAMPED_NORMALLY [label="rx RRC CONN\nREJECT"]
CONNECTED_NORMALLY -> CONNECTED_HANDOVER [label="rx RRC CONN RECONF\nwith MobilityCtrlInfo"]
CONNECTED_HANDOVER -> CONNECTED_NORMALLY [label="random access\nsuccessful"]
}

BIN
src/lte/doc/source/figures/lte-ue-rrc-states.pdf
View File

Binary file not shown.

BIN
src/lte/doc/source/figures/lte-ue-rrc-states.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 55 KiB

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

@@ -1267,6 +1267,8 @@ The scheduler implements the filtering of the uplink CQIs according to their nat
- ``ALL_UL_CQI``: all CQIs are stored in the same internal attibute (i.e., the last CQI received is stored independently from its nature).
.. _sec-random-access:
Random Access
+++++++++++++
@@ -1948,6 +1950,40 @@ represented in Figure :ref:`fig-lte-enb-rrc-states`.
ENB RRC State Machine for each UE
.. _sec-cell-search:
Cell Search
+++++++++++
Cell search is one of the first steps performed by every UE in the beginning of
simulation, particularly when the UE has not yet camped or attached to an
eNodeB. The objective of the procedure is to detect surrounding cells and
measure the strength of received signal from each of these cells. One of these
cells will become the UE's entry point to join the cellular network.
The measurements are based on the RSRP of the received PSS, averaged by Layer 1
filtering, and performed by the PHY layer. This is described in more detail in
section :ref:`phy-ue-measurements`. PSS is transmitted by eNodeB over the
central 72 sub-carriers of the DL channel (Section 5.1.7.3 [TS36300]_), hence
we model cell search to operate using a DL bandwidth of 6 RBs. Note that
measurements of RSRQ are not available at this point of time in simulation. As
a consequence, the ``LteUePhy::RsrqUeMeasThreshold`` attribute does not apply
during cell search.
Using the measured RSRP, the PHY entity is able to generate a list of detected
cells, each with its corresponding cell ID and averaged RSRP. This list is
periodically pushed via CPHY SAP to the RRC entity as a measurement report.
The RRC entity inspects the report and simply choose the cell with the strongest
RSRP, as also indicated in Section 5.2.3.1 of [TS36304]_. Then it instructs the
PHY entity to synchronize to this particular cell. The actual operating
bandwidth of the cell is still unknown at this time, so the PHY entity listens
only to the minimum bandwidth of 6 RBs. Nevertheless the PHY entity will be
able to receive system broadcast message from this particular eNodeB, which is
the topic of the next section.
Broadcast of System Information
+++++++++++++++++++++++++++++++
@@ -1966,10 +2002,11 @@ intervals. The supported system information blocks are:
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`.
Reception of system information is detrimental to a UE in order to advance in
its lifecycle. MIB enables the UE to increase the initial DL bandwidth of 6 RBs
to the actual operating bandwidth of the network. SIB1 provides information
necessary for initial cell selection procedure (explained in the next section).
And finally SIB2 is necessary before the UE can switch to CONNECTED state.
.. _sec-initial-cell-selection:
@@ -1977,59 +2014,72 @@ state. SIB1 is necessary for switching from `IDLE_CELL_SELECTION` to
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.
Performed by UE RRC, the initial cell selection procedure reviews the
measurement report produced in :ref:`sec-cell-search` and the cell access
information provided by SIB1. Once both information is available for a specific
cell, the UE triggers the evaluation process. The purpose of this process is to
determine if the cell is a suitable cell to camp to.
UE will perform the selection among the surrounding eNodeBs based on several
criteria:
The evaluation process is a slightly simplified version of Section 5.2.3.2 of
[TS36304]_. It consists of the following 3 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:
The first criterion, Rx level, is based on the cell's measured RSRP
:math:`Q_{rxlevmeas}`, which has to be higher than the required minimum in order
to pass the criterion:
.. 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.
where :math:`Q_{rxlevmin}` is determined by each eNodeB and is 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. Only
eNodeB and UE. The basic rule is that UE will not camp to eNodeBs with different
PLMN ID and/or CSG ID. The default value of zero disables these criteria. Only
at most one PLMN ID and one CSG ID can be associated to each eNodeB or UE.
Section :ref:`sec-network-attachment` of user documentation provides more
details on multi-operator simulation.
details on this.
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.
When the cell passes all the above criteria, then the cell is deemed as
*suitable*. Next, UE camps to it, switching its RRC state to
`IDLE_CAMPED_NORMALLY`. After this, the UE may request to enter CONNECTED mode,
which can be done by calling ``LteHelper::Connect`` function; please refer to
section :ref:`sec-rrc-connection-establishment` for details on this.
On the other hand, when no suitable cell is found, or when the selected cell
rejects the connection request, then the UE will stop the attempt and stay in
`IDLE_CELL_SELECTION` state until the end of the simulation. In real LTE system,
the UE would enter "any cell selection" state, camp to any cell, and then
perform cell reselection. But these are not modeled in this version of LTE
module.
On the other hand, when the cell does not pass either the PLMN or CSG criteria,
then the cell is labeled as *acceptable* (Section 10.1.1.1 [TS36300]_). In this
case, the RRC entity will tell the PHY entity to synchronize to a different
cell. As long as no suitable cell is found, the UE will repeat these steps while
avoiding cells that have been identified as acceptable.
The above behaviour is based on the following simplifying assumptions:
- multiple carrier frequency is not supported;
- as mentioned in section :ref:`sec-cell-search`, RSRQ is not available during
cell search;
- stored information cell selection is not supported;
- "Any Cell Selection" state and camping to an acceptable cell is not
supported;
- marking a cell as barred or reserved is not supported; and
- 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.
Also note that both cell search and initial cell selection are only available
for EPC-enabled simulation. EPC-only simulation must use the manual attachment
method. See section :ref:`sec-network-attachment` of user documentation for more
information on their difference in usage.
Radio Admission Control
@@ -2097,6 +2147,8 @@ following simplifying assumptions:
- only `reportStrongestCells` purpose is supported, while `reportCGI` and
`reportStrongestCellsForSON` purposes are not supported;
- `s-Measure` is not supported;
- since carrier aggregation is not supported in general, the following
assumptions in UE measurements hold true:
@@ -2104,7 +2156,8 @@ following simplifying assumptions:
- primary cell (`PCell`) simply means serving cell;
- Event A6 is not implemented;
- `s-Measure` and `SpeedStatePars` are not supported;
- speed dependant scaling of time-to-trigger (Section 5.5.6.2 of [TS36331]_) is
not supported.
Overall design
--------------
@@ -2140,11 +2193,10 @@ The following sections will describe each of the parts above.
Measurement configuration
-------------------------
The eNodeB RRC entity configures the UE measurements by sending the
configuration parameters to the UE RRC entity within the ``MeasConfig`` IE of
the RRC Connection Reconfiguration message. This message occurs when the UE
attaches to the eNodeB or during the RRC Handover Request message when the
target eNodeB initiates the handover procedure.
An eNodeB RRC entity configures UE measurements by sending the configuration
parameters to the UE RRC entity. This set of parameters are defined within the
``MeasConfig`` Information Element (IE) of the RRC Connection Reconfiguration
message (:ref:`sec-rrc-connection-reconfiguration`).
The eNodeB RRC entity implements the configuration parameters and procedures
described in Section 5.5.2 of [TS36331]_, with the following simplifying
@@ -2158,7 +2210,7 @@ assumption:
modeling assumptions described in :ref:`phy-ue-measurements`.
The eNodeB RRC instance here acts as an intermediary between the consumers and
the attached UEs. At the beginning of simulation, each consumer provide the
the attached UEs. At the beginning of simulation, each consumer provides the
eNodeB RRC instance with the UE measurements configuration that it requires.
After that, the eNodeB RRC distributes the configuration to attached UEs.
@@ -2171,10 +2223,10 @@ details are explained in user documentation
Performing measurements
-----------------------
UE RRC receives measurements on periodic basis from UE PHY, as described in
:ref:`phy-ue-measurements`. *Layer 3 filtering* will be applied to these
received measurements. The implementation of the filtering follows Section
5.5.3.2 of [TS36331]_:
UE RRC receives both RSRP and RSRQ measurements on periodical basis from UE PHY,
as described in :ref:`phy-ue-measurements`. *Layer 3 filtering* will be applied
to these received measurements. The implementation of the filtering follows
Section 5.5.3.2 of [TS36331]_:
.. math::
@@ -2194,17 +2246,21 @@ where:
`RsrpFilterCoefficient` and `RsrqFilterCoefficient` attributes in
``LteEnbRrc``.
Therefore :math:`k = 0` will disable Layer 3 filtering, i.e. the maximum
forgetting factor. On the other hand, past measurements can be granted more
influence on the filtering results by using larger value of :math:`k`.
Measurement reporting triggering
--------------------------------
This part will go through the list of active measurement configuration and check
whether the triggering condition is fulfilled in accordance with Section 5.5.4
of [TS36331]_. When at least one triggering condition from all the active
measurement configuration is fulfilled, the measurement reporting procedure (in
the next subsection) will be initiated.
In this part, UE RRC will go through the list of active measurement
configuration and check whether the triggering condition is fulfilled in
accordance with Section 5.5.4 of [TS36331]_. When at least one triggering
condition from all the active measurement configuration is fulfilled, the
measurement reporting procedure (in the next subsection) will be initiated.
3GPP defines two kinds of `triggerType`: periodical and event-based. At the
moment, only *event-based* criterion is supported. There are various events that
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
@@ -2221,29 +2277,30 @@ can be selected, which are briefly described in the table below:
======== ======================================================
Two main conditions to be checked in an event-based trigger are *entering
condition* and *leaving condition*. More details can be found in Section 5.5.4
of [TS36331]_.
condition* and *leaving condition*. More details on these two can be found in
Section 5.5.4 of [TS36331]_.
Event-based trigger can be further configured by introducing hysteresis and
time-to-trigger. *Hysteresis* (:math:`Hys`) defines the distance between the
entering and leaving conditions in dB. Similarly, *time-to-trigger* introduces
delay to both entering and leaving conditions, but as a unit of time.
delay to both entering and leaving conditions, but as a unit of time. Section
*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 reports will be regularly triggered at every
certain interval, as determined by the `reportInterval` field within
As a result, the measurement reports will always be 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
supported. Moreover, cell-specific offsets (i.e. :math:`O_{cn}` and
:math:`O_{cp}` in Event A3, A4, and A5) are not supported as well. The value
equal to zero is always assumed in place of them.
In contrast with 3GPP standard, the current model does not support any
cell-specific configuration. These configuration parameters are defined in
measurement object. As a consequence, incorporating a list of black cells into
the triggering process is not supported. Moreover, cell-specific offset
(i.e. :math:`O_{cn}` and :math:`O_{cp}` in Event A3, A4, and A5) are not
supported as well. The value equal to zero is always assumed in place of them.
Measurement reporting
---------------------
@@ -2319,6 +2376,8 @@ RRC sequence diagrams
In this section we provide some sequence diagrams that explain the
most important RRC procedures being modeled.
.. _sec-rrc-connection-establishment:
RRC connection establishment
----------------------------
@@ -2336,6 +2395,8 @@ interaction with the other layers.
.. _sec-rrc-connection-reconfiguration:
RRC connection reconfiguration
------------------------------

4
src/lte/doc/source/lte-references.rst
View File

@@ -20,11 +20,11 @@ References
.. [TS36213] 3GPP TS 36.213 "E-UTRA Physical layer procedures"
.. [TS36214] 3GPP TS 36.213 "E-UTRA Physical layer – Measurements"
.. [TS36214] 3GPP TS 36.214 "E-UTRA Physical layer – Measurements"
.. [TS36300] 3GPP TS 36.300 "E-UTRA and E-UTRAN; Overall description; Stage 2"
.. [TS36304] 3GPP TS 36.104 "E-UTRA User Equipment (UE) procedures in idle mode"
.. [TS36304] 3GPP TS 36.304 "E-UTRA User Equipment (UE) procedures in idle mode"
.. [TS36321] 3GPP TS 36.321 "E-UTRA Medium Access Control (MAC) protocol specification"

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

@@ -346,34 +346,36 @@ Piecewise test #2.
====== ================== ================ ========== ===============
1 Event A1 Low No No
2 Event A1 Normal No No
3 Event A1 High No No
4 Event A2 Low No No
5 Event A2 Normal No No
6 Event A2 High No No
7 Event A3 Positive No No
8 Event A3 Zero No No
9 Event A3 Zero No Short
10 Event A3 Zero No Super
11 Event A3 Zero Yes No
12 Event A3 Negative No No
13 Event A4 Low No No
14 Event A4 Normal No No
15 Event A4 Normal No Short
16 Event A4 Normal No Super
17 Event A4 Normal Yes No
18 Event A4 High No No
19 Event A5 Low-Low No No
20 Event A5 Low-Normal No No
21 Event A5 Low-High No No
22 Event A5 Normal-Low No No
23 Event A5 Normal-Normal No No
24 Event A5 Normal-Normal No Short
25 Event A5 Normal-Normal No Super
26 Event A5 Normal-Normal Yes No
27 Event A5 Normal-High No No
28 Event A5 High-Low No No
29 Event A5 High-Normal No No
30 Event A5 High-High No No
3 Event A1 Normal Yes No
4 Event A1 High No No
5 Event A2 Low No No
6 Event A2 Normal No No
7 Event A2 Normal Yes No
8 Event A2 High No No
9 Event A3 Positive No No
10 Event A3 Zero No No
11 Event A3 Zero No Short
12 Event A3 Zero No Super
13 Event A3 Zero Yes No
14 Event A3 Negative No No
15 Event A4 Low No No
16 Event A4 Normal No No
17 Event A4 Normal No Short
18 Event A4 Normal No Super
19 Event A4 Normal Yes No
20 Event A4 High No No
21 Event A5 Low-Low No No
22 Event A5 Low-Normal No No
23 Event A5 Low-High No No
24 Event A5 Normal-Low No No
25 Event A5 Normal-Normal No No
26 Event A5 Normal-Normal No Short
27 Event A5 Normal-Normal No Super
28 Event A5 Normal-Normal Yes No
29 Event A5 Normal-High No No
30 Event A5 High-Low No No
31 Event A5 High-Normal No No
32 Event A5 High-High No No
====== ================== ================ ========== ===============
One note about the tests with time-to-trigger, they are tested using 3 different

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

@@ -919,17 +919,20 @@ That's all! You can now start your simulation as usual::
Network Attachment
------------------
As shown in the example in section :ref:`sec-basic-simulation-program`,
As shown in the basic example in ,
attaching a UE to an eNodeB is done by calling ``LteHelper::Attach`` function.
This is the *"manual"* method of network attachment, and there is the
*"automatic"* method as well. Each of them will be covered in this section.
There are 2 possible ways of network attachment. The first method is the
*"manual"* one, while the second one has a more *"automatic"* sense on it. Each
of them will be covered in this section.
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::
This method uses the ``LteHelper::Attach`` function as demonstrated in section
:ref:`sec-basic-simulation-program`. It has been the only available network
attachment 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
@@ -941,8 +944,8 @@ 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.
One may choose the distance between the UE and the eNodeB may be used as a
criterion for selecting the appropriate cell. It is simple (at least from the
One may choose the distance between the UE and the eNodeB as a criterion for
selecting the appropriate cell. It is quite simple (at least from the
simulator's point of view) and sometimes practical. But it is important to note
that sometimes distance does not make a single correct criterion. For instance,
the eNodeB antenna direction should be considered as well. Besides that, we
@@ -975,19 +978,41 @@ neighbouring cells, and then attempt to connect to the best one. More details
can be found in section :ref:`sec-initial-cell-selection` of design
documentation.
Multi-operator environment
**************************
Closed Subscriber Group
***********************
An interesting use case of the initial cell selection process is to setup a
simulation environment with multiple network operators.
simulation environment with Closed Subscriber Group (CSG).
(To be expanded)
For example, a certain eNodeB, typically a smaller version such as femtocell,
might belong to a private owner (a household or business), allowing access only
for some UEs which have been previously registered by the owner. The eNodeB and
the registered UEs altogether form a CSG.
Note that the manual network attachment method does not take the PLMN and CSG
criteria into account, and thus can be regarded as the *"force attach"* method.
In other words, UE and eNodeB with incompatible PLMN or CSG can still attach
successfully using the manual network attachment method.
The access restriction can be simulated by "labeling" the CSG members with the
same CSG ID. This function is available from ``LteHelper`` class::
lteHelper->SetCsgId (enbDevs, 1); // label one or more eNodeBs with CSG ID of 1
lteHelper->SetCsgId (ueDevs, 1); // label one or more UEs with CSG ID of 1
Then enable the initial cell selection procedure on the UEs::
lteHelper->Attach (ueDevs);
This is necessary because the CSG restriction only works with initial cell
selection, and not in the manual method.
Note that setting the CSG ID of an eNodeB as 0 (the default value) will disable
the restriction, i.e. any UEs can connect to this eNodeB. On the other hand,
setting the CSG ID of a UE to 0 (also the default value) does not remove the
restriction, i.e. it can only attach to an eNodeB with CSG ID of 0.
Besides differences in CSG, we can also introduce differences in Public Land
Mobile Network (PLMN). ``LteHelper`` also has similar functions for this purpose
and the restricting behaviour is exactly the same as in CSG::
lteHelper->SetPlmnId (enbDevs, 1); // label one or more eNodeBs with PLMN ID of 1
lteHelper->SetPlmnId (ueDevs, 1); // label one or more UEs with PLMN ID of 1
.. _sec-configure-ue-measurements: