diff --git a/doc/models/Makefile b/doc/models/Makefile index 4060e893d..6e05667d5 100644 --- a/doc/models/Makefile +++ b/doc/models/Makefile @@ -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 \ diff --git a/src/lte/doc/source/figures/lte-ue-rrc-states.dot b/src/lte/doc/source/figures/lte-ue-rrc-states.dot index f57f399f3..ca8180a98 100644 --- a/src/lte/doc/source/figures/lte-ue-rrc-states.dot +++ b/src/lte/doc/source/figures/lte-ue-rrc-states.dot @@ -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"] } diff --git a/src/lte/doc/source/figures/lte-ue-rrc-states.pdf b/src/lte/doc/source/figures/lte-ue-rrc-states.pdf index bc41d8899..696c7ba8a 100644 Binary files a/src/lte/doc/source/figures/lte-ue-rrc-states.pdf and b/src/lte/doc/source/figures/lte-ue-rrc-states.pdf differ diff --git a/src/lte/doc/source/figures/lte-ue-rrc-states.png b/src/lte/doc/source/figures/lte-ue-rrc-states.png index 91253816f..277334b90 100644 Binary files a/src/lte/doc/source/figures/lte-ue-rrc-states.png and b/src/lte/doc/source/figures/lte-ue-rrc-states.png differ diff --git a/src/lte/doc/source/lte-design.rst b/src/lte/doc/source/lte-design.rst index 4b85501b6..6ad8b3f64 100644 --- a/src/lte/doc/source/lte-design.rst +++ b/src/lte/doc/source/lte-design.rst @@ -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 ------------------------------ diff --git a/src/lte/doc/source/lte-references.rst b/src/lte/doc/source/lte-references.rst index 93bf61d86..d52cfbc6a 100644 --- a/src/lte/doc/source/lte-references.rst +++ b/src/lte/doc/source/lte-references.rst @@ -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" diff --git a/src/lte/doc/source/lte-testing.rst b/src/lte/doc/source/lte-testing.rst index 4a6b12cf3..d4869a08d 100644 --- a/src/lte/doc/source/lte-testing.rst +++ b/src/lte/doc/source/lte-testing.rst @@ -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 diff --git a/src/lte/doc/source/lte-user.rst b/src/lte/doc/source/lte-user.rst index 005e9c3b4..8ac2f4331 100644 --- a/src/lte/doc/source/lte-user.rst +++ b/src/lte/doc/source/lte-user.rst @@ -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: