22 Support for self-configuration and self-optimisation
36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS
22.1 Definitions
This concept includes several different functions from eNB activation to radio parameter tuning. Figure 22.1-1 is a basic framework for all self-configuration /self-optimisation functions.
Self-configuration process is defined as the process where newly deployed nodes are configured by automatic installation procedures to get the necessary basic configuration for system operation.
This process works in pre-operational state. Pre-operational state is understood as the state from when the eNB is powered up and has backbone connectivity until the RF transmitter is switched on.
As described in Figure 21.1, functions handled in the pre-operational state like:
– Basic Setup; and
– Initial Radio Configuration.
are covered by the Self Configuration process.
Self-optimisation process is defined as the process where UE & eNB measurements and performance measurements are used to auto-tune the network.
This process works in operational state. Operational state is understood as the state where the RF interface is additionally switched on.
As described in Figure 21.1, functions handled in the operational state like:
– Optimisation / Adaptation
are covered by the Self Optimisation process.
Figure 22.1-1: Ramifications of Self-Configuration /Self-Optimisation functionality
22.2 UE Support for self-configuration and self-optimisation
UE shall support measurements and procedures which can be used for self-configuration and self-optimisation of the E-UTRAN system.
– UE shall support measurements and measurement reporting to support self-optimisation of the E-UTRAN system. Measurements and reports used for the normal system operation, should be used as input for the self-optimisation process as far as possible.
– The network is able to configure the measurements and the reporting for self-optimisation support by RRC signalling messages.
22.3 Self-configuration
22.3.1 Dynamic configuration of the S1-MME interface
22.3.1.1 Prerequisites
The following prerequisites are assumed:
– An initial remote IP end point to be used for SCTP initialisation is provided to the eNB for each MME. The eNB may be in pre-operational or operational state when this occurs.
How the eNB gets the remote IP end point(s) and its own IP address are outside the scope of this specification.
22.3.1.2 SCTP initialization
For each MME the eNodeB tries to initialize a SCTP association as described in IETF RFC 4960 [8], using a known initial remote IP Endpoint as the starting point, until SCTP connectivity is established.
NOTE: The eNB may use different source and/or destination IP end point(s) if the SCTP establishment towards one IP endpoint fails.
22.3.1.3 Application layer initialization
Once SCTP connectivity has been established, the eNodeB and MME shall exchange application level configuration data over the S1-MME application protocol with the S1 Setup Procedure, which is needed for these two nodes to interwork correctly on the S1 interface.
– The eNodeB provides the relevant configuration information to the MME, which includes list of supported TA(s), etc.
– The MME provides the relevant configuration information to the eNodeB, which includes PLMN ID, etc.
– When the application layer initialization is successfully concluded, the dynamic configuration procedure is completed and the S1-MME interface is operational.
In addition, an eNB which has become X2-C connected to an en-gNB provides the connected en-gNB’s Global en-gNB Identifier to the MME.
22.3.2 Dynamic Configuration of the X2 interface
22.3.2.1 Prerequisites
The following prerequisites are assumed:
– An initial local IP end point to be used for SCTP initialisation is provided to the eNB/en-gNB.
– For EN-DC, the en-gNB is provided with an initial remote IP end point of an eNB to be used for SCTP initialisation.
22.3.2.2 SCTP initialization
For candidate eNB/en-gNB the eNB/en-gNB tries to initialize a SCTP association as described in IETF RFC 4960 [8], using a known initial remote IP Endpoint as the starting point, until SCTP connectivity is established.
NOTE: The eNB/en-gNB may use different source and/or destination IP end point(s) if the SCTP establishment towards one IP endpoint fails.
22.3.2.3 Application layer initialization
In the below, one of the involved eNBs (initiating or candidate eNB) may instead be an en-gNB.
– Once SCTP connectivity has been established, the eNB and its candidate peer eNB are in a position to exchange application level configuration data over the X2 application protocol needed for the two nodes to interwork correctly on the X2 interface.
– The eNB provides the relevant configuration information to the candidate eNB, which includes served cell information, etc.
– The candidate eNB provides the relevant configuration information to the initiating eNB, which includes served cell information, etc.
– When the application layer initialization is successfully concluded, the dynamic configuration procedure is completed and the X2 interface is operational.
The following principles apply for the exchange of served cell information:
– eNBs shall keep neighbouring eNBs and en-gNBs updated with the complete list of served E-UTRA cells while the X2 interface is operational.
– en-gNBs shall inform neighbouring eNBs of the full or partial list of served NR served cell during application layer initialization, and keep neighbouring eNBs updated with the full or partial list of served NR served cells, or, if requested by the eNB, with a limited list of served NR cells, while the X2 interface is operational.
22.3.2a Automatic Neighbour Relation Function
The purpose of the Automatic Neighbour Relation (ANR) function is to relieve the operator from the burden of manually managing Neighbour Cell Relations (NCRs). Figure 22.3.2a-1 shows ANR and its environment:
Figure 22.3.2a-1: Interaction between eNB and O&M due to ANR
The ANR function resides in the eNB and manages the conceptual Neighbour Cell Relation Table (NCRT). Located within ANR, the Neighbour Detection Function finds new neighbours and adds them to the NCRT. ANR also contains the Neighbour Removal Function which removes outdated NCRs. The Neighbour Detection Function and the Neighbour Removal Function are implementation specific.
A Neighbour Cell Relation (NCR) in the context of ANR is defined as follows:
An existing Neighbour Relation from a source cell to a target cell means that eNB controlling the source cell:
a) Knows the ECGI/CGI and PCI of the target cell.
b) Has an entry in the Neighbour Cell Relation Table for the source cell identifying the target cell.
c) Has the attributes in this Neighbour Cell Relation Table entry defined, either by O&M or set to default values.
For each cell that the eNB has, the eNB keeps a NCRT, see Figure 22.3.2a-1. For each NCR, the NCRT contains the Target Cell Identifier (TCI), which identifies the target cell. For E-UTRAN, the TCI corresponds to the E-UTAN Cell Global Identifier (ECGI) and Physical Cell Identifier (PCI) of the target cell. Furthermore, each NCR has three attributes, the NoRemove, the NoHO and the NoX2 attribute. These attributes have the following definitions:
– No Remove: If checked, the eNB shall not remove the Neighbour Cell Relation from the NRT.
– No HO: If checked, the Neighbour Cell Relation shall not be used by the eNB for handover reasons.
– No X2: If checked, the Neighbour Relation shall not use an X2 interface in order to initiate procedures towards the eNB parenting the target cell.
Neighbour Cell Relations are cell-to-cell relations, while an X2 link is set up between two eNBs. Neighbour Cell Relations are unidirectional, while an X2 link is bidirectional.
NOTE: The neighbour information exchange, which occurs during the X2 Setup procedure or in the eNB Configuration Update procedure, may be used for ANR purpose.
The ANR function also allows O&M to manage the NCRT. O&M can add and delete NCRs. It can also change the attributes of the NCRT. The O&M system is informed about changes in the NCRT.
22.3.3 Intra-LTE/frequency Automatic Neighbour Relation Function
The ANR (Automatic Neighbour Relation) function relies on cells broadcasting their identity on global level, E-UTRAN Cell Global Identifier (ECGI).
Figure 22.3.3-1: Automatic Neighbour Relation Function
The function works as follows:
The eNB serving cell A has an ANR function. As a part of the normal call procedure, the eNB instructs each UE to perform measurements on neighbour cells. The eNB may use different policies for instructing the UE to do measurements, and when to report them to the eNB. This measurement procedure is as specified in TS 36.331 [16].
1. The UE sends a measurement report regarding cell B. This report contains Cell B’s PCI, but not its ECGI.
When the eNB receives a UE measurement report containing the PCI, the following sequence may be used.
2. The eNB instructs the UE, using the newly discovered PCI as parameter, to read the ECGI, the TAC and all available PLMN ID(s) of the related neighbour cell. To do so, the eNB may need to schedule appropriate idle periods to allow the UE to read the ECGI from the broadcast channel of the detected neighbour cell. How the UE reads the ECGI is specified in TS 36.331 [16].
3. When the UE has found out the new cell’s ECGI, the UE reports the detected ECGI to the serving cell eNB. In addition, the UE reports the tracking area code and all PLMN IDs that have been detected. If the detected cell is a CSG or hybrid cell, the UE also reports the CSG ID to the serving cell eNB.
4. The eNB decides to add this neighbour relation, and can use PCI and ECGI to:
a Lookup a transport layer address to the new eNB.
b Update the Neighbour Relation List.
c If needed, setup a new X2 interface towards this eNB. The setup of the X2 interface is described in clause 22.3.2.
NOTE: The eNB may differentiate the open access HeNB from the other types of (H)eNB by the PCI configuration or ECGI configuration.
22.3.4 Inter-RAT/Inter-frequency Automatic Neighbour Relation Function
Figure 22.3.4-1: Automatic Neighbour Relation Function in case of e.g. UTRAN detected cell
For Inter-RAT and Inter-Frequency ANR, each cell contains an Inter Frequency Search list. This list contains all frequencies that shall be searched.
For Inter-RAT cells, the NoX2 attribute in the NCRT is absent, as X2 is only defined for E-UTRAN.
The function works as follows:
The eNB serving cell A has an ANR function. During connected mode, the eNB can instruct a UE to perform measurements and detect cells on other RATs/frequencies. The eNB may use different policies for instructing the UE to do measurements, and when to report them to the eNB.
1 The eNB instructs a UE to look for neighbour cells in the target RATs/frequencies. To do so the eNB may need to schedule appropriate idle periods to allow the UE to scan all cells in the target RATs/frequencies.
2 The UE reports the PCI of the detected cells in the target RATs/frequencies. The PCI is defined by the carrier frequency and the Primary Scrambling Code (PSC) in case of UTRAN FDD cell, by the carrier frequency and the cell parameter ID in case of UTRAN TDD cell, by the Band Indicator + BSIC + BCCH ARFCN in case of GERAN cell, by the PN Offset in case of CDMA2000 cell, and by the NR PSS/SSS in case of NR cell.
When the eNB receives UE reports containing PCIs of cell(s) the following sequence may be used.
3 The eNB instructs the UE, using the newly discovered PCI as parameter, to read the CGI and the RAC of the detected neighbour cell in case of GERAN detected cells, CGI, LAC, RAC and all broadcasted PLMN-ID(s) in case of UTRAN detected cells, CGI in case of CDMA2000 detected cells, and NCGI(s), TAC(s), RANAC(s), all available PLMN ID(s), gNB identity length(s) and all available NR frequency band(s) in case of NR detected cells. For the Inter-frequency case, the eNB instructs the UE, using the newly discovered PCI as parameter, to read the ECGI, TAC and all available PLMN ID(s) of the inter-frequency detected cell. The UE ignores transmissions from the serving cell while finding the requested information transmitted in the broadcast channel of the detected inter-system/inter-frequency neighbour cell. To do so, the eNB may need to schedule appropriate idle periods to allow the UE to read the requested information from the broadcast channel of the detected inter-RAT/inter-frequency neighbour cell.
4 After the UE has read the requested information in the new cell, it reports the detected CGI and RAC (in case of GERAN detected cells) or CGI, LAC, RAC and all broadcasted PLMN-ID(s) (in case of UTRAN detected cells) or CGI (in case of CDMA2000 detected cells) or all broadcast NCGI(s), TAC(s), RANAC(s), PLMN-ID(s), gNB identity length(s) and NR frequency band(s) (in case of NR detected cells) to the serving cell eNB. In the inter-RAT NR case, the UE may report noSIB1 indication in case the detected NR cell does not broadcast SIB1, as described in TS 36.331 [16]. In the inter-frequency case, the UE reports the ECGI, the, tracking area code and all PLMN-ID(s) that have been detected. If the detected cell is a CSG or hybrid cell, the UE also reports the CSG ID to the serving cell eNB.
5 The eNB updates its inter-RAT/inter-frequency Neighbour Cell Relation Table.
In the inter-frequency case and if needed, the eNB can use the PCI and ECGI for a new X2 interface setup towards this eNB. The setup of the X2 interface is described in clause 22.3.2.
NOTE: The eNB may differentiate the open access HeNB from the other types of (H)eNB by the PCI configuration or ECGI configuration.
22.3.4a Automatic Neighbour Relation Function towards NR
The ANR function described in clause 22.3.2 and 22.3.4 applies towards NR with enhancements as follows:
An existing NCR from a source E-UTRA cell to a target NR cell means that eNB controlling the source cell knows the NCGI and PCI of the target cell.
If an NCR from a source E-UTRA cell to a target E-UTRA cell exists, the eNB controlling the source cell has information whether the target E-UTRA cell has an existing NCR to a target NR cell for performing EN-DC.
An X2 link may be set up between eNB and en-gNB. The NoRemove, the NoHO and the NoX2 attributes apply when the en-gNB parents the target cell. Each NCR has the following additional attribute:
– No EN-DC: If checked, the Neighbour Cell Relation shall not be used by the eNB for EN-DC.
Each E-UTRA cell contains an Inter Frequency Search list. This list contains all frequencies that shall be searched.
The PCI is defined by the frequency of the SSB associated with SIB1, and NR-PCI.
22.3.4b Automatic Neighbour Relation Function in NB-IoT
The ANR (Automatic Neighbour Relation) function relies on cells broadcasting their identity on global level, E-UTRAN Cell Global Identifier (ECGI).
Figure 22.3.4b-1: Automatic Neighbour Relation Function in case of NB-IoT
The purpose of SON/ANR reporting in NB-IoT is network optimisation. The measurements are performed when the UE is in RRC_IDLE and reported next time the UE enters RRC_CONNECTED. ANR measurement reporting is not supported when the UE uses the Control Plane CIoT EPS Optimisation.
The function works as follows:
The eNB serving cell A has an ANR function. During connected mode, the eNB can configure the UE to perform measurements on a frequency and read the CGI of the strongest cell if the quality is above a given RSRP threshold. The eNB may use different policies for instructing the UE to do measurements.
1 When releasing the RRC connection, the eNB configures the UE to perform ANR measurements on one or more frequencies. The RRC connection is released and the UE enters RRC_IDLE.
When the UE is in RRC_IDLE and remains camped on the cell from which the ANR measurement configuration was received, the UE performs the ANR measurements requested by the eNB:
2a For each of the configured frequency, the UE performs measurements, identifies the strongest cell and stores the cell measurement results for later reporting.
2b For each of the configured frequency, if the NRSRP of the strongest cell is above the configured threshold, the UE reads the ECGI, the TAC and all available PLMN ID(s) of the related neighbour cell and stores the information for later reporting.
NOTE: While performing an ANR measurement, the UE performs inter-frequency measurements on the configured frequency regardless of the measurement rules for cell re-selection and the relaxed monitoring measurement rules as specified in TS 36.304 [11].
When the UE establishes or resumes the RRC connection:
3 The UE reports the availability of an ANR report.
When the eNB receives the indication of the ANR report availability, the following sequence may be used whilst UE is in RRC_CONNECTED mode:
4 The eNB requests the UE to provide the report.
5 The UE reports the stored cells and associated information.
The UE discards the ANR configuration and the ANR report when returning to RRC_IDLE after it has indicated the availability of the ANR report, after 96 hours of receiving the configuration, upon power off, upon detach or upon RAT change.
22.3.5 Framework for PCI Selection
The eNB shall base the selection of its PCI either on a centralized or distributed PCI assignment algorithm:
[Centralized PCI assignment] The OAM signals a specific PCI value. The eNB shall select this value as its PCI.
[Distributed PCI assignment] The OAM signals a list of PCI values. The eNB may restrict this list by removing PCI-s that are:
a) reported by UEs;
b) reported over the X2 interface by neighbouring eNBs; and/or
c) acquired through other implementation dependent methods, e.g. heard over the air using a downlink receiver.
The eNB shall select a PCI value randomly from the remaining list of PCIs.
22.3.6 TNL address discovery
22.3.6.1 TNL address discovery of candidate eNB via S1 interface
If the eNB is aware of the eNB ID of the candidate eNB (e.g. via the ANR function) but not a TNL address suitable for SCTP connectivity, then the eNB can utilize the Configuration Transfer Function to determine the TNL address as follows:
– The eNB sends the eNB CONFIGURATION TRANSFER message to the MME to request the TNL address of the candidate eNB, and includes relevant information such as the source and target eNB ID.
– The MME relays the request by sending the MME CONFIGURATION TRANSFER message to the candidate eNB identified by the target eNB ID.
– The candidate eNB responds by sending the eNB CONFIGURATION TRANSFER message containing one or more TNL addresses to be used for SCTP connectivity with the initiating eNB, and includes other relevant information such as the source and target eNB ID.
– The MME relays the response by sending the MME CONFIGURATION TRANSFER message to the initiating eNB identified by the target eNB ID.
22.3.6.2 TNL address discovery of a candidate en-gNB via the S1 interface
If the eNB is aware of the en-gNB ID of the candidate en-gNB but not a TNL address suitable for SCTP connectivity between the eNB and the en-gNB, then the eNB utilizes the Configuration Transfer Function to determine the TNL address as follows:
– The eNB sends the eNB CONFIGURATION TRANSFER message to the MME to request the TNL address of the candidate en-gNB. The eNB includes its own (source) eNB ID and the candidate (target) en-gNB ID.
– The eNB may include in the eNB CONFIGURATION TRANSFER message, if available,
– a target eNB ID, if the eNB has knowledge that the target eNB ID is X2 connected to the candidate en-gNB;
– a TAI associated with the target en-gNB, if the eNB has knowledge about a TAI broadcast in the coverage area of an NR cell served by the candidate en-gNB.
– The MME relays the request by sending the MME CONFIGURATION TRANSFER message to an eNB known to be connected to the candidate en-gNB.
– The eNB connected to the candidate en-gNB relays the request to the candidate en-gNB by means of the X2AP EN-DC Configuration Transfer procedure.
– The candidate en-gNB sends its X2 TNL Configuration Information to the same eNB using the X2AP EN-DC Configuration Transfer procedure, and identifying the initiating eNB as the target eNB ID.
– The eNB connected to the candidate en-gNB forwards the received X2 TNL Configuration Information to the MME in the eNB CONFIGURATION TRANSFER message.
– The MME relays the response by sending the MME CONFIGURATION TRANSFER message to the initiating eNB identified by the target eNB ID.
NOTE: An NR cell does not broadcast a Tracking Area Code applicable for the EPS. In case that inter-MME X2 TNL address discovery procedures are required, the source MME may use the available information to identify the target MME.
22.3.6.3 TNL address discovery of a candidate en-gNB via inter-system signalling
If the MME is aware that the en-gNB serves cells which provide access to 5GS, the MME may relay the request towards a suitable AMF via inter-system signalling based on a broadcast 5G TAC. Upon receiving a reply from the AMF, the MME may relay this reply to the target eNB using a MME CONFIGURATION TRANSFER message.
22.3.7 Dynamic configuration of the Xw-C interface
22.3.7.1 Prerequisites
The following prerequisites are assumed:
– An initial remote IP end point to be used for SCTP initialisation is provided to the eNB.
How the eNB gets the remote IP end point(s) and its own IP address are outside the scope of this specification.
22.3.7.2 SCTP initialization
For each WT the eNB tries to initialize a SCTP association as described in IETF RFC 4960 [8], using a known initial remote IP endpoint as the starting point, until SCTP connectivity is established.
22.3.7.3 Application layer initialization
Once SCTP connectivity has been established, the eNB and candidate WT shall exchange application level configuration data over the Xw-C application protocol with the Xw Setup Procedure, which is needed for these two nodes to interwork correctly on the Xw interface.
– The eNB provides the relevant configuration information to the WT, which includes the Global eNB ID.
– The WT provides the relevant configuration information to the eNB, which includes WLAN information, etc.
– When the application layer initialization is successfully concluded, the dynamic configuration procedure is completed and the Xw-C interface is operational.
22.4 Self-optimisation
22.4.1 Support for Mobility Load Balancing
22.4.1.1 General
The objective of load balancing is to distribute cell load evenly among cells or to transfer part of the traffic from congested cells. This is done by the means of self-optimisation of mobility parameters or handover actions.
Self-optimisation of the intra-LTE, inter-RAT and inter-system mobility parameters to the current load in the cell and in the adjacent cells can improve the system capacity compared to static/non-optimised cell reselection/handover parameters. Such optimisation can also minimize human intervention in the network management and optimisation tasks.
Support for mobility load balancing consists of one or more of following functions:
– Load reporting (for intra-LTE, inter-RAT, EN-DC and inter-system scenarios);
– Load balancing action based on handovers;
– Adapting handover and/or reselection configuration.
Triggering of each of these functions is optional and depends on implementation. Functional architecture is presented in Figure 22.4.1.1-1.
Figure 22.4.1.1-1: Functional architecture of SON load balancing
22.4.1.2 Load reporting
The load reporting function is executed by exchanging cell specific load information between neighbour eNBs over the X2 interface (intra-LTE scenario) or S1 (inter-RAT scenario and EN-DC scenario). The load reporting function for inter-system load balancing is executed by exchanging load information between E-UTRAN and NG-RAN.
22.4.1.2.1 Load reporting for intra-LTE scenario
The load information consists of:
– radio resource usage (UL/DL GBR PRB usage, UL/DL non-GBR PRB usage, UL/DL total PRB usage);
– HW load indicator (UL/DL HW load: low, mid, high, overload);
– TNL load indicator (UL/DL TNL load: low, mid, high, overload);
– (Optionally) Cell Capacity Class value (UL/DL relative capacity indicator: the same scale shall apply to E-UTRAN, UTRAN and GERAN cells when mapping cell capacities on this value);
– Capacity value (UL/DL available capacity for load balancing as percentage of total cell capacity).
NOTE 1: Capacity value is expressed in available E-UTRAN resources.
NOTE 2: A cell is expected to accept traffic corresponding to the indicated available capacity.
22.4.1.2.2 Load reporting for inter-RAT scenario
The load information consists of:
– Cell Capacity Class value (UL/DL relative capacity indicator: the same scale shall apply to E-UTRAN, UTRAN, GERAN and eHRPD cells when mapping cell capacities on this value);
– Capacity value (UL/DL available capacity for load balancing as percentage of total cell capacity).
NOTE 1: Capacity value is expressed in available E-UTRAN resources.
NOTE 2: A cell is expected to accept traffic corresponding to the indicated available capacity.
Event-triggered inter-RAT load reports are sent when the reporting node detects crossing of cell load thresholds.
Load information shall be provided in a procedure separated from existing active mode mobility procedures, which shall be used infrequently and with lower priority with respect to the UE dedicated signalling.
22.4.1.2.3 Load reporting for EN-DC scenario
The load reporting function is executed by the way that an en-gNB provides its load information toward an eNB over the X2 interface.
For an NR cell, the following load related information should be supported which consists of:
– Radio resource usage (per-SSB-area PRB usage: DL/UL/SUL GBR PRB usage, DL/UL/SUL non-GBR PRB usage, DL/UL/SUL total PRB usage, and DL/UL/SUL scheduling PDCCH CCE usage);
– TNL capacity indicator (UL/DL TNL offered capacity and available capacity);
– Cell Capacity Class value (UL/DL relative capacity indicator);
– Capacity value (UL/DL available capacity);
To achieve load reporting function, EN-DC Resource Status Reporting Initiation & EN-DC Resource Status Reporting procedures are used.
22.4.1.2.4 Load reporting for inter-system load balancing
Both event-triggered and periodic inter-system load reporting are supported. Event-triggered inter-system load reports are sent when the reporting node detects crossing of cell load thresholds.
The following load related information should be supported which consists of:
– Cell Capacity Class value (UL/DL relative capacity indicator);
– Capacity value (per cell: UL/DL available capacity);
– RRC connections (number of RRC connections, and available RRC Connection Capacity);
– Number of active UEs;
– Radio Resource Status (per cell PRB usage: UL/DL GBR PRB usage, DL/UL non-GBR PRB usage, DL/UL total PRB usage, and DL/UL scheduling PDCCH CCE usage).
NGAP procedures used for inter-system load balancing are Uplink RAN Configuration Transfer and Downlink RAN Configuration Transfer.
S1AP procedures used for inter-system load balancing are eNB Configuration Transfer and MME Configuration Transfer.
22.4.1.3 Load balancing action based on handovers
The source cell may initiate handover due to load (see clauses 10.1.2 and 10.2.2). The target cell performs admission control for the load balancing handovers. A handover preparation related to a mobility load balancing action shall be distinguishable from other handovers, so that the target cell is able to apply appropriate admission control.
22.4.1.4 Adapting handover and/or reselection configuration
This function enables requesting of a change of handover and/or reselection parameters at target cell. The source cell that initialized the load balancing estimates if it is needed to change mobility configuration in the source and/or target cell. If the amendment is needed, the source cell initializes mobility negotiation procedure toward the target cell.
The source cell informs the target cell about the new mobility setting and provides cause for the change (e.g. load balancing related request). The proposed change is expressed by the means of the difference (delta) between the current and the new values of the handover trigger. The handover trigger is the cell specific offset that corresponds to the threshold at which a cell initialises the handover preparation procedure. Cell reselection configuration may be amended to reflect changes in the HO setting. The target cell responds to the information from the source cell. The allowed delta range for HO trigger parameter may be carried in the failure response message. The source cell should consider the responses before executing the planned change of its mobility setting.
All automatic changes on the HO and/or reselection parameters must be within the range allowed by OAM.
22.4.2 Support for Mobility Robustness Optimisation
22.4.2.1 General
Mobility Robustness Optimisation aims at detecting and enabling correction of following problems:
– Connection failure due to intra-LTE or inter-RAT mobility;
– Unnecessary HO to another RAT (too early IRAT HO with no radio link failure);
– Inter-RAT ping-pong;
– Inter-system ping-pong.
22.4.2.2 Connection failure due to intra-LTE mobility
One of the functions of Mobility Robustness Optimisation is to detect connection failures that occur due to Too Early or Too Late Handovers, or Handover to Wrong Cell. These problems are defined as follows:
– [Too Late Handover] An RLF occurs after the UE has stayed for a long period of time in the cell; the UE attempts to re-establish the radio link connection in a different cell.
– [Too Early Handover] An RLF occurs shortly after a successful handover from a source cell to a target cell or a handover failure occurs during the handover procedure; the UE attempts to re-establish the radio link connection in the source cell.
– [Handover to Wrong Cell] An RLF occurs shortly after a successful handover from a source cell to a target cell or a handover failure occurs during the handover procedure; the UE attempts to re-establish the radio link connection in a cell other than the source cell and the target cell.
In the definition above, the "successful handover" refers to the UE state, namely the successful completion of the RA procedure.
In addition, MRO provides means to distinguish the above problems from LTE coverage related problems and other problems, not related to mobility.
Solution for failure scenarios consists of one or more of following functions:
– Detection of the failure after RRC re-establishment attempt;
– Detection of the failure after RRC connection setup;
– Retrieval of information needed for problem analysis.
Triggering of each of these functions is optional and depends on situation and implementation.
Detection of the failure after RRC re-establishment attempt:
Detection mechanisms for Too Late Handover, Too Early Handover and Handover to Wrong Cell are carried out through the following:
– [Too Late Handover]
If the UE attempts to re-establish the radio link connection in a cell that belongs to eNB B, indicating as the last serving cell a cell belonging to eNB A, different from eNB B, then eNB B may report this event to eNB A by means of the RLF Indication Procedure. eNB A may then use information in the RLF INDICATION message to determine whether the failure occurred in the serving cell.
– [Too Early Handover]
If the target cell belongs to an eNB B different from the eNB A that controls the source cell, the eNB B may send a HANDOVER REPORT message indicating a Too Early Handover event to eNB A upon eNB B receives an RLF INDICATION message from eNB A and if eNB B has sent the UE CONTEXT RELEASE message to eNB A related to the completion of an incoming handover for the same UE within the last Tstore_UE_cntxt seconds or there exists a prepared handover for the same UE in eNB B.
– [Handover to Wrong Cell]
If the type of the failure is Radio Link Failure and the target cell belongs to eNB B that is different from the eNB A that controls the source cell, the eNB B may send a HANDOVER REPORT message indicating a Handover To Wrong Cell event to eNB A upon eNB B receives an RLF INDICATION message from eNB C, and if eNB B has sent the UE CONTEXT RELEASE message to eNB A related to the completion of an incoming handover for the same UE within the last Tstore_UE_cntxt seconds or there exists a prepared handover for the same UE in eNB B. This also applies when eNB A and eNB C are the same. The HANDOVER REPORT message may also be sent if eNB B and eNB C are the same and the RLF Indication is internal to this eNB.
If the type of the failure is Handover Failure during a handover from a cell in eNB A, and the UE attempts to re-establish the radio link connection to a cell in eNB C, then eNB C may send a RLF INDICATION message to eNB A.
The detection of the above events, when involving more than one eNB, is enabled by the RLF Indication, Handover Report and MME Configuration Transfer procedures.
The RLF Indication procedure may be initiated after a UE attempts to re-establish the radio link connection at eNB B after a failure at eNB A. The RLF INDICATION message sent from eNB B to eNB A shall contain the following information elements:
– Failure Cell ID: PCI of the cell in which the UE was connected prior to the failure occurred;
– Reestablishment Cell ID: ECGI of the cell where RL re-establishment attempt is made;
– C-RNTI: C-RNTI of the UE in the cell where UE was connected prior to the failure occurred;
– shortMAC-I (optionally): the 16 least significant bits of the MAC-I calculated using the security configuration of the source cell and the re-establishment cell identity;
– UE RLF Report Container (optionally): the RLF Report received from the UE, as specified in TS 36.331 [16];
– Reestablishment Cause (optionally): provided by the UE during the RRC connection re-establishment attempt.
eNB B may initiate RLF Indication towards multiple eNBs if they control cells which use the PCI signalled by the UE during the re-establishment procedure. The eNB A selects the UE context that matches the received Failure Cell ID and C-RNTI, and, if available, uses the shortMAC-I to confirm this identification, by calculating the shortMAC-I and comparing it to the received IE.
The Handover Report procedure is used in the case of recently completed handovers, when a failure occurs in the target cell (in eNB B) shortly after it sent the UE Context Release message to the source eNB A. The Handover Report procedure is also used when an RLF occurs before the UE Context Release message is sent, if the random access procedure in the target cell was completed successfully. The HANDOVER REPORT message contains the following information:
– Type of detected handover problem (Too Early Handover, Handover to Wrong Cell);
– ECGI of source and target cells in the handover;
– ECGI of the re-establishment cell (in the case of Handover to Wrong Cell);
– Handover cause (signalled by the source during handover preparation);
– C-RNTI allocated for the UE in the source cell (if available);
– Mobility Information (optionally);
– UE RLF Report (optionally): the RLF Report received from the UE and forwarded in the RLF INDICATION message.
UE may provide the RLF Report to the eNB after successful RRC re-establishment. The radio measurements contained in the RLF Report may be used e.g. to identify coverage issues as the potential cause of the failure. The cause for the RLF contained in the RLF Report may be used to identify the cause of the failure and exclude the events that are irrelevant for MRO evaluation.
Detection of the failure after RRC connection setup:
In case the RRC re-establishment fails or the UE does not perform any RRC re-establishment, the UE makes the RLF Report available to the eNB after reconnecting from idle mode. The RLF Report is described in clause 22.4.5. Availability of the RLF Report at the RRC connection setup procedure is the indication that the UE suffered from a connection failure and that the RLF Report from this failure was not yet delivered to the network. The RLF Report from the UE includes the following information:
– The E-CGI of the last cell that served the UE (in case of RLF) or the target of the handover (in case of handover failure). If the E-CGI is not known, the PCI and frequency information are used instead.
– E-CGI of the cell that the re-establishment attempt was made at.
– E-CGI of the cell that served the UE at the last handover initialisation, i.e. when message 7 (RRCConnectionReconfiguration) was received by the UE, as presented in Figure 10.1.2.1.1-1.
– Time elapsed since the last handover initialisation until connection failure.
– An indication whether the connection failure was due to RLF or handover failure.
– The radio measurements.
– C-RNTI allocated for the UE in the last serving cell.
– RLF trigger of the last RLF that was detected.
– Time elapsed from the connection failure till RLF Report signalling.
The eNB receiving the RLF Report from the UE may forward the report to the eNB that served the UE before the reported connection failure using the RLF INDICATION message. In case the RLF Report is received in an NG-RAN node (as defined in TS 38.300 [79]), it may be delivered to the eNB that served the UE before the reported connection failure using the MME Configuration Transfer procedure. The radio measurements contained in the RLF Report may be used e.g. to identify coverage issues as the potential cause of the failure. The cause for the RLF contained in the RLF Report may be used to identify the cause of the failure and exclude the irrelevant events that are irrelevant for MRO evaluation.
Detection of Too Late Handover, Too Early Handover and Handover to Wrong Cell is carried out through the following:
– [Too Late Handover]
There is no recent handover for the UE prior to the connection failure i.e. the UE reported timer is absent or larger than the configured threshold, e.g. Tstore_UE_cntxt.
– [Too Early Handover]
There is a recent handover for the UE prior to the connection failure i.e. the UE reported timer is smaller than the configured threshold, e.g. Tstore_UE_cntxt, and the first re-establishment attempt cell is the cell that served the UE at the last handover initialisation.
– [Handover to Wrong Cell]
There is a recent handover for the UE prior to the connection failure i.e. the UE reported timer is smaller than the configured threshold, e.g. Tstore_UE_cntxt, and the first re-establishment attempt cell is neither the cell that served the UE at the last handover initialisation nor the cell that served the UE where the RLF happened or the cell that the handover was initialised toward.
The "UE reported timer" above indicates the time elapsed since the last handover initialisation until connection failure.
In case of Too Early Handover or Handover to Wrong Cell, the eNB receiving the RLF INDICATION message may use the HANDOVER REPORT message to inform the eNB controlling the cell where the mobility configuration caused the failure.
Retrieval of information needed for problem analysis
The information needed for detailed problem analysis may be retrieved from both, the UE and the network sides. The information that is collected at the UE is provided to the network with the RLF Report, which may be forwarded to the last serving node in the RLF INDICATION message and, in case of "Too Early HO" or "HO to Wrong Cell", further in the HANDOVER REPORT message.
In order to retrieve relevant information collected at the network side as part of the UE context, the UE provides C-RNTI used in the last serving cell. If the cause for the failure is identified as a "Too Early HO" or a "HO to Wrong Cell", the eNB controlling the last serving cell shall, if supported, include in the HANDOVER REPORT message the C-RNTI used in the source cell of the last completed handover before the failure. If the eNB controlling that source cell provided the Mobility Information, it is included in the HANDOVER REPORT message. If used, the Mobility Information is prepared at the source eNB of a handover and may refer to or identify any handover-related data at this eNB.
Handling multiple reports from a single failure event
In case the RRC re-establishment fails and the RRC connection setup succeeds, MRO evaluation of intra-LTE mobility connection failures may be triggered twice for the same failure event. In this case, only one failure event should be counted.
22.4.2.2a Connection failure due to inter-RAT mobility
One of the functions of Mobility Robustness Optimisation is to detect connection failures that occurred due to Too Early or Too Late inter-RAT handovers. These problems are defined as follows:
– [Too Late Inter-RAT Handover] An RLF occurs after the UE has stayed in an E-UTRAN cell for a long period of time; the UE attempts to re-connect to a UTRAN cell.
– [Too Early Inter-RAT Handover] An RLF occurs shortly after a successful handover from a UTRAN cell to a target cell in E-UTRAN; the UE attempts to re-connect to the source cell or to another UTRAN cell.
The UE makes the RLF Report available to an eNB, when RLF happens in E-UTRAN and the UE re-connects to an eNB cell. Availability of the RLF Report at the RRC connection setup or at a handover to E-UTRAN cell is the indication that the UE suffered a connection failure and that the RLF Report from this failure was not yet delivered to the network.
The eNB receiving the RLF Report from the UE may forward the report to the eNB that served the UE before the reported connection failure using the RLF INDICATION message over X2 or by means of the eNB configuration transfer procedure and MME configuration transfer procedure over S1. If present in the RLF Report, the radio measurements may be used to identify lack of coverage as the potential cause of the failure. This information may be used to exclude those events from the MRO evaluation and redirect them as input to other algorithms.
Detection mechanisms for Too Late Inter-RAT Handover and Too Early Inter-RAT Handover are carried out through the following:
– [Too Late Inter-RAT Handover]
The connection failure occurs while being connected to an LTE cell, and there is no recent handover for the UE prior to the connection failure i.e., the UE reported timer is absent or larger than the configured threshold, e.g., Tstore_UE_cntxt, and the first cell where the UE attempts to re-connect is a UTRAN cell.
– [Too Early Inter-RAT Handover]
The connection failure occurs while being connected to an LTE cell, and there is a recent inter-RAT handover for the UE prior to the connection failure i.e., the UE reported timer is smaller than the configured threshold, e.g., Tstore_UE_cntxt, and the first cell where the UE attempts to re-connect and the cell that served the UE at the last handover initialisation are both UTRAN cells.
The "UE reported timer" above indicates the time elapsed since the last handover initialisation until connection failure.
In case the failure is a Too Early Inter-RAT Handover, the eNB receiving the RLF INDICATION message may inform the UTRAN node by means of the eNB Direct Information Transfer procedure over S1. The information contains:
– Type of detected handover problem (Too Early Inter-RAT Handover);
– UE RLF Report Container: the RLF Report received from the UE, as specified in TS 36.331 [16];
– Mobility Information (optionally, if provided in the last Handover Resource Allocation procedure from the UTRAN node);
22.4.2.3 Unnecessary HO to another RAT
One of the purposes of inter-RAT Mobility Robustness Optimisation is the detection of a non-optimal use of network resources. In particular, in case of inter-RAT operations and when E-UTRAN is considered, the case known as Unnecessary HO to another RAT is identified. The problem is defined as follows:
– UE is handed over from E-UTRAN to other RAT (e.g. GERAN or UTRAN) even though quality of the E-UTRAN coverage was sufficient for the service used by the UE. The handover may therefore be considered as unnecessary HO to another RAT (too early IRAT HO without connection failure).
In inter-RAT HO, if the serving cell threshold (E-UTRAN) is set too high, and another RAT with good signal strength is available, a handover to another RAT (e.g. UTRAN or GERAN) may be triggered unnecessarily, resulting in an inefficient use of the networks. With a lower threshold the UE could have continued in the source RAT (E-UTRAN).
To be able to detect the Unnecessary HO to another RAT, an eNB may choose to put additional coverage and quality condition information into the HANDOVER REQUIRED message in the Handover Preparation procedure when an inter-RAT HO from E-UTRAN to another RAT occurs. The RAN node in the other RAT, upon receiving this additional coverage and quality information, may instruct the UE to continue measuring the source RAT (E-UTRAN) during a period of time, while being connected to another RAT (e.g. UTRAN or GERAN), and send periodic or single measurement reports to the other RAT (e.g. UTRAN or GERAN). When the period of time indicated by the source RAT (E-UTRAN) expires, the RAN node in the other RAT (e.g. UTRAN or GERAN), may evaluate the received measurement reports with the coverage/quality condition received during the inter-RAT HO procedure and decide if an inter-RAT unnecessary HO report should be sent to the RAN node in the source RAT (E-UTRAN). The inter-RAT unnecessary HO report should include the following information:
– Handover type (LTE to UTRAN, LTE to GERAN);
– Type of detected handover problem (Unnecessary HO to another RAT);
– ECGI of the source cell in the handover;
– Cell ID of the target cell;
– A list of cells whose radio quality, as reported in the UE’s first measurement report following the handover, exceeds the threshold indicated in the additional coverage and quality information in the Handover Preparation procedure.
The inter-RAT unnecessary HO report shall only be sent in cases where, in all UE measurement reports collected during the measurement period, any source RAT cells exceed the radio coverage and/or quality threshold (the radio threshold RSRP or/and RSRQ and the measurement period are indicated in the additional coverage and quality information in the Handover Preparation procedure). If an inter-RAT handover towards LTE is executed from RNC within the indicated measurement period, the measurement period expires. In this case, the RNC may also send the HO Report. No HO Report shall be sent in case no E-UTRAN cell could be included, or if the indicated period of time is interrupted by an inter-RAT handover to a RAT different than LTE or by an intra-UMTS handover with SRNC relocation or inter-BSS handover.
The RAN node in the source RAT (E-UTRAN) upon receiving of the report, can decide if/how its parameters (e.g., threshold to trigger IRAT HO) should be adjusted.
22.4.2.4 O&M Requirements
All automatic changes of the HO and/or reselection parameters for mobility robustness optimisation shall be within the range allowed by OAM.
The following control parameters shall be provided by OAM to control MRO behaviour:
– Maximum deviation of Handover Trigger
This parameter defines the maximum allowed absolute deviation of the Handover Trigger (as defined in 22.4.1.4), from the default point of operation defined by the parameter values assigned by OAM.
– Minimum time between Handover Trigger changes
This parameter defines the minimum allowed time interval between two Handover Trigger change performed by MRO. This is used to control the stability and convergence of the algorithm.
Furthermore, in order to support the solutions for detection of Too Late and Too Early HO, the parameter Tstore_UE_cntxt shall be configurable by the OAM system.
OAM may define multiple coverage configurations for each cell served by an eNB. The coverage configuration may also mean a cell is inactive (no coverage). The eNB may dynamically select the most appropriate coverage configuration for its served cells.
22.4.2.5 Inter-RAT ping-pong
One of the functions of Mobility Robustness Optimisation is to detect ping-pongs that occur in inter-RAT environment. The problem is defined as follows:
– A UE is handed over from a cell in a source RAT (e.g. E-UTRAN) to a cell in a target RAT different from the source RAT (e.g. UTRAN), then within a predefined limited time the UE is handed over back to a cell in the source RAT, while the coverage of the source RAT was sufficient for the service used by the UE. The event may occur more than once.
The solution for the problem may consist of the following steps:
1) Statistics regarding inter-RAT ping-pong occurrences are collected by the responsible node.
2) Coverage verification is performed to check if the mobility to other RAT was inevitable.
The statistics regarding ping-pong occurrence may be based on evaluation of the UE History Information IE in the HANDOVER REQUIRED message. If the evaluation indicates a potential ping-pong case and the source eNB of the 1st inter-RAT handover is different than the target eNB of the 2nd inter-RAT handover, the target eNB may use the HANDOVER REPORT message to indicate the occurrence of potential ping-pong cases to the source eNB. The HANDOVER REPORT message for ping-pong indication contains the following information:
– Type of detected handover problem (InterRAT ping-pong);
– ECGI of the source cell in the handover from E-UTRAN to UTRAN;
– ECGI of the target in the handover from UTRAN to E-UTRAN;
– Cell Identifier of the target UTRAN cell in the first inter-RAT handover;
– Cause of the first handover (signalled by the source during handover preparation).
If E-UTRAN coverage during the potential ping-pong event needs to be verified for the purpose of determining corrective measures, the Unnecessary HO to another RAT procedure may be used
22.4.2.6 Dynamic coverage configuration changes
Each eNB may be configured with alternative coverage configurations and an eNB may autonomously select and switch between these configurations, e.g. using the Active Antenna Systems functions.
An eNB may notify its neighbour eNBs about the coverage reconfiguration using the ENB CONFIGURATION UPDATE message with the list of cells with modified coverage included. The list contains the ECGI of each modified cell and its coverage state indicator. The indicator may be used at the receiving eNB to adjust the functions of the Mobility Robustness Optimisation, e.g. by using the indicator to retrieve a previously stored Mobility Robustness Optimisation state. If the list includes indication about planned reconfiguration and possibly a list of replacing cells, the receiving eNB may use this to avoid connection or re-establishment failures during the reconfiguration. Also, if the sending eNB adds cells in inactive state, the receiving eNB may use this information to avoid connection or re-establishment failures.
The receiving node may also use the notification to reduce the impact on mobility. For example, the receiving eNB should avoid triggering handovers towards cell(s) that are indicated to be inactive.
22.4.2.7 Connection failure due to Radio Link Failure in NB-IoT
In NB-IoT, the function of Mobility Robustness Optimization is to detect connection failures due to radio link failure.
Solution for failure scenarios consists of one or more of following functions:
– Detection of the failure after RRC re-establishment attempt;
– Detection of the failure after RRC connection setup;
– Retrieval of information needed for problem analysis.
Triggering of each of these functions is optional and depends on situation and implementation.
Detection of the failure after RRC re-establishment attempt:
UE provides the RLF Report to the eNB after successful RRC connection re-establishment.
Detection of the failure after RRC connection setup:
In case the RRC connection re-establishment fails or the UE does not perform any RRC connection re-establishment, the UE makes the RLF Report available to the eNB after reconnecting from idle mode. Availability of the RLF Report at the RRC connection setup procedure is the indication that a RLF failure occured and that the RLF Report from this occurence could be obtained by the network.
Retrieval of information needed for problem analysis
The information needed for detailed problem analysis may be retrieved from both, the UE and the network sides. The information that is collected at the UE is provided to the network with the RLF Report.
The RLF Report from the UE includes the following information:
– The E-CGI of the last cell that served the UE.
– The radio measurements of the last cell that served the UE.
– Time elapsed from the connection failure till RLF Report signalling.
The eNB receiving the RLF Report from the UE may forward the report to the eNB that served the UE before the reported connection failure using the RLF INDICATION message.
22.4.2.8 Inter-system Ping-Pong
One of the functions of Mobility Robustness Optimization is to detect ping-pongs that occur in inter-system environment. The problem is defined as follows:
– A UE is handed over from a cell in a source system (e.g. E-UTRAN) to a cell in a target system different from the source system (e.g. NG-RAN), then within a predefined limited time the UE is handed over back to a cell in the source system, while the coverage of the source system was sufficient for the service used by the UE. The event may occur more than once.
The solution for the problem may consist of the following steps:
1) Statistics regarding inter-system ping-pong occurrences are collected by the responsible node.
2) Coverage verification is performed to check if the mobility to other system was inevitable.
The statistics regarding ping-pong occurrence may be based on evaluation of the UE History Information IE in the HANDOVER REQUIRED message. If the evaluation indicates a potential ping-pong case and the source E-UTRAN node of the 1st inter-system handover is different than the target E-UTRAN node of the 2nd inter-system handover, the target E-UTRAN node may use the HANDOVER REPORT message to indicate the occurrence of potential ping-pong cases to the source E-UTRAN node.
22.4.3 Support for RACH Optimisation
22.4.3.1 General
The aim of this function is to support RACH Optimisation. RACH optimisation is supported by UE reported information and by RACH parameters exchange between:
– E-UTRA cells;
– NR cells, in case of EN-DC.
22.4.3.2 Solution description
22.4.3.2.1 E-UTRA cell case
The setting of RACH parameters that can be optimized are:
– RACH configuration (resource unit allocation);
– RACH preamble split (among dedicated, group A, group B, RSRP level, NRSRP level (for NB-IoT), NPRACH resource pools (for NB-IoT), EDT);
– RACH backoff parameter value;
– RACH transmission power control parameters.
RACH optimisation is supported by UE reported information and by PRACH parameters exchange or NPRACH parameters (for NB-IoT) between eNBs.
UEs which receive polling signalling shall report the below information:
– Number of RACH preambles sent until the successful RACH completion;
– Contention resolution failure;
– For BL UE or UE in enhanced coverage or NB-IoT UE, the RSRP (NRSRP for NB-IoT) level in which the UE started the random access procedure;
– For BL UE or UE in enhanced coverage or NB-IoT UE, an EDT fallback indication.
UE reporting of RACH information is not supported for a NB-IoT UE using the Control Plane CIoT EPS Optimisation,
22.4.3.2.2 NR cell in EN-DC case
The solution applies to an en-gNB supporting EN-DC operation. RACH optimisation is supported by UE reported information (RACH information report, see TS 38.300 [79]) made available at the eNB and further forwarded to the en-gNB, and by PRACH parameters exchanged (see TS 38.300 [79]) between en-gNBs and eNBs.
22.4.4 Support for Energy Saving
22.4.4.1 General
The aim of this function is to reduce operational expenses through energy savings.
The function allows, for example in a deployment where capacity boosters can be distinguished from cells providing basic coverage, to optimize energy consumption enabling the possibility for a E-UTRA or EN-DC cell or NR cell providing additional capacity via single or dual connectivity, to be switched off when its capacity is no longer needed and to be re-activated on a need basis. The basic coverage may be provided by
– E-UTRAN, UTRAN or GERAN cells, in the case of E-UTRA cells;
– E-UTRA cells, in the case of EN-DC cells.
22.4.4.2 Solution description
22.4.4.2.1 E-UTRA cell case
The solution builds upon the possibility for the eNB owning a capacity booster cell to autonomously decide to switch-off such cell to lower energy consumption (dormant state). The decision is typically based on cell load information, consistently with configured information. The switch-off decision may also be taken by O&M.
The eNB may initiate handover actions in order to off-load the cell being switched off and may indicate the reason for handover with an appropriate cause value to support the target node in taking subsequent actions, e.g. when selecting the target cell for subsequent handovers.
All peer eNBs are informed by the eNB owning the concerned cell about the switch-off actions over the X2 interface, by means of the eNB Configuration Update procedure. The eNB indicates the switch-off action to a GERAN and/or UTRAN node by means of the eNB Direct Information Transfer procedure over S1.
All informed nodes maintain the cell configuration data, e.g., neighbour relationship configuration, also when a certain cell is dormant. If basic coverage is ensured by E-UTRAN cells, eNBs owning non-capacity boosting cells may request a re-activation over the X2 interface if capacity needs in such cells demand to do so. This is achieved via the Cell Activation procedure. If basic coverage is ensured by UTRAN or GERAN cells, the eNB owning the capacity booster cell may receive a re-activation request from a GERAN or UTRAN node by means of the MME Direct Information Transfer procedure over S1. The eNB owning the capacity booster cell may also receive from the sending GERAN or UTRAN node the minimum time before that cell switches off; during this time, the same eNB may prevent idle mode UEs from camping on the cell and may prevent incoming handovers to the same cell.
The eNB owning the dormant cell should normally obey a request. The switch-on decision may also be taken by O&M. All peer eNBs are informed by the eNB owning the concerned cell about the re-activation by an indication on the X2 interface. The eNB indicates the re-activation action to a GERAN and/or UTRAN node by means of the eNB Direct Information Transfer procedure over S1. The eNB owning the concerned cell may choose to delay or not to send indication(s) if the sending GERAN or UTRAN node has included the minimum activation time in the re-activation request.
22.4.4.2.2 EN-DC cell case
The solution applies to an en-gNB supporting EN-DC operation.
The en-gNB may autonomously decide to switch-off NR cells to lower energy consumption. MeNBs are informed by the en-gNB owning the concerned cell about the switch-off actions over the X2 interface, by means of the EN-DC Configuration Update procedure.
The en-gNB may initiate dual connectivity procedures towards the MeNB in order to off-load the cell being switched off, and may indicate the reason for release or modification with an appropriate cause value to support the master node in taking subsequent actions.
The MeNB may request a re-activation over the X2 interface if capacity needs demand to do so. This is achieved via the EN-DC Cell Activation procedure. The en-gNB owning the dormant NR cell should normally obey a request. The switch-on decision may also be taken by O&M. All peer eNBs are informed by the en-gNB owning the concerned NR cell about the re-activation by an indication on the X2 interface.
22.4.4.2.3 NR cell case
For Inter-RAT Inter-system energy saving, in case the eNB provides basic coverage, it may request a NR cell re-activation based on its own cell load information or neighbour cell load information and receive the cell re-activation reply. The switch-on decision may also be taken by O&M. The eNB can be notified of the status of the concerned NR cell. The cell activation, cell activation reply and cell status notification information are transferred over S1 interface and NG interface.
22.4.4.3 O&M requirements
Operators should be able to configure the energy saving function.
The configured information should include:
– The ability of an eNB to perform autonomous cell switch-off.
– The ability of an eNB to request the re-activation of a configured list of dormant cells owned by a peer eNB.
– The ability of an eNB to request the re-activation of a configured list of dormant cells owned by a peer gNB.
O&M may also configure
– policies used by the eNB for cell switch-off decision.
– policies used by peer eNBs for requesting the re-activation of a dormant cell.
22.4.5 Radio Link Failure report
The RLF Report from the UE can be used for both coverage optimisation and mobility robustness optimisation.
Except for NB-IoT, the UE stores the latest RLF or handover failure related information, and indicates RLF report availability at each subsequent LTE RRC connection (re-)establishment and handover to an LTE cell until the RLF report is fetched by the network or for 48 hours after the RLF or handover failure is detected.
Except for NB-IoT, the UE keeps the information during state transitions and RAT changes, and indicates RLF report availability again after it returns to the LTE RAT.
For NB-IoT, the UE stores the latest RLF related information and indicates RLF report availability at the subsequent RRC connections (re-)establishment. The UE discards the RLF report when returning to RRC_IDLE after it has indicated RLF report availability, after 48 hours of the RLF detection, upon power off, upon detach or upon RAT change.
The UE only indicates RLF report availability and only provides the RLF report to the network if the current RPLMN is a PLMN that was present in the UE’s EPLMN List or was the RPLMN at the time the RLF or handover failure was detected.UE reporting of RLF information is not supported for a NB-IoT UE using the Control Plane CIoT EPS Optimisation.