Mobility Management (5G RAN6.1 - Draft A)
Mobility Management (5G RAN6.1 - Draft A)
Mobility Management (5G RAN6.1 - Draft A)
Issue Draft A
Date 2021-12-30
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Website: https://www.huawei.com
Email: support@huawei.com
Contents
1 Change History.........................................................................................................................1
1.1 5G RAN6.1 Draft A (2021-12-30)...................................................................................................................................... 1
3 Overview................................................................................................................................. 19
4 SA Mobility Management in Connected Mode.............................................................. 23
4.1 Basic Functions of Mobility Management in Connected Mode............................................................................26
4.1.1 Principles.............................................................................................................................................................................. 26
4.1.1.1 Basic Procedure............................................................................................................................................................... 26
4.1.1.2 Handover Function Start Decision........................................................................................................................... 28
4.1.1.3 Processing Mode Selection......................................................................................................................................... 28
4.1.1.4 Measurement Configuration Delivery..................................................................................................................... 28
4.1.1.4.1 Measurement Object................................................................................................................................................. 29
4.1.1.4.2 Reporting Configuration...........................................................................................................................................31
4.1.1.4.3 Other Configurations.................................................................................................................................................46
4.1.1.5 Measurement Reporting.............................................................................................................................................. 52
4.1.1.6 Target Cell or Frequency Decision............................................................................................................................ 53
4.1.1.7 Handover Execution...................................................................................................................................................... 57
4.1.1.8 Handover Failure Penalty............................................................................................................................................ 61
4.1.2 Network Analysis............................................................................................................................................................... 62
4.1.2.1 Benefits.............................................................................................................................................................................. 62
4.1.2.2 Impacts.............................................................................................................................................................................. 63
4.1.3 Requirements...................................................................................................................................................................... 64
4.1.3.1 Licenses.............................................................................................................................................................................. 64
4.1.3.2 Software............................................................................................................................................................................ 64
4.1.3.3 Hardware.......................................................................................................................................................................... 64
4.1.3.4 Others................................................................................................................................................................................ 65
4.1.4 Operation and Maintenance......................................................................................................................................... 66
9 Parameters............................................................................................................................232
10 Counters.............................................................................................................................. 233
11 Glossary............................................................................................................................... 234
12 Reference Documents...................................................................................................... 235
1 Change History
Technical Changes
Change Description Parameter Change RAT Base Station Model
● 4.1.1.4.2
Reporting
Configuration
● 4.3.4.1 Data
Configuration
● 4.4.4.1 Data
Configuration
● 4.5.4.1 Data
Configuration
● 4.6.4.1 Data
Configuration
● 4.7.4.1 Data
Configuration
Editorial Changes
Optimized descriptions of principles of measurement configuration delivery for
frequency-priority-based inter-frequency handover. For details, see Measurement
Configuration Delivery.
Modified the conditions for determining neighboring cells exposed to low uplink
interference specific to uplink-interference-based inter-frequency handover. For
details, see Target Cell or Frequency Decision.
Added the signaling procedures for mobility management in SA networking. For
details, see 8 Appendix.
Revised descriptions in this document.
This document only provides guidance for feature activation. Feature deployment and
feature gains depend on the specifics of the network scenario where the feature is
deployed. To achieve optimal gains, contact Huawei professional service engineers.
Software Interfaces
Any parameters, alarms, counters, or managed objects (MOs) described in Feature
Parameter Description documents apply only to the corresponding software
release. For future software releases, refer to the corresponding updated product
documentation.
5 SA Mobility
Management in
Idle Mode
7 NSA Mobility
Management in
Connected Mode
3 Overview
NOTE
For details about the RRC states, see section 4.2.1 "UE states and state transitions
including inter RAT" in 3GPP TS 38.331 V15.5.1.
SA Mobility Management
An SA network uses an end-to-end 5G network architecture, where the terminals,
base stations, and core network comply with 5G specifications. Figure 3-2 shows
SA networking. For details, see 5G Networking and Signaling.
NSA networking does not support the RRC_INACTIVE state. Therefore, in the
current version, NSA mobility management is categorized based on the UE's RRC
state as follows:
UTRAN and NG-RAN. For details, see Interoperability Between E-UTRAN and NG-
RAN.
4.3 Coverage- ● The specific function switch is turned on. Event A1 is ● Event A5 or
based Inter- – Handover: The COVERAGE_BASED_HO received. A3 is
Frequency option of the received.
Handover NRCellAlgoSwitch.InterFreqHoSwitch ● The serving
parameter is selected. cell is
– Redirectionb: The REDIRECTION option configured
of the with
NRCellAlgoSwitch.InterFreqHoSwitch neighboring
parameter is selected. cellsc.
● Event A2 is received.
4.6 Service- ● A UE initiates a service with a QCI that has N/A ● Event A4 or
based Inter- the highest priority. A5 is
Frequency ● The SERVICE_BASED_HO option of the received.
Handover NRCellAlgoSwitch.InterFreqHoSwitch ● The serving
parameter is selected. cell is
● The base station checks the priority of a configured
QoS flow when deciding whether to start with
service-based inter-frequency handover. neighboring
cells.
● The service with this QCI is associated with
a target frequency group.
● The serving frequency of the UE is not
within the target frequency range desired
for this service.
Note:
a: For details about the events, see Measurement Event.
b: Handover policies consist of handover and redirection. For details, see Determination of a
Handover Policy.
c: Blind redirection does not have requirements for neighboring cell configurations. For details, see
4.3 Coverage-based Inter-Frequency Handover.
NOTE
4.1.1 Principles
This section describes the basic principles and mechanisms of SA mobility
management in connected mode. The detailed signaling procedure complies with
3GPP specifications. For details, see:
● Section 9.2.3 "Mobility in RRC_CONNECTED" in 3GPP TS 38.300 V15.6.0
● Sections 5.3.5 "RRC reconfiguration" and 5.3.7 "RRC connection re-
establishment" in 3GPP TS 38.331 V15.5.1
● Section 8.4 "UE Mobility Management Procedures" in 3GPP TS 38.413 V15.3.0
5. 4.1.1.6 Target Cell or Frequency Decision describes how the gNodeB selects
a handover policy and generates target cells or frequencies for a handover.
6. 4.1.1.7 Handover Execution describes how the gNodeB and UEs execute the
handover based on the handover policy.
7. 4.1.1.8 Handover Failure Penalty describes the penalty mechanism for UE
handover failures.
Depending on whether UEs measure the signal quality of candidate target cells
before a handover, the processing mode is classified into measurement-based
mode and blind mode.
● Measurement-based mode: UEs measure the signal quality of a measurement
object on the per-frequency basis and report the results to the gNodeB based
on the measurement configurations delivered from the gNodeB. The gNodeB
then uses the measurement report to generate a target cell list.
● Blind mode: The gNodeB generates a target cell or frequency list based on
priority parameter configurations without instructing UEs to measure the
signal quality of candidate target cells.
NOTE
In blind mode, accessing a target cell has a high risk of failure due to the uncertain signal
quality of the target cell. As such, blind mode is not recommended in most cases. This
mode is only used when a quick handover is needed. Blind mode is widely used in high-
frequency scenarios. In these scenarios, mmWave signals attenuate quickly during
transmission and provide a limited coverage range due to high frequencies and short
wavelengths. When a UE moves at a high speed (for example, in high-speed railway
scenarios), the UE may have moved out of the source cell before the measurement of the
target cell or frequency is completed in measurement-based mode. Consequently, the
service drop rate increases. To prevent this, blind mode can be used, in which case a
handover is quickly implemented for the UE. However, blind mode has high requirements
on neighboring cell planning. In the case of improper neighboring cell planning, the UE
may experience an access failure.
Intra-frequency measurement refers to measuring cells that have the same SSB
frequency and SSB frequency subcarrier spacing (SCS) as the serving cell,
regardless of whether their bandwidths are the same or not. Inter-frequency
measurement refers to measuring cells that have different SSB frequencies from
the serving cell, or those that have the same SSB frequency as the serving cell but
different SSB frequency SCS.
● For intra-frequency measurement, the gNodeB sends the NR frequencies
determined by the NRDUCell.SsbDescMethod and NRDUCell.SsbFreqPos
parameters for measurement.
● For inter-frequency measurement:
– Common policy for inter-frequency measurement: If no RFSP-based inter-
frequency measurement policy is configured, the gNodeB selects the
frequencies to be sent for measurement based on the following common
policy (RFSP is short for RAT/Frequency Selection Priority):
● If this parameter is not set to 0, the cell information selected from the NRT is
sent for the measurement object.
Table 4-2 lists the protocol-defined maximum number of neighboring cells
that can be delivered for each measurement object. For details, see section 6.4
"RRC multiplicity and type constraint values" in 3GPP TS 38.331 V16.5.0.
Table 4-2 Maximum number of neighboring cells that can be delivered for
each measurement object
● If this parameter is set to 0, the cell information is not sent for the
measurement object.
● Measurement event, which can be A1, A2, A3, A4, A5, A6, B1, or B2. Handover
functions determine the measurement events to be used. For details, see the
sections corresponding to each handover function. For details about the
definition, entering conditions, and leaving conditions for each event, see
Measurement Event.
● Triggering quantity, which specifies the policy used to trigger event reporting
and can be reference signal received power (RSRP), reference signal received
quality (RSRQ), or signal to interference plus noise ratio (SINR). This version
supports SSB RSRP or RSRQ. For details, see Triggering Quantity.
Measurement Event
An event indicates signal quality. Table 4-3 lists the definition of each event.
A5 The signal quality of the serving cell is below threshold 1 and the
signal quality of a neighboring cell exceeds threshold 2.
B2 The signal quality of the serving cell is below threshold 1 and the
signal quality of an inter-RAT neighboring cell exceeds threshold
2.
A1 (Ms – Hys > Thresh) is (Ms + Hys < Thresh) is See Table 4-5.
true during the time true during the time
specified by TimeToTrig. specified by TimeToTrig.
A2 (Ms + Hys < Thresh) is (Ms – Hys > Thresh) is See Table 4-6.
true during the time true during the time
specified by TimeToTrig. specified by TimeToTrig.
A3 (Mn + Ofn + Ocn – Hys > (Mn + Ofn + Ocn + Hys < See Table 4-7.
Ms + Ofs + Ocs + Off) is Ms + Ofs + Ocs + Off) is
true during the time true during the time
specified by TimeToTrig. specified by TimeToTrig.
A4 (Mn + Ofn + Ocn – Hys > (Mn + Ofn + Ocn + Hys < See Table 4-8.
Thresh) is true during the Thresh) is true during the
time specified by time specified by
TimeToTrig. TimeToTrig.
A5 (Ms + Hys < Thresh1) (Ms – Hys > Thresh1) or See Table 4-9.
and (Mn + Ofn + Ocn – (Mn + Ofn + Ocn + Hys <
Hys > Thresh2) are true Thresh2) is true during
during the time specified the time specified by
by TimeToTrig. TimeToTrig.
A6 (Mn + Ocn – Hys > Ms + (Mn + Ocn + Hys < Ms + Applicable to
Ocs + Off) is true during Ocs + Off) is true during carrier
the time specified by the time specified by aggregation
TimeToTrig. TimeToTrig. (CA). For
details, see
Carrier
Aggregation.
B1 (Mn + Ofn + Ocn – Hys > (Mn + Ofn + Ocn + Hys < Applicable to
Thresh) is true during the Thresh) is true during the inter-RAT
time specified by time specified by scenarios. For
TimeToTrig. TimeToTrig. details, see
Interoperability
Between E-
UTRAN and
NG-RAN.
B2 (Ms + Hys < Thresh1) (Ms – Hys > Thresh1) or Applicable to
and (Mn + Ofn + Ocn – (Mn + Ofn + Ocn + Hys < inter-RAT
Hys > Thresh2) are true Thresh2) is true during scenarios. For
during the time specified the time specified by details, see
by TimeToTrig. TimeToTrig. Interoperability
Between E-
UTRAN and
NG-RAN.
● Ms and Mn: measurement results of the serving cell and a neighboring cell,
respectively
● Hys: hysteresis for an event
● TimeToTrig: duration during which a condition is met before the event can be
triggered
Entering condition for event A2: (Ms + Hys < Thresh) is true throughout the
duration specified by TimeToTrig. Table 4-6 describes the parameters for the
variables.
Entering condition for event A3: (Mn + Ofn + Ocn – Hys > Ms + Ofs + Ocs + Off) is
true throughout the duration specified by TimeToTrig. Table 4-7 describes the
parameters for the variables.
Entering condition for event A4: (Mn + Ofn + Ocn – Hys > Thresh) is true
throughout the duration specified by TimeToTrig. Table 4-8 describes the
parameters for the variables.
Entering condition for event A5: (Ms + Hys < Thresh1) and (Mn + Ofn + Ocn – Hys
> Thresh2) are true throughout the duration specified by TimeToTrig. Table 4-9
describes the parameters for the variables.
Triggering Quantity
Triggering quantity specifies the policy used to trigger event reporting and can be
RSRP, RSRQ, or SINR. This version supports SSB RSRP, SINR, or RSRQ. Further
details are as follows:
● Only RSRP: Measurement is triggered and stopped based only on the RSRP.
The gNodeB sends only the RSRP-indicating measurement configuration
related to an event to a UE, based on which the UE performs measurements.
When determining that the measured RSRP of a frequency (or cell) meets the
entering conditions (as indicated in Table 4-4) for the event, the UE sends a
measurement report to the gNodeB.
● RSRP and RSRQ: Measurement is triggered and stopped based on both the
RSRP and RSRQ, and the RSRP-based process is independent of the RSRQ-
based process. The gNodeB sends both RSRP- and RSRQ-indicating
measurement configurations related to an event to a UE, based on which the
UE performs measurements. When determining that the measured RSRP or
RSRQ of a frequency (or cell) meets the entering conditions (as indicated in
Table 4-4) for the event, the UE sends a measurement report to the gNodeB.
● RSRP combined with RSRQ-based filtering: Measurement is triggered and
stopped based only on the RSRP, but a measurement report includes both the
measured RSRP and RSRQ. Specific neighboring cells are filtered out based on
the measured RSRQ. The gNodeB sends both RSRP- and RSRQ-indicating
measurement configurations related to an event to a UE, based on which the
UE performs measurements. When determining that the measured RSRP of a
frequency (or cell) meets the entering conditions (as indicated in Table 4-4)
for the event, the UE sends the gNodeB a measurement report including the
measured RSRP and RSRQ. Then, the gNodeB generates a candidate cell list
or a candidate frequency list based on the measured RSRP, and filters out
specific candidate cells based on the measured RSRQ. For details about RSRQ-
based filtering, see Generation of a Target Cell or Frequency List.
● Only SINR: Measurement is triggered and stopped based only on the SINR.
The gNodeB sends only the SINR-indicating measurement configuration
related to an event to a UE, based on which the UE performs measurements.
When determining that the measured SINR of a frequency (or cell) meets the
entering conditions (as indicated in Table 4-4) for the event, the UE sends a
measurement report to the gNodeB.
Table 4-10 lists the triggering quantities specific to handover functions. For
details, see the sections corresponding to each handover function.
Handover Function Event That Triggers Event That Stops a Event That Triggers the
the Start of a Handover Function Execution of a
Handover Function Handover
4.4 Frequency- Event A1: only RSRP Event A2: only RSRP Event A4: only RSRP
Priority-based Event A5: only RSRP
Inter-Frequency
Handover
4.8 SSB SINR-based Event A2: only SINR Event A1: only SINR Event A3: only RSRP
Inter-Frequency
Handover
NOTE
SMTC is specific to frequencies. If the cells on the same frequency have different SSB
periods (configured by the NRDUCell.SsbPeriod parameter), SSB measurements may
be inaccurate for the cells whose SSB periods are longer than the corresponding SMTC
period. To prevent this, ensure that the cells on the same frequency use the same SSB
period (configured by the NRDUCell.SsbPeriod parameter) according to the network
plan.
● The SMTC duration determines the time during which the UE performs SSB
measurements in each SMTC period. It is configured by the
NRDUCell.SmtcDuration parameter for intra-frequency measurements and
by the NRCellFreqRelation.SmtcDuration parameter for inter-frequency
measurements.
The NRDUCell.SmtcDuration and NRCellFreqRelation.SmtcDuration
parameters take effect only for low frequency bands. The system
automatically calculates the SMTC duration for high frequency bands.
● The SMTC offset determines the time offset for the UE to start SSB
measurements in each SMTC period. The offset is calculated by the gNodeB to
ensure accurate SSB measurements by the UE. The following configurations
affect the SMTC offset calculation. If they do not meet the corresponding
requirements, the SSB measurement result may be inaccurate.
The frame offsets (specified by the gNBFreqBandConfig.FrameOffset
parameter) of frequency bands must meet all of the following conditions:
– The frame offset of a frequency band must be the same for all base
stations on the entire network.
– If the frame offsets for the to-be-measured frequency bands differ, the
maximum difference must not exceed 3 ms.
– If the frame offsets for the serving and to-be-measured frequency bands
differ, the maximum difference must not exceed 4 ms.
– If the frame offset of a frequency band is configured on a base station on
the network, the frame offset of this band must also be specified on
neighboring base stations, even if these neighboring base stations do not
serve any cell in this band. This ensures that this frequency band is
accurately measured by UEs served by these neighboring base stations.
NOTE
If frame offsets are different between frequency bands, the measurement gap
configured for a UE must be sufficient to include the SMTC duration of cells in
different frequency bands, reducing the throughput during inter-frequency
measurements. If the maximum difference between said frame offsets exceeds 3 ms,
the measurement gap is insufficient to include the SMTC duration of all cells. As a
result, inter-frequency measurement is incomplete, affecting the handover success
rate.
In cases where the frame offsets for the serving and to-be-measured frequency bands
differ and the maximum difference exceeds 4 ms, the gNodeB cannot send a
measurement gap. As a result, inter-frequency measurement is incomplete, affecting
the handover success rate. For details, see Measurement Gap Configuration.
For details about frame offsets of frequency bands, see Standards Compliance.
Time synchronization between the serving cell and the cell to be measured
affects the calculation of the SMTC offset. The following applies only when
the cell to be measured is an NR FDD cell and the serving cell is an NR FDD
cell or NR TDD cell:
– If time synchronization is configured with its precision being +/- 1.5 μs,
you are advised to set the intra-frequency SMTC duration (specified by
NRDUCell.SmtcDuration) and the inter-frequency SMTC duration
(specified by NRCellFreqRelation.SmtcDuration) to their recommended
values.
– If time synchronization is configured with its precision being +/- 500 μs
(indicating that 1588V2 loose time synchronization takes effect), you are
advised to set both the intra-frequency SMTC duration (specified by
NRDUCell.SmtcDuration) and the inter-frequency SMTC duration
(specified by NRCellFreqRelation.SmtcDuration) to 4 ms or 5ms.
If both the intra- and inter-frequency SMTC durations are set to 5 ms, UE
compatibility issues may occur. In this context, Huawei introduces the
SMTC offset compatibility function, which is controlled by the
SMTC_OFFSET_COMPAT_SW option of the
NRDUCellAlgoSwitch.AlgoCompatibilitySwitchExt parameter. This
function can be enabled when the serving cell is an NR FDD cell or a low-
frequency NR TDD cell.
▪ If this option is deselected for the serving cell and 1588V2 loose time
synchronization takes effect, UE compatibility issues may occur when
both the intra- and inter-frequency SMTC durations are set to 5 ms.
UEs with compatibility issues may encounter the following situations:
repeated SgNB addition and release in NSA networking; service drops
in SA networking.
▪ If this option is selected for the serving cell and 1588V2 loose time
synchronization takes effect, UE compatibility issues do not occur
when both the intra- and inter-frequency SMTC durations are set to
5 ms. In this case, however, incomplete intra-frequency SSB
measurements may decrease the RRC connection setup success rate
and handover success rate, and incomplete inter-frequency SSB
measurements may decrease the handover success rate.
– If time synchronization is not configured, inter-base-station handovers
may fail due to exceptions in neighboring cell measurements. Therefore,
the clock synchronization mode of the gNodeB must be set to time
synchronization.
For details about time synchronization or frequency synchronization, see
Synchronization.
which reduces the uplink and downlink throughput of those UEs. In addition,
when the PUCCH SR period is greater than or equal to the gap repetition period,
PUCCH SR may conflict with gap-assisted measurement in the time domain. As a
result, service drops occur. In this version, the function of non-overlapping
between gap and NR resources is now supported in low-frequency SA networking,
which staggers the channel resources of specific signals (SRS, PUCCH SR, CSI-RS
for CM, and CSI-RS for CM measurement reporting) from the measurement gap in
the time domain. The GAP_AVOID_NR_RES_SW option of the
gNBMobilityCommParam.MeasAlgoSwitch parameter specifies whether to
enable the function of non-overlapping between gap and NR resources.
● If this option is deselected, the channel resources of the said signals are not
staggered from the measurement gap in the time domain. In this case, the
measurement gap preferentially takes effect on UEs, which do not transmit or
receive signals during the measurement gap.
● If this option is selected, the channel resources of the said signals are
staggered from the measurement gap in the time domain. This setting
reduces the loss in uplink and downlink UE throughput caused by gap-
assisted measurement and the rate of service drops caused by conflicts
between PUCCH SR and gap-assisted measurement but prolongs the
measurement duration.
Measurement ID Preemption
A measurement ID links a measurement object with a reporting configuration as a
set. Given a measurement ID, a UE measures the associated measurement object
according to the reporting configuration. With multiple measurement IDs
configured, it is possible to link multiple measurement objects to the same
reporting configuration, as well as to link multiple reporting configurations to the
same measurement object. Figure 4-3 provides an example, in which both
measObjectID 1 and measObjectID 2 are linked to reportConfigID 1, and
event are met, the UE periodically sends measurement reports to the gNodeB. In
this version, UEs send reports at fixed intervals of 240 ms in SSB SINR-based inter-
frequency handover and 320 ms in other handover functions, as indicated by the
reportInterval IE (MeasConfig > ReportConfigToAddModList) in the
RRCReconfiguration message.
● Unless otherwise stated, handover is used in this chapter as a generic term that covers
procedures related to mobility management in connected mode.
● When referred to as a handover policy, handover is a specific term in contrast to
redirection and describes a procedure in which the serving cell of a UE changes.
● To perform a medium-priority blocking for a cell, the RRC_CONNECTED UEs in the cell
must be migrated out. The gNodeB selects redirection for transferring UEs out of the
cell.
Note:
● When configuring the gNBEqvPlmn MO, ensure that there is a
roaming agreement between the PLMN corresponding to
gNBEqvPlmn.OperatorId and the EPLMN collectively determined by
gNBEqvPlmn.EquivalentMcc and gNBEqvPlmn.EquivalentMnc.
● The PLMNs that are graylisted or blacklisted using the PLMN ID
management function are excluded from those allowed for UE
handovers. For details about the PLMN ID management function,
see ANR.
– The gNodeB filters out the neighboring cells whose uplink and downlink
bandwidths are not supported by UEs. The conditions for this are as
follows:
▪ Inter-base-station handover:
○ If an Xn interface is set up between the gNodeB and a
neighboring base station, the gNodeB can obtain the uplink and
downlink bandwidths of inter-base-station neighboring cells. In
this scenario, if the minimum bandwidth supported by a UE is
greater than the downlink bandwidth and uplink bandwidth of
an inter-base station neighboring cell, the gNodeB filters out the
neighboring cell.
○ If an Xn interface is not set up between the gNodeB and a
neighboring base station, the gNodeB cannot obtain the uplink
and downlink bandwidths of inter-base-station neighboring cells.
In this scenario, the gNodeB does not filter out such neighboring
cells based on UE bandwidth capabilities.
The minimum bandwidths supported by a UE can be obtained from the
channelBWs-UL, channelBWs-DL, channelBWs-UL-v1590, and
channelBWs-DL-v1590 IEs in the UECapabilityInformation IE signaled over
the Uu interface. For details, see section 4.2 "UE Capability Parameters"
in 3GPP TS 38.306 V16.5.0.
▪ If both RSRP and RSRQ are used as the triggering quantities for
event A2 related to coverage-based inter-frequency measurements,
the gNodeB filters out the cells whose RSRP is less than the result of
"NRCellInterFHoMeaGrp.CovInterFreqA2RsrpThld –
NRCellInterFHoMeaGrp.InterFreqA1A2Hyst" and the cells whose
RSRQ is less than the result of
"NRCellInterFHoMeaGrp.CovInterFreqA2RsrqThld –
NRCellInterFHoMeaGrp.InterFreqA1A2Hyst".
The RSRP_AND_RSRQ_SW option of the
NRCellMobilityConfig.A1A2MeasTrigQty parameter determines the
triggering quantity for event A2.
Handover
Figure 4-4 shows the procedure when the handover policy is handover.
1. Inter-AMF-region determination: The source gNodeB selects the cell with the
best quality from the target cell or frequency list and then starts inter-AMF-
region determination.
If the gNodeB serving the source cell and the gNodeB serving the target cell
belong to different AMF regions, an NG-based handover request is sent. In
this case, the procedure goes to 4.
If the gNodeB serving the source cell and the gNodeB serving the target cell
belong to the same AMF region, the procedure goes to 2.
2. Target gNodeB determination: The source gNodeB determines whether the
target cell is served by a different base station.
– If the source cell and the target cell are served by the same gNodeB,
handover execution is performed. In this case, the procedure goes to 5.
– If the target cell is served by a different gNodeB from the source cell, the
procedure goes to 3.
3. Handover link selection: The source gNodeB initiates an Xn- or NG-based
handover request.
– If an Xn link exists between the gNodeB serving the source cell and the
gNodeB serving the target cell, the source gNodeB initiates an Xn-based
handover request. In this case, the procedure goes to 4.
– If no Xn link is present between the gNodeB serving the source cell and
the gNodeB serving the target cell, the source gNodeB initiates an NG-
based handover request. In this case, the procedure goes to 4.
4. Handover preparation: After receiving the handover request, the target
gNodeB prepares for the handover and responds with the preparation result.
– If the admission to the target gNodeB succeeds, the target gNodeB sends
a Handover Request Acknowledge or Handover Command message to
the source gNodeB. As such, the source gNodeB considers the handover
preparation to have succeeded and initiates handover execution. In this
case, the procedure goes to 5.
– If the admission to the target gNodeB fails, the target gNodeB sends a
Handover Preparation Failure message to the source gNodeB.
Redirection
If the handover policy is redirection, the gNodeB selects the cell of the highest-
priority frequency from the target cell or frequency list, and sends it to the UE
through an RRC Release message. The UE then performs redirection.
This function applies to all 5QI-specific QoS flow procedures. It can be enabled for a specific
5QI by binding the 5QI to the NRCellQciBearer.Qci parameter. Note that among services
carried on bearers with 5QI 1 (with the NRCellQciBearer.Qci parameter set to 1), this
function is only applicable to bearers carrying VoNR services. For details about the conflict
handling between 5QI-1-based voice fallback and handover, see Conflict Handling
Between Handover and Voice Fallback.
For handover preparation failures with the cause value "Transport resource
unavailable", the following applies within the penalty time:
● If the UE involved is an NSA DC UE, the NSA DC UEs that are connected to
the same eNodeB and served by the same PLMN as this NSA DC UE cannot
initiate handover attempts to the target cell.
● If the UE involved is an SA UE, the SA UEs that are served by the same PLMN
as this SA UE cannot initiate handover attempts to the target cell.
● After cell A enters the penalty state, the number of penalty times is incremented by one
each time the measurement result indicates that cell A meets the handover condition.
● Retry means that a request for a handover to cell A is sent again when this cell meets
the handover condition after the specified penalties imposed on it have ended.
● Resource-caused handover preparation failures are only those whose failure causes are
as follows:
● No radio resources available in target cell
● Transport resource unavailable
● Not enough User Plane Processing Resources
● Radio resources not available
● Control Processing Overload
4.1.2.1 Benefits
This function selects the cell with the best quality for UEs in RRC_CONNECTED
mode to transmit data, ensuring continuous coverage and providing users with
seamless service experience.
Non-overlapping between gap and NR resources reduces the loss in uplink and
downlink UE throughput caused by gap-assisted measurement and the rate of
service drops caused by conflicts between PUCCH SR and gap-assisted
measurement but prolongs the measurement duration. Due to cell-level
measurement, the values of the following indicators may also change after the
function of non-overlapping between gap and NR resources is enabled.
Specifically, the values of N.ThpTime.UL.Cell (duration of uplink data
transmission at the MAC layer in a cell) and N.ThpTime.DL.Cell (duration of
downlink data transmission at the MAC layer in a cell) may increase, and those of
Cell Uplink Average Throughput (DU) (average uplink cell throughput) and Cell
Downlink Average Throughput (DU) (average downlink cell throughput) may
decrease.
Enabling optimized configuration for deriveSSB-IndexFromCell results in the
following impacts: In TDD, the efficiency and accuracy of detecting neighboring
cells' SSB indexes is improved as cells working on TDD frequencies are time-
synchronized. In FDD, network performance is not affected.
4.1.2.2 Impacts
Network Impacts
The values of the following counters (related to canceled handovers) will increase
if a handover procedure conflicts with a voice fallback procedure or an emergency
call voice fallback procedure and the VOICE_FB_FIRST_SWITCH option of the
gNBMobilityCommParam.HoPduSessConflHandlingSw parameter is selected. It
is recommended that the handover cancellation times indicated by such counters
be deducted during the calculation of the outgoing handover success rate.
● N.HO.IntraFreq.Prep.FailOut.HOCancel
● N.HO.IntraFreq.FailOut.HOCancel
● N.HO.InterFreq.Prep.FailOut.HOCancel
● N.HO.InterFreq.FailOut.HOCancel
Function Impacts
RAT Function Function Reference Description
Name Switch
4.1.3 Requirements
4.1.3.1 Licenses
There are no license requirements.
4.1.3.2 Software
Prerequisite Functions
None
4.1.3.3 Hardware
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules support this function. For details, see the technical
specifications of RF modules in 3900 & 5900 Series Base Station Product
Documentation.
4.1.3.4 Others
● If there are multiple AMFs, the core network must support inter-AMF
handovers.
● If an AMF region is planned on the core network, the gNodeB must support
at least one network slice in the AMF region and connect to all AMFs in the
AMF set corresponding to the network slice.
● For an intra-base-station handover, if the source cell and target cell are in the
same PLMN, they cannot belong to different AMFs in the same AMF region.
Otherwise, the UE registration update fails after the intra-base-station
handover is complete, resulting in a service drop. As such, during network
planning, cells in the same PLMN under a base station need to be mapped to
the same AMF through the TACs.
● In NR FDD, the clock synchronization mode of the gNodeB must be set to
time synchronization. For details about time synchronization, see
Synchronization.
● During the configuration of external cells (through the NRExternalNCell
MO):
– If the NRExternalNCell.NrNetworkingOption parameter is set to NSA,
no tracking area code (TAC) needs to be planned. In this case, you are
advised to set the TAC to an invalid value (4294967295).
– If the NRExternalNCell.NrNetworkingOption parameter is set to SA or
SA_NSA, a TAC equal to the actual TAC of the external cell must be
configured. Otherwise, handovers may fail.
● Xn-based handovers have the following requirements for the target gNodeB:
The target gNodeB must comply with 3GPP TS 38.423 V15.5.0 or later.
Otherwise, Xn-based handovers will fail as the source gNodeB complies with
3GPP TS 38.423 V15.5.0 or later. Consequently, the function of protocol
compatibility processing for Service Area Information exchanged between
base stations has been introduced. This function is controlled by the
XN_SERVICE_AREA_INFO_PROC_SW option of the
gNodeBParam.CompatibilityAlgoSwitch parameter. It is recommended that
this option be deselected when the source and target gNodeBs comply with
different protocol versions.
– If this option is selected, Huawei base stations signal the Service Area
Information IE and process this IE in compliance with 3GPP TS 38.423
V15.5.0 or later.
– If this option is deselected, Huawei base stations do not signal the Service
Area Information IE and they process this IE after receiving it in
compliance with 3GPP TS 38.423 V15.4.0 or earlier. With this setting, Xn-
based handovers can succeed, but UEs may be handed over to the
forbidden cells indicated by the Mobility Restriction List IE in the INITIAL
CONTEXT SETUP REQUEST message sent from the AMF.
● Compared with 3GPP TS 38.423 V16.6.0, 3GPP TS 38.423 V16.7.0 introduced a
non-compatibility change in the definition of the UE Security Capabilities IE.
For details, see section 9.2.3.49 "UE Security Capabilities" in 3GPP TS 38.423
V16.7.0. During an Xn-based handover, the target gNodeB processes the UE
Security Capabilities IE in the Handover Request message sent by the source
gNodeB to select a ciphering algorithm. If the two base stations comply with
different protocols during the processing, a protocol compatibility issue
occurs. To prevent handover failures due to protocol inconsistency between
the source and target gNodeBs, Huawei gNodeBs have optimized the
compatibility processing in accordance with 3GPP TS 38.423 V16.7.0. This
optimization is controlled by the XN_UE_SECURITY_CAP_PROC_SW option of
the gNodeBParam.CompatibilityAlgoSwitch parameter. It is recommended
that this option be selected when a Huawei gNodeB is connected to a non-
Huawei gNodeB over the Xn interface and the non-Huawei gNodeB signals
the Handover Request message containing the UE Security Capabilities IE in
compliance with 3GPP TS 38.423 V16.7.0.
– When this option is selected, Huawei gNodeBs signal the UE Security
Capabilities IE and process this IE in compliance with 3GPP TS 38.423
V16.7.0.
– When this option is deselected, Huawei gNodeBs signal the UE Security
Capabilities IE and process this IE in compliance with 3GPP TS 38.423
V16.6.0.
NOTE
● Maximum number of external NR cells that can be configured for a gNodeB: Maximum
number of cells supported by the gNodeB x 32
● Maximum number of neighboring NR cells that can be configured for an NR cell: 384
● Maximum number of neighboring NR cells that can be configured for a gNodeB:
Maximum number of cells supported by the gNodeB x 256
The NRExternalNCell MO defines external NR cells, and the NRCellRelation MO defines
neighboring NR cells. For details about the maximum number of cells supported by a
gNodeB, see "Capacity Specifications" in the corresponding BBU technical specifications in
3900 & 5900 Series Base Station Product Documentation.
4.2.1 Principles
Coverage-based intra-frequency handover is a basic function that ensures
continuous coverage. Measurement configurations are sent after RRC connections
are set up. A handover is executed when a target cell that meets the specific
requirement is available, requiring no handover function start decision. This
handover function does not apply to the blind mode. Figure 4-6 shows the
procedure of coverage-based intra-frequency handover. This section describes the
differences between this function and the basic handover functions presented in
4.1 Basic Functions of Mobility Management in Connected Mode.
For details about the definition, entering conditions, and leaving conditions for
event A3, see Measurement Event. For the variable configurations for event A3,
see Table 4-7.
4.2.2.1 Benefits
Coverage-based intra-frequency handovers reduce interference caused by intra-
frequency neighboring cells in SA intra-frequency networking, thereby reducing
the service drop rate and providing users with seamless service experience.
4.2.2.2 Impacts
Network Impacts
During a handover, the UE needs to synchronize with the target cell and initiate
random access. This increases delay due to service interruption, affecting
throughput.
Function Impacts
None
4.2.3 Requirements
4.2.3.1 Licenses
There are no license requirements.
4.2.3.2 Software
Prerequisite Functions
None
4.2.3.3 Hardware
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules support this function. For details, see the technical
specifications of RF modules in 3900 & 5900 Series Base Station Product
Documentation.
4.2.3.4 Others
None
4.3.1 Principles
NOTE
▪ Both RSRP and RSRQ are used as the triggering quantities for event
A2 related to coverage-based inter-frequency measurements.
The gNodeB receives a measurement report indicating that the
measured RSRP of a frequency (or cell) meets the entering
conditions for event A2 (indicating the signal quality of the serving
cell drops below a specific threshold) related to coverage-based
inter-frequency measurements. Alternatively, it receives a
measurement report indicating that the measured RSRQ of a
frequency (or cell) meets the entering conditions for event A2
(indicating the signal quality of the serving cell drops below a
specific threshold) related to coverage-based inter-frequency
measurements.
● If this option is deselected, only RSRP is used as the triggering quantity. The
gNodeB sends only the RSRP-indicating measurement configuration related to
event A2 to a UE, based on which the UE performs measurements. When
determining that the measured RSRP of a frequency (or cell) meets the
entering conditions for the event, the UE sends a measurement report to the
gNodeB to trigger a handover or redirection.
● If this option is selected, both RSRP and RSRQ are used as the triggering
quantities. The gNodeB sends both RSRP- and RSRQ-indicating measurement
configurations related to event A2 to a UE, based on which the UE performs
measurements. When determining that the measured RSRP or RSRQ of a
frequency (or cell) meets the entering conditions for the event, the UE sends
a measurement report to the gNodeB to trigger a handover or redirection.
For details about the definition, entering conditions, and leaving conditions for
event A2, see Measurement Event. For the variable configurations for event A2,
see Table 4-6.
conditions for the event, the UE sends a measurement report to the gNodeB.
The gNodeB then determines the target cells or frequencies based on the
measurement report.
● If this parameter is set to INTRF for a frequency, RSRP is used as the
triggering quantity, combined with RSRQ-based filtering. The gNodeB sends
both RSRP- and RSRQ-indicating measurement configurations related to
event A5 to a UE, based on which the UE performs measurements. When
determining that the measured RSRP of a frequency (or cell) meets the
entering conditions for event A5, the UE sends the gNodeB a measurement
report including the measured RSRP and RSRQ. Then, the gNodeB generates a
candidate cell list or a candidate frequency list based on the measured RSRP,
and filters out specific candidate cells based on the measured RSRQ. For
details about RSRQ-based filtering, see Generation of a Target Cell or
Frequency List.
Only RSRP is used as the triggering quantity for event A3 related to coverage-
based inter-frequency measurements. The gNodeB sends only the RSRP-indicating
measurement configuration related to event A3 to a UE, based on which the UE
performs measurements. When determining that the RSRP meets the entering
conditions for the event, the UE sends a measurement report to the gNodeB. The
gNodeB then determines the target cells or frequencies based on the
measurement report.
For details about the definitions, entering conditions, and leaving conditions for
events A5/A3/A1, see Measurement Event. For details about the variable
configurations for event A5, see Table 4-9. For details about the variable
configurations for event A3, see Table 4-7. For details about the variable
configurations for event A1, see Table 4-5.
Measurement Reporting
A UE performs measurements based on the event measurement configuration and
reports the event based on the results.
● If event A5 (indicating the signal quality of the serving cell drops below
threshold 1 and the signal quality of a neighboring cell exceeds threshold 2)
related to coverage-based inter-frequency measurements is reported, the
gNodeB determines the target cells or frequencies based on the measurement
report. If RSRP is used as the triggering quantity with RSRQ-based filtering,
the gNodeB further filters candidate cells based on the measured RSRQ. For
details about RSRQ-based filtering, see Generation of a Target Cell or
Frequency List.
● If event A3 (indicating the signal quality of a neighboring cell is higher than
that of the serving cell by a certain offset) related to coverage-based inter-
frequency measurements is reported, the gNodeB determines the target cells
or frequencies based on the measurement report.
● If event A1 (indicating the signal quality of the serving cell exceeds a specific
threshold) related to coverage-based inter-frequency measurements is
reported, the gNodeB instructs the UE to stop coverage-based inter-frequency
measurements for event A5, and the UE then stops related event A5
measurements, which results in the corresponding function being stopped. If
both RSRP and RSRQ are used as the triggering quantities, coverage-based
inter-frequency measurements for event A5 are stopped only after RSRP- and
4.3.2.1 Benefits
Coverage-based inter-frequency handovers ensure that coverage is continuous and
service experience is consistent for moving UEs.
The service drop rate decreases after the blind redirection optimization function is
enabled. The service drop rate is indicated by counters such as Service‧Call‧Drop‧
Rate‧(CU), Service‧Call‧Drop‧Rate‧(CU,‧Inactive), and Call‧Drop‧Rate‧(CU,‧
VoNR).
4.3.2.2 Impacts
Network Impacts
This function results in the following network impacts:
● During a handover, the UE needs to synchronize with the target cell and
initiate random access. This increases delay due to service interruption,
affecting throughput.
● Inter-frequency measurements require the use of measurement gaps, leading
to decreased throughput.
Function Impacts
RAT Function Function Reference Description
Name Switch
4.3.3 Requirements
4.3.3.1 Licenses
There are no license requirements.
4.3.3.2 Software
Prerequisite Functions
None
4.3.3.3 Hardware
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules support this function. For details, see the technical
specifications of RF modules in 3900 & 5900 Series Base Station Product
Documentation.
4.3.3.4 Others
UE support is required for inter-frequency intra-FR1 FDD handover/inter-frequency
intra-FR1 TDD handover/inter-frequency intra-FR2 TDD handover, and indicated by
the handoverInterF IE in the UECapabilityInformation message over the Uu
interface.
Since the values of handoverInterF in the said IEs may differ, the methods to
evaluate whether UEs support inter-frequency handover may vary among vendors.
In this context, 3GPP TS 38.306 V16.1.0 updates the definition of the inter-
frequency handover capability of UEs and defines the method of checking the
capability based on the combination of handoverInterF values in different IEs. For
● N.HO.InterFreq.Coverage.PrepAttOut
● N.HO.InterFreq.Coverage.ExecAttOut
● N.HO.InterFreq.Coverage.ExecSuccOut
4.4.1 Principles
Figure 4-9 shows the procedure of frequency-priority-based inter-frequency
handover. This section describes the differences between this function and the
basic handover functions presented in 4.1 Basic Functions of Mobility
Management in Connected Mode.
If the source gNodeB receives a measurement report from the UE and sends a Handover
Request message to the target gNodeB but does not receive a response from the target
gNodeB during a period specified by NRCellMobilityConfig.InterFreqMeasWaitTime, the
source gNodeB will again send measurement configurations for event A4 or A5 related to
frequency-priority-based measurements to the UE.
Measurement Reporting
A UE performs measurements based on the event measurement configuration and
reports the event based on the results.
For details about how the serving cell determines whether a neighboring cell is
exposed to low uplink interference, see Target Cell or Frequency Decision.
If frequency-priority-based inter-frequency handover is enabled for the serving cell and
uplink-interference-based inter-frequency handover is enabled for the target cell, you
are advised to enable the function of subscription to uplink interference information
about inter-frequency neighboring cells for the serving cell, avoiding ping-pong
handover.
When the inter-frequency handover collaboration function is enabled (by
selecting the INTER_FREQ_HO_COLLABORATION_SW option of the
NRCellAlgoSwitch.InterFreqHoSwitch parameter) for the serving cell, the
serving cell further determines whether to instruct the UE to initiate a
handover as follows:
– If the serving cell identifies that the target cell has entered the MLB state
through inter-cell load information exchange, the gNodeB does not
Parameter Configuration
The following table describes the parameters related to frequency-priority-based
inter-frequency handover.
● Traffic priority
The gNodeB selects traffic priority-related parameters based on whether
RFSP-specific frequency-priority-based inter-frequency handover is enabled
(as specified by the FREQ_PRIORITY_BASED_HO_SW option of the
NRCellAlgoSwitch.RfspAlgoSwitch parameter).
– If RFSP-specific frequency-priority-based inter-frequency handover is
disabled, the value of the NRCellFreqRelation.TrafficPriority parameter
is used as the traffic priority. In this case, the gNodeB sends all UEs in the
cell the frequencies whose traffic priorities are not 0 and higher than the
serving frequency.
– If RFSP-specific frequency-priority-based inter-frequency handover is
enabled, the parameters related to traffic priority are configured as
follows:
The gNodeB attempts to obtain the RFSP index of a UE from the core
network, and then sends the UE measurement configurations including
the frequency that is selected based on the RFSP index.
▪ If the gNodeB has obtained the UE's RFSP index from the core
network and the RFSP-index-specific gNBRfspConfig.RfspIndex
parameter (bound to a valid
gNBRfspConfig.gNBFreqPriorityGroupId parameter, which has a
non-255 value) has been configured on the gNodeB, the traffic
priority will be specified by the
▪ If the gNodeB has obtained the UE's RFSP index from the core
network and the RFSP-index-specific gNBRfspConfig.RfspIndex
parameter has not been configured but a 0-value
gNBRfspConfig.RfspIndex parameter (bound to a valid
gNBRfspConfig.gNBFreqPriorityGroupId parameter, which has a
non-255 value) has been configured on the gNodeB, the traffic
priority will be specified by the
gNBFreqPriorityGroup.TrafficPriority parameter, which is bound to
the 0-value gNBRfspConfig.RfspIndex parameter. In this case, the
gNodeB sends the UE the 0-value gNBRfspConfig.RfspIndex-specific
frequencies whose traffic priorities are not 0 and higher than the
serving frequency.
In this scenario, thresholds for RFSP-specific frequency-priority-based
event A1 and RFSP-specific frequency-priority-based event A2 can be
customized for UEs.
▪ If the gNodeB has failed to obtain the UE's RFSP index from the core
network and a 0-value gNBRfspConfig.RfspIndex parameter (bound
to a valid gNBRfspConfig.gNBFreqPriorityGroupId parameter,
which has a non-255 value) has been configured on the gNodeB, the
traffic priority will be specified by the
gNBFreqPriorityGroup.TrafficPriority parameter, which is bound to
the 0-value gNBRfspConfig.RfspIndex parameter. In this case, the
gNodeB sends the UE the 0-value gNBRfspConfig.RfspIndex-specific
frequencies whose traffic priorities are not 0 and higher than the
serving frequency.
In this scenario, thresholds for RFSP-specific frequency-priority-based
event A1 and RFSP-specific frequency-priority-based event A2 can be
customized for UEs.
In NSA networking, the gNodeB uses the SPIDs to customize the frequency-priority-
based traffic priority, threshold for frequency-priority-based event A1, and threshold
for frequency-priority-based event A2 for UEs. After receiving the SPIDs from the
eNodeB, the gNodeB processes the SPIDs in the same way as in SA networking.
4.4.2.1 Benefits
This function provides a method to hand over UEs and allows for flexible
networking to help operators implement service steering.
4.4.2.2 Impacts
Network Impacts
This function results in the following network impacts:
● During a handover, the UE needs to synchronize with the target cell and
initiate random access. This increases delay due to service interruption,
affecting throughput.
● Inter-frequency measurements require the use of measurement gaps, leading
to decreased throughput.
● Networking of the existing network and the impact relationship between
frequency-priority-based inter-frequency handover and other handover
functions (such as service-based inter-frequency handover) must be
Function Impacts
RAT Function Function Reference Description
Name Switch
4.4.3 Requirements
4.4.3.1 Licenses
There are no license requirements.
4.4.3.2 Software
Prerequisite Functions
RAT Function Function Reference Description
Name Switch
4.4.3.3 Hardware
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules support this function. For details, see the technical
specifications of RF modules in 3900 & 5900 Series Base Station Product
Documentation.
4.4.3.4 Networking
During network planning, if an unnecessary handover function needs to be
enabled for multiple cells, a UE must be prevented from being handed over back
to the source cell after several unnecessary handovers of the same or different
types. Otherwise, the UE experiences repeated handovers and user experience is
4.4.3.5 Others
UE support is required for inter-frequency intra-FR1 FDD handover/inter-frequency
intra-FR1 TDD handover/inter-frequency intra-FR2 TDD handover, and indicated by
the handoverInterF IE in the UECapabilityInformation message over the Uu
interface.
UE support is required for inter-frequency FDD-TDD handover, and indicated by
the handoverFDD-TDD IE in the UECapabilityInformation message over the Uu
interface.
UE support is required for inter-frequency FR1-FR2 handover, and indicated by the
handoverFR1-FR2 IE in the UECapabilityInformation message over the Uu
interface.
The handoverInterF IE can be included in the measAndMobParametersXDD-Diff/
measAndMobParametersFRX-Diff/fdd-Add-UE-NR-Capabilities/tdd-Add-UE-NR-
Capabilities/fr1-Add-UE-NR-Capabilities/fr2-Add-UE-NR-Capabilities IEs. For this
reason, whether UEs support inter-frequency handover is evaluated based on the
value of handoverInterF in those IEs. For details on evaluation based on
handoverInterF/handoverFDD-TDD/handoverFR1-FR2, see section 4.2 "UE
Capability Parameters" in 3GPP TS 38.306 V15.9.0.
Since the values of handoverInterF in the said IEs may differ, the methods to
evaluate whether UEs support inter-frequency handover may vary among vendors.
In this context, 3GPP TS 38.306 V16.1.0 updates the definition of the inter-
frequency handover capability of UEs and defines the method of checking the
capability based on the combination of handoverInterF values in different IEs. For
details, see "Annex B: UE capability indication for UE capabilities with both
FDD/TDD and FR1/FR2 differentiations" in 3GPP TS 38.306 V16.1.0.
To ensure UE compatibility and improve the accuracy of UE capability evaluation,
compatibility processing optimization has been made in accordance with the latest
definition in 3GPP specifications. The INTER_FREQ_HO_CAPB_IND_OPT_SW
option of the gNBMobilityCommParam.ProtocolCompatibilitySw parameter
determines whether to enable the optimization. It is recommended that this
option be selected. If this option is selected, the number of NR inter-frequency
handovers due to protocol incompatibility of UEs decreases, that is, the number of
invalid inter-frequency handover attempts decreases.
4.5.1 Principles
Figure 4-11 shows the procedure of operator-specific-priority-based inter-
frequency handover. This section describes the differences between this function
and the basic handover functions presented in 4.1 Basic Functions of Mobility
Management in Connected Mode.
Measurement Reporting
A UE performs measurements based on the event indicated in the measurement
configuration and reports the event based on the measurement results. If event A4
(indicating the signal quality of a neighboring cell exceeds a specific threshold) or
A5 (indicating the signal quality of the serving cell drops below threshold 1 and
the signal quality of a neighboring cell exceeds threshold 2) related to operator-
specific-priority-based measurements is reported, the gNodeB determines the
target cells or frequencies based on the measurement report.
that the signal quality of the serving cell drops below threshold 1 and the signal
quality of a neighboring cell exceeds threshold 2) related to operator-specific-
priority-based measurements, the gNodeB selects the best cell from the reported
cells as the target cell for handover execution.
Wherein:
When the function of subscription to uplink interference information about inter-
frequency neighboring cells is enabled (by selecting the
INTER_FREQ_UL_INTRF_SW option of the
NRCellAlgoSwitch.NCellInfoCtrlSwitch parameter) for the serving cell, the
serving cell obtains uplink interference information about intra- or inter-base-
station neighboring cells, based on which the serving cell determines whether to
instruct the UE to initiate a handover. Specifically, the UE is instructed to do so if
the serving cell determines that the target cell is exposed to low uplink
interference. Otherwise, the UE is not instructed to perform a handover.
NOTE
For details about how the serving cell determines whether a neighboring cell is exposed to
low uplink interference, see Target Cell or Frequency Decision.
If operator-specific-priority-based inter-frequency handover is enabled for the serving cell
and uplink-interference-based inter-frequency handover is enabled for the target cell, you
are advised to enable the function of subscription to uplink interference information about
inter-frequency neighboring cells for the serving cell, avoiding ping-pong handover.
NOTE
4.5.2.1 Benefits
In network sharing scenarios, this function facilitates the transfer of each
operator's UEs to cells on the higher-priority frequency of that operator, providing
flexible networking for operators.
4.5.2.2 Impacts
Network Impacts
This function results in the following network impacts:
● During a handover, the UE needs to synchronize with the target cell and
initiate random access. This increases delay due to service interruption,
affecting throughput.
● Inter-frequency measurements require the use of measurement gaps, leading
to decreased throughput.
● Networking of the existing network and the impact relationship between
operator-specific-priority-based inter-frequency handover and other handover
functions (such as frequency-priority-based inter-frequency handover) must
be considered to prevent ping-pong handovers and ensure user experience.
For details about networking requirements, see 4.5.3.4 Networking.
Function Impacts
RAT Function Function Reference Description
Name Switch
4.5.3 Requirements
4.5.3.1 Licenses
There are no license requirements.
4.5.3.2 Software
Prerequisite Functions
None
4.5.3.3 Hardware
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules support this function. For details, see the technical
specifications of RF modules in 3900 & 5900 Series Base Station Product
Documentation.
4.5.3.4 Networking
During network planning, if an unnecessary handover function needs to be
enabled for multiple cells, a UE must be prevented from being handed over back
to the source cell after several unnecessary handovers of the same or different
types. Otherwise, the UE experiences repeated handovers and user experience is
poor. Handovers other than coverage-based intra-frequency handovers and
coverage-based inter-frequency handovers are called unnecessary handovers.
Following are examples:
● During network planning, avoid the following situation: After a UE is handed
over from cell 1 to cell 2 through an operator-specific-priority-based inter-
frequency handover, the UE is handed over from cell 2 back to cell 1 through
an operator-specific-priority-based inter-frequency handover.
● During network planning, avoid the following situation: After a UE is handed
over from cell 1 to cell 2 through an operator-specific-priority-based inter-
frequency handover, the UE is handed over from cell 2 back to cell 1 through
a frequency-priority-based handover.
● During network planning, avoid the following situation: A UE is handed over
from cell 1 to cell 2 through an operator-specific-priority-based inter-
frequency handover, then from cell 2 to cell 3 through a service-based inter-
frequency handover, and finally from cell 3 to cell 1 through a frequency-
priority-based handover.
4.5.3.5 Others
UE support is required for inter-frequency intra-FR1 FDD handover/inter-frequency
intra-FR1 TDD handover/inter-frequency intra-FR2 TDD handover, and indicated by
the handoverInterF IE in the UECapabilityInformation message over the Uu
interface.
UE support is required for inter-frequency FDD-TDD handover, and indicated by
the handoverFDD-TDD IE in the UECapabilityInformation message over the Uu
interface.
UE support is required for inter-frequency FR1-FR2 handover, and indicated by the
handoverFR1-FR2 IE in the UECapabilityInformation message over the Uu
interface.
The handoverInterF IE can be included in the measAndMobParametersXDD-Diff/
measAndMobParametersFRX-Diff/fdd-Add-UE-NR-Capabilities/tdd-Add-UE-NR-
Capabilities/fr1-Add-UE-NR-Capabilities/fr2-Add-UE-NR-Capabilities IEs. For this
reason, whether UEs support inter-frequency handover is evaluated based on the
value of handoverInterF in those IEs. For details on evaluation based on
handoverInterF/handoverFDD-TDD/handoverFR1-FR2, see section 4.2 "UE
Capability Parameters" in 3GPP TS 38.306 V15.9.0.
Since the values of handoverInterF in the said IEs may differ, the methods to
evaluate whether UEs support inter-frequency handover may vary among vendors.
In this context, 3GPP TS 38.306 V16.1.0 updates the definition of the inter-
frequency handover capability of UEs and defines the method of checking the
capability based on the combination of handoverInterF values in different IEs. For
details, see "Annex B: UE capability indication for UE capabilities with both
FDD/TDD and FR1/FR2 differentiations" in 3GPP TS 38.306 V16.1.0.
To ensure UE compatibility and improve the accuracy of UE capability evaluation,
compatibility processing optimization has been made in accordance with the latest
definition in 3GPP specifications. The INTER_FREQ_HO_CAPB_IND_OPT_SW
option of the gNBMobilityCommParam.ProtocolCompatibilitySw parameter
determines whether to enable the optimization. It is recommended that this
option be selected. If this option is selected, the number of NR inter-frequency
handovers due to protocol incompatibility of UEs decreases, that is, the number of
invalid inter-frequency handover attempts decreases.
● If this option is selected:
During evaluation of UE support for inter-frequency handover, the gNodeB
checks the handoverInterF IE in compliance with the new definition of
checking the inter-frequency handover capability of UEs in 3GPP TS 38.306
V16.1.0.
During evaluation of UE support for inter-frequency FDD-TDD handover and
inter-frequency FR1-FR2 handover, the gNodeB first checks the
Table 4-23 Parameters used to configure frequency priority groups of the gNodeB
Parameter Parameter ID Setting Notes
Name
NOTE
In SA networking, the 5G Core Network (5GC) notifies the gNodeB of the 5QI
corresponding to each QoS flow. For detailed description about QCI and 5QI, see QoS
Management.
4.6.1 Principles
With service-based inter-frequency handover, a target frequency group for
handover can be configured for each QCI. After service-based inter-frequency
handover is enabled, the gNodeB continuously monitors a UE's service status. If
the UE's QCI changes, the gNodeB sends the measurement configuration for the
specified frequency group to the UE, which then performs inter-frequency
measurement accordingly. After receiving a measurement report from the UE, the
gNodeB determines the optimal candidate target cell for handover execution. This
handover function does not apply to the blind mode. Figure 4-13 shows the
procedure of service-based inter-frequency handover. This section describes the
differences between this function and the basic handover functions presented in
4.1 Basic Functions of Mobility Management in Connected Mode.
● The serving frequency of the UE is not within the target frequency range
desired for the service. That is, the serving frequency is not contained in the
frequency group specified by the gNBSrvInterHoFreqGrp MO associated with
this QCI.
NOTE
For details about the priority configuration for each QCI, see QoS Management.
Measurement Reporting
The UE performs measurements based on the event configuration included in the
measurement configuration. If neighboring cells that meet the requirements are
detected, a measurement report is sent to the gNodeB, which then uses the report
to determine the target cells or frequencies.
If no neighboring cell is reported 6s after the measurement of event A4 or A5
related to service-based inter-frequency handover has started, the gNodeB
releases the measurement configuration, enabling the UE to stop measurements
for this event A4 or A5. In this scenario, if the UE is always in connected mode, the
gNodeB no longer sends the same measurement configuration.
that the signal quality of the serving cell drops below threshold 1 and the signal
quality of a neighboring cell exceeds threshold 2) related to service-based inter-
frequency handover, the gNodeB selects the best cell from the reported cells as
the target cell for handover execution.
Wherein:
When the function of subscription to uplink interference information about inter-
frequency neighboring cells is enabled (by selecting the
INTER_FREQ_UL_INTRF_SW option of the
NRCellAlgoSwitch.NCellInfoCtrlSwitch parameter) for the serving cell, the
serving cell obtains uplink interference information about intra- or inter-base-
station neighboring cells, based on which the serving cell determines whether to
instruct the UE to initiate a handover. Specifically, the UE is instructed to do so if
the serving cell determines that the target cell is exposed to low uplink
interference. Otherwise, the UE is not instructed to perform a handover.
NOTE
For details about how the serving cell determines whether a neighboring cell is exposed to
low uplink interference, see Target Cell or Frequency Decision.
If service-based inter-frequency handover is enabled for the serving cell and uplink-
interference-based inter-frequency handover is enabled for the target cell, you are advised
to enable the function of subscription to uplink interference information about inter-
frequency neighboring cells for the serving cell, avoiding ping-pong handover.
NOTE
When service-based inter-frequency handover is enabled for the serving cell, you are
advised to enable the inter-frequency handover collaboration function to avoid ping-pong
handover if MLB by transferring UEs in connected mode between inter-frequency cells is
enabled (by selecting the INTER_FREQ_CONNECTED_MLB_SW option of the
NRCellAlgoSwitch.MlbAlgoSwitch parameter) for the target cell.
For details about MLB by transferring UEs in connected mode, see Mobility Load Balancing.
4.6.2.1 Benefits
This function provides a method for handing over UEs based on services and
allows flexible networking, thereby helping operators implement service steering.
4.6.2.2 Impacts
Network Impacts
This function results in the following network impacts:
● During a handover, the UE needs to synchronize with the target cell and
initiate random access. This increases delay due to service interruption,
affecting throughput.
● Inter-frequency measurements require the use of measurement gaps, leading
to decreased throughput.
● Networking of the existing network and the impact relationship between
service-based inter-frequency handover and other handover functions (such
as frequency-priority-based inter-frequency handover) must be considered to
prevent ping-pong handovers and ensure user experience. For details about
networking requirements, see 4.6.3.4 Networking.
Function Impacts
RAT Function Function Reference Description
Name Switch
4.6.3 Requirements
4.6.3.1 Licenses
There are no license requirements.
4.6.3.2 Software
Prerequisite Functions
None
4.6.3.3 Hardware
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules support this function. For details, see the technical
specifications of RF modules in 3900 & 5900 Series Base Station Product
Documentation.
4.6.3.4 Networking
During network planning, if an unnecessary handover function needs to be
enabled for multiple cells, a UE must be prevented from being handed over back
to the source cell after several unnecessary handovers of the same or different
types. Otherwise, the UE experiences repeated handovers and user experience is
poor. Handovers other than coverage-based intra-frequency handovers and
coverage-based inter-frequency handovers are called unnecessary handovers.
Following are examples:
● During network planning, avoid the following situation: After a UE is handed
over from cell 1 to cell 2 through a service-based inter-frequency handover,
the UE is handed over from cell 2 back to cell 1 through a service-based inter-
frequency handover.
● During network planning, avoid the following situation: After a UE is handed
over from cell 1 to cell 2 through a service-based inter-frequency handover,
the UE is handed over from cell 2 back to cell 1 through a frequency-priority-
based handover.
● During network planning, avoid the following situation: A UE is handed over
from cell 1 to cell 2 through an uplink-interference-based inter-frequency
handover, then from cell 2 to cell 3 through a service-based inter-frequency
handover, and finally from cell 3 to cell 1 through a frequency-priority-based
handover.
4.6.3.5 Others
UE support is required for inter-frequency intra-FR1 FDD handover/inter-frequency
intra-FR1 TDD handover/inter-frequency intra-FR2 TDD handover, and indicated by
the handoverInterF IE in the UECapabilityInformation message over the Uu
interface.
UE support is required for inter-frequency FDD-TDD handover, and indicated by
the handoverFDD-TDD IE in the UECapabilityInformation message over the Uu
interface.
UE support is required for inter-frequency FR1-FR2 handover, and indicated by the
handoverFR1-FR2 IE in the UECapabilityInformation message over the Uu
interface.
The handoverInterF IE can be included in the measAndMobParametersXDD-Diff/
measAndMobParametersFRX-Diff/fdd-Add-UE-NR-Capabilities/tdd-Add-UE-NR-
Capabilities/fr1-Add-UE-NR-Capabilities/fr2-Add-UE-NR-Capabilities IEs. For this
reason, whether UEs support inter-frequency handover is evaluated based on the
value of handoverInterF in those IEs. For details on evaluation based on
handoverInterF/handoverFDD-TDD/handoverFR1-FR2, see section 4.2 "UE
Capability Parameters" in 3GPP TS 38.306 V15.9.0.
Since the values of handoverInterF in the said IEs may differ, the methods to
evaluate whether UEs support inter-frequency handover may vary among vendors.
In this context, 3GPP TS 38.306 V16.1.0 updates the definition of the inter-
frequency handover capability of UEs and defines the method of checking the
capability based on the combination of handoverInterF values in different IEs. For
details, see "Annex B: UE capability indication for UE capabilities with both
FDD/TDD and FR1/FR2 differentiations" in 3GPP TS 38.306 V16.1.0.
Table 4-28 Parameters used to configure frequency groups for service-based inter-
frequency handover
Parameter Parameter ID Setting Notes
Name
4.7.1 Principles
The gNodeB determines whether to start uplink-interference-based inter-
frequency handover based on the strength of uplink interference in the serving
cell. Specifically, if the uplink interference strength is greater than a specified
threshold, the gNodeB sends inter-frequency measurement configurations to low-
SRS-SINR UEs performing large packet services in the serving cell's uplink. The UEs
then perform inter-frequency measurements. After receiving measurement reports
from the UEs, the gNodeB determines the optimal candidate target cells for
handover execution. This function does not apply to the blind mode. Figure 4-15
shows how uplink-interference-based inter-frequency handover works. This section
describes the differences between this function and the basic handover functions
presented in 4.1 Basic Functions of Mobility Management in Connected Mode.
● The strength of uplink interference in the serving cell is greater than the
uplink interference threshold (specified by the
NRDUCellIntrfIdent.UlIntrfThld parameter).
Measurement Reporting
After receiving the measurement configuration from the gNodeB, the UE performs
measurements in descending order of interference-based frequency priority
(specified by NRCellFreqRelation.IntrfFreqPriority). If the UE detects a
neighboring cell that meets the specific requirements, it reports the measurement
result to the gNodeB and stops measurements for this event A3. The gNodeB then
determines the target cells or frequencies based on the measurement report.
If no neighboring cell is reported 6s after the measurement of event A3 related to
uplink-interference-based inter-frequency handover has started, the gNodeB
releases the measurement configuration, enabling the UE to stop measurements
for this event A3. To prevent the UE from experiencing continued failures in
outgoing handovers from the serving cell, cell-level supplementary selection in
polling mode is performed. Specifically, the gNodeB periodically (at a fixed
interval of 30s) selects a maximum of five low-SRS-SINR UEs performing large
packet services in the serving cell's uplink in polling mode and sends measurement
NOTE
4.7.2.1 Benefits
Uplink-interference-based inter-frequency handovers are performed to ensure
uplink user experience when the serving cell has strong uplink interference.
4.7.2.2 Impacts
Network Impacts
Uplink-interference-based inter-frequency handover results in the following
impacts on the network:
● During a handover, the UE needs to synchronize with the target cell and
initiate random access. This increases delay due to service interruption,
affecting throughput.
Function Impacts
RAT Function Function Reference Description
Name Switch
4.7.3 Requirements
4.7.3.1 Licenses
This function is not under license control.
4.7.3.2 Software
Prerequisite Functions
None
FDD LTE FDD LTE_NR_FDD_SPCT_ LTE FDD LTE FDD and NR Flash
and NR SHR_SW option of and NR Dynamic Spectrum
Flash the Spectrum Sharing is mutually
Dynamic NRDUCellAlgoSwitc Sharing exclusive with uplink-
Spectrum h.SpectrumCloudSw interference-based
Sharing itch parameter inter-frequency
handover.
4.7.3.3 Hardware
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules that work in low frequency bands support this
function. For details, see the technical specifications of RF modules in 3900 & 5900
Series Base Station Product Documentation.
4.7.3.4 Networking
During network planning, if an unnecessary handover function needs to be
enabled for multiple cells, a UE must be prevented from being handed over back
to the source cell after several unnecessary handovers of the same or different
types. Otherwise, the UE experiences repeated handovers and user experience is
poor. Handovers other than coverage-based intra-frequency handovers and
coverage-based inter-frequency handovers are called unnecessary handovers.
Following are examples:
● During network planning, avoid the following situation: After a UE is handed
over from cell 1 to cell 2 through an uplink-interference-based inter-frequency
handover, the UE is handed over from cell 2 back to cell 1 through an uplink-
interference-based inter-frequency handover.
● During network planning, avoid the following situation: After a UE is handed
over from cell 1 to cell 2 through an uplink-interference-based inter-frequency
handover, the UE is handed over from cell 2 back to cell 1 through a
frequency-priority-based handover.
● During network planning, avoid the following situation: A UE is handed over
from cell 1 to cell 2 through an uplink-interference-based inter-frequency
handover, then from cell 2 to cell 3 through a service-based inter-frequency
handover, and finally from cell 3 to cell 1 through a frequency-priority-based
handover.
4.7.3.5 Others
UE support is required for inter-frequency intra-FR1 FDD handover/inter-frequency
intra-FR1 TDD handover, and indicated by the handoverInterF IE in the
UECapabilityInformation message over the Uu interface.
UE support is required for inter-frequency FDD-TDD handover, and indicated by
the handoverFDD-TDD IE in the UECapabilityInformation message over the Uu
interface.
The handoverInterF IE can be included in the measAndMobParametersXDD-Diff/
measAndMobParametersFRX-Diff/fdd-Add-UE-NR-Capabilities/tdd-Add-UE-NR-
Capabilities/fr1-Add-UE-NR-Capabilities IEs. For this reason, whether UEs support
inter-frequency handover is evaluated based on the value of handoverInterF in
those IEs. For details on evaluation based on handoverInterF/handoverFDD-TDD,
see section 4.2 "UE Capability Parameters" in 3GPP TS 38.306 V15.9.0.
Since the values of handoverInterF in the said IEs may differ, the methods to
evaluate whether UEs support inter-frequency handover may vary among vendors.
In this context, 3GPP TS 38.306 V16.1.0 updates the definition of the inter-
frequency handover capability of UEs and defines the method of checking the
capability based on the combination of handoverInterF values in different IEs. For
details, see "Annex B: UE capability indication for UE capabilities with both
FDD/TDD and FR1/FR2 differentiations" in 3GPP TS 38.306 V16.1.0.
To ensure UE compatibility and improve the accuracy of UE capability evaluation,
compatibility processing optimization has been made in accordance with the latest
definition in 3GPP specifications. The INTER_FREQ_HO_CAPB_IND_OPT_SW
option of the gNBMobilityCommParam.ProtocolCompatibilitySw parameter
determines whether to enable the optimization. It is recommended that this
option be selected. If this option is selected, the number of NR inter-frequency
handovers due to protocol incompatibility of UEs decreases, that is, the number of
invalid inter-frequency handover attempts decreases.
Table 4-33 and Table 4-35 describe other parameters used for function
optimization.
//Turning on the switch for subscription to uplink interference information about inter-frequency
neighboring cells
MOD NRCELLALGOSWITCH: NrCellId=0, NCellInfoCtrlSwitch=INTER_FREQ_UL_INTRF_SW-1;
//Modifying the interference identification configuration of the NR DU cell
MOD NRDUCELLINTRFIDENT: NrDuCellId=0, UlIntrfThld=-100, SrsSinrThld=-4;
//Selecting INTER_FREQ_HO_CAPB_IND_OPT_SW
MOD GNBMOBILITYCOMMPARAM: ProtocolCompatibilitySw=INTER_FREQ_HO_CAPB_IND_OPT_SW-1;
//(Recommended) Turning on the inter-frequency handover collaboration switch if uplink-interference-
based inter-frequency handover is enabled for the serving cell while either MLB by transferring UEs in
connected mode between inter-frequency cells or voice-quality-based inter-frequency handover is also
enabled
MOD NRCELLALGOSWITCH: NrCellId=0, InterFreqHoSwitch=INTER_FREQ_HO_COLLABORATION_SW-1;
Figure 4-16 Traditional cell splitting networking and cell splitting heterogeneous
networking
4.8.1 Principles
Figure 4-18 shows the procedure for SSB SINR-based inter-frequency handover.
This section describes the differences between this function and the basic
handover functions presented in 4.1 Basic Functions of Mobility Management in
Connected Mode.
For details about the definition, entering conditions, and leaving conditions for
event A2, see Measurement Event. For the variable configurations for event A2,
see Table 4-6.
For details about the definitions, entering conditions, and leaving conditions for
events A3 and A1, see Measurement Event. For details about the variable
configurations for event A3, see Table 4-7. For details about the variable
configurations for event A1, see Table 4-5.
Measurement Reporting
A UE performs measurements based on the event measurement configuration and
reports the event based on the results.
The following filtering rules, which are dedicated to the SSB SINR-based inter-
frequency handover function, are also considered: If this function (controlled by
the SSB_SINR_BASED_HO option of NRCellAlgoSwitch.InterFreqHoSwitch) is
enabled, and measurement-based inter-frequency handover (controlled by the
COVERAGE_BASED_HO option of NRCellAlgoSwitch.InterFreqHoSwitch) or
measurement-based inter-frequency redirection (controlled by the REDIRECTION
option of NRCellAlgoSwitch.InterFreqHoSwitch) is also enabled, the gNodeB
further filters out the following cells to generate a target cell or frequency list.
● If only RSRP is used as the triggering quantity for event A2 related to
coverage-based inter-frequency measurements, the gNodeB filters out the
cells whose RSRP is less than the result of
"NRCellInterFHoMeaGrp.CovInterFreqA2RsrpThld –
NRCellInterFHoMeaGrp.InterFreqA1A2Hyst".
● If both RSRP and RSRQ are used as the triggering quantities for event A2
related to coverage-based inter-frequency measurements, the gNodeB filters
out the cells whose RSRP is less than the result of
"NRCellInterFHoMeaGrp.CovInterFreqA2RsrpThld –
NRCellInterFHoMeaGrp.InterFreqA1A2Hyst" and the cells whose RSRQ is
less than the result of "NRCellInterFHoMeaGrp.CovInterFreqA2RsrqThld –
NRCellInterFHoMeaGrp.InterFreqA1A2Hyst".
The RSRP_AND_RSRQ_SW option of the
NRCellMobilityConfig.A1A2MeasTrigQty parameter determines the triggering
quantity for event A2.
When the function of subscription to uplink interference information about inter-
frequency neighboring cells is enabled (by selecting the
INTER_FREQ_UL_INTRF_SW option of the
NRCellAlgoSwitch.NCellInfoCtrlSwitch parameter) for the serving cell, the
serving cell obtains uplink interference information about intra- or inter-base-
station neighboring cells, based on which the serving cell determines whether to
instruct the UE to initiate a handover. Specifically, the UE is instructed to do so if
the serving cell determines that the target cell is exposed to low uplink
interference. Otherwise, the UE is not instructed to perform a handover.
NOTE
For details about how the serving cell determines whether a neighboring cell is exposed to
low uplink interference, see Target Cell or Frequency Decision.
If SSB SINR-based inter-frequency handover is enabled for the serving cell and uplink-
interference-based inter-frequency handover is enabled for the target cell, you are advised
to enable the function of subscription to uplink interference information about inter-
frequency neighboring cells for the serving cell, avoiding ping-pong handover.
NOTE
When SSB SINR-based inter-frequency handover is enabled for the serving cell, you are
advised to enable the inter-frequency handover collaboration function to avoid ping-pong
handover if MLB by transferring UEs in connected mode between inter-frequency cells is
enabled (by selecting the INTER_FREQ_CONNECTED_MLB_SW option of the
NRCellAlgoSwitch.MlbAlgoSwitch parameter) for the target cell.
For details about MLB by transferring UEs in connected mode, see Mobility Load Balancing.
4.8.2.1 Benefits
In cell splitting heterogeneous networking, SSB SINR-based inter-frequency
handover reduces interference between intra-frequency cells and improves user
experience and system capacity.
4.8.2.2 Impacts
Network Impacts
This function results in the following network impacts:
● During a handover, the UE needs to synchronize with the target cell and
initiate random access. This increases delay due to service interruption,
affecting throughput.
● Inter-frequency measurements require the use of measurement gaps, leading
to decreased throughput.
● Networking of the existing network and the impact relationship between SSB
SINR-based inter-frequency handover and other handover functions (such as
frequency-priority-based inter-frequency handover) must be considered to
prevent ping-pong handovers and ensure user experience. For details about
networking requirements, see 4.8.3.4 Networking.
Function Impacts
RAT Function Function Reference Description
Name Switch
4.8.3 Requirements
4.8.3.1 Licenses
There are no license requirements.
4.8.3.2 Software
Prerequisite Functions
None
4.8.3.3 Hardware
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules that work in low frequency bands support this
function. For details, see the technical specifications of RF modules in 3900 & 5900
Series Base Station Product Documentation.
4.8.3.4 Networking
During network planning, if an unnecessary handover function needs to be
enabled for multiple cells, a UE must be prevented from being handed over back
to the source cell after several unnecessary handovers of the same or different
types. Otherwise, the UE experiences repeated handovers and user experience is
poor. Handovers other than coverage-based intra-frequency handovers and
coverage-based inter-frequency handovers are called unnecessary handovers.
Following are examples:
4.8.3.5 Others
UE support is required for inter-frequency intra-FR1 FDD handover/inter-frequency
intra-FR1 TDD handover/inter-frequency intra-FR2 TDD handover, and indicated by
the handoverInterF IE in the UECapabilityInformation message over the Uu
interface.
UE support is required for inter-frequency FDD-TDD handover, and indicated by
the handoverFDD-TDD IE in the UECapabilityInformation message over the Uu
interface.
UE support is required for inter-frequency FR1-FR2 handover, and indicated by the
handoverFR1-FR2 IE in the UECapabilityInformation message over the Uu
interface.
The handoverInterF IE can be included in the measAndMobParametersXDD-Diff/
measAndMobParametersFRX-Diff/fdd-Add-UE-NR-Capabilities/tdd-Add-UE-NR-
Capabilities/fr1-Add-UE-NR-Capabilities/fr2-Add-UE-NR-Capabilities IEs. For this
reason, whether UEs support inter-frequency handover is evaluated based on the
value of handoverInterF in those IEs. For details on evaluation based on
handoverInterF/handoverFDD-TDD/handoverFR1-FR2, see section 4.2 "UE
Capability Parameters" in 3GPP TS 38.306 V15.9.0.
Since the values of handoverInterF in the said IEs may differ, the methods to
evaluate whether UEs support inter-frequency handover may vary among vendors.
In this context, 3GPP TS 38.306 V16.1.0 updates the definition of the inter-
frequency handover capability of UEs and defines the method of checking the
capability based on the combination of handoverInterF values in different IEs. For
details, see "Annex B: UE capability indication for UE capabilities with both
FDD/TDD and FR1/FR2 differentiations" in 3GPP TS 38.306 V16.1.0.
To ensure UE compatibility and improve the accuracy of UE capability evaluation,
compatibility processing optimization has been made in accordance with the latest
definition in 3GPP specifications. The INTER_FREQ_HO_CAPB_IND_OPT_SW
option of the gNBMobilityCommParam.ProtocolCompatibilitySw parameter
determines whether to enable the optimization. It is recommended that this
option be selected. If this option is selected, the number of NR inter-frequency
handovers due to protocol incompatibility of UEs decreases, that is, the number of
invalid inter-frequency handover attempts decreases.
● If this option is selected:
During evaluation of UE support for inter-frequency handover, the gNodeB
checks the handoverInterF IE in compliance with the new definition of
checking the inter-frequency handover capability of UEs in 3GPP TS 38.306
V16.1.0.
During evaluation of UE support for inter-frequency FDD-TDD handover and
inter-frequency FR1-FR2 handover, the gNodeB first checks the
handoverInterF IE to determine whether outgoing handovers from the current
cell are allowed. It then checks the handoverFDD-TDD IE to determine
whether UEs support inter-frequency FDD-TDD handover and the
//(Recommended) Turning on the inter-frequency handover collaboration switch if SSB SINR-based inter-
frequency handover is enabled for the serving cell while either MLB by transferring UEs in connected mode
between inter-frequency cells or voice-quality-based inter-frequency handover is also enabled
MOD NRCELLALGOSWITCH: NrCellId=0, InterFreqHoSwitch=INTER_FREQ_HO_COLLABORATION_SW-1;
//(Recommended) Turning on the switch for subscription to uplink interference information about inter-
frequency neighboring cells for the serving cell if SSB SINR-based inter-frequency handover is enabled for
the serving cell and uplink-interference-based inter-frequency handover is enabled for the target cell
MOD NRCELLALGOSWITCH: NrCellId=0, NCellInfoCtrlSwitch=INTER_FREQ_UL_INTRF_SW-1;
● N.HO.InterFreq.SSB.SINR.PrepAttOut
● N.HO.InterFreq.SSB.SINR.ExecAttOut
● N.HO.InterFreq.SSB.SINR.ExecSuccOut
After optimized configuration for deriveSSB-IndexFromCell is enabled, perform the
following operations to check whether it has taken effect:
● If the serving frequency is an NR TDD frequency and the frequency to be
measured is an NR FDD frequency, check whether the value of the deriveSSB-
IndexFromCell IE corresponding to the frequency to be measured in the
RRCReconfiguration message sent by the gNodeB is TRUE, which shows that
the function has taken effect.
● If the serving frequency is an NR FDD frequency and the frequency to be
measured is an NR TDD frequency, check whether the value of the deriveSSB-
IndexFromCell IE corresponding to the frequency to be measured in the
RRCReconfiguration message sent by the gNodeB is TRUE, which shows that
the function has taken effect.
5.1 Principles
In mobility management in idle mode, the following terms and definitions apply:
● Acceptable cell: A cell that a UE obtains only limited services (such as
emergency calls) from when camping on it.
A cell can be an acceptable cell only when:
– It is not barred.
– It meets the cell selection criteria (see 5.1.2 Cell Selection).
● Suitable cell: A cell that a UE obtains normal services from when camping on
it.
A cell can be a suitable cell only when:
– It is not barred.
– It meets the cell selection criteria (see 5.1.2 Cell Selection).
– It belongs to the UE-selected PLMN or a PLMN on the equivalent PLMN
list.
– It supports the PLMN selected or registered by the UE.
● Barred cell: A cell that is barred from providing services. If it is a single-
operator cell, the master information block (MIB) is used to indicate its barred
status. If it is a multi-operator cell, the SIB1 is used to indicate its barred
status for each of the operators.
In NR, two synchronization signals are used in cell search: primary synchronization
signals (PSSs) and secondary synchronization signals (SSSs).
A UE performs cell search as follows:
1. The UE detects the PSS to achieve clock synchronization and acquires an ID in
a PCI group based on the mapping with the PSS.
2. The UE detects the SSS to achieve time synchronization (frame
synchronization) and acquires a PCI group ID based on the mapping with the
SSS.
3. The UE determines the cell's PCI based on the PCI group ID and the ID in the
PCI group.
4. The UE detects the downlink SSB signal to determine the cell's signal quality.
5. The UE reads the MIB and SIB1 to obtain other information about the cell,
such as the operator information.
PLMN Selection
After completing cell search, the UE selects and registers with a PLMN. After the
PLMN registration succeeds, the UE displays the information about the PLMN and
prepares to obtain services from the operator.
Figure 5-1 shows the procedure for the UE to select a PLMN.
NOTE
For details about cell selection criteria, see section 5.2.3.2 "Cell Selection Criterion" in 3GPP
TS 38.304 V15.4.0.
In the cell selection criteria, Squal must be greater than 0 only if the SIB1_RSRQ_SW option
of the NRDUCellSelConfig.SibOptionalIeInd parameter is selected; only Srxlev must be
greater than 0 in other cases.
NOTE
To perform medium-priority blocking for a cell, the RRC_IDLE UEs in the cell must be
migrated out. The gNodeB selects cell reselection for transferring UEs out of the cell.
▪ If the Srxlev of the serving cell is less than or equal to the value of
NRCellReselConfig.NonIntraFreqMeasRsrpThld or the Squal is less
than or equal to the value of
NRCellReselConfig.NonIntraFreqMeasRsrqThld, the UE starts
neighboring cell measurements for inter-frequency cell reselection.
When speed-based cell reselection is enabled, a UE can determine its speed based
on the system information (SI) broadcast by the gNodeB and then use appropriate
cell reselection parameters adaptive to its speed for cell reselection.
5.2.1 Benefits
This function allows UEs in RRC_IDLE mode to camp on a cell with a higher signal
quality, ensuring continuous coverage and providing users with seamless service
experience.
5.2.2 Impacts
Network Impacts
None
Function Impacts
None
5.3 Requirements
5.3.1 Licenses
There are no license requirements.
5.3.2 Software
Prerequisite Functions
RAT Function Function Switch Reference Description
Name
5.3.3 Hardware
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules that work in low frequency bands support this
function. For details, see the technical specifications of RF modules in 3900 & 5900
Series Base Station Product Documentation.
5.3.4 Others
Speed-based cell reselection: UEs must support speed-based cell reselection.
//Modifying the SSB combination threshold and the number of SSBs allowed for calculating the average
value for inter-frequency neighboring cell measurement
MOD NRCELLMOBILITYCONFIG: NrCellId=0, SsbConsolidationThld=70, SsbNumToAverage=8;
//Turning on the protocol IE optimization switch
MOD NRCELLALGOSWITCH: NrCellId=0, HoCompatibilitySwitch=PROTOCOL_IE_OPT_SW-1;
//Adding a cell blacklist for the gNodeB
ADD GNBCELLBLACKLIST: CellBlacklistId=1, StartPhysicalCellId=231, PhysicalCellIdRange=N4;
//Modifying the cell blacklist ID for intra-frequency reselection
MOD NRCELLMOBILITYCONFIG: NrCellId=0, IntraFReselCellBlacklistId=1;
//Configuration for enabling speed-based cell reselection
//Setting the UE mobility state evaluation period, threshold expressed as a number of cell reselections for
evaluating whether UEs enter the medium-mobility state, threshold expressed as a number of cell
reselections for evaluating whether UEs enter the high-mobility state, scaling factor for the cell reselection
time of medium-mobility UEs, scaling factor for the cell reselection time of high-mobility UEs, additional
hysteresis for cell reselection by medium-mobility UEs, and additional hysteresis for cell reselection by high-
mobility UEs
MOD NRCELLRESELCONFIG: NrCellId=0, MobStateEvalPeriod=S60, ReselThldForMediumMob=4,
ReselThldForHighMob=8, ReselTimeSfForMediumMob=1DOT0, ReselTimeSfForHighMob=0DOT75,
AddlHystForMediumMob=DB0, AddlHystForHighMob=DB0;
//Enabling speed-based cell reselection
MOD NRCELLRESELCONFIG: NrCellId=0, SibOptionalIeInd=SPEED_BASED_RESEL_SW-1;
//Enabling speed-based cell reselection to inter-frequency or inter-RAT neighboring cells
MOD NRCELLRESELCONFIG: NrCellId=0, SibOptionalIeInd=INTER_FREQ_RAT_SPEED_RESEL_SW-1;
Step 1 Start Uu signaling tracing: Log in to the MAE-Access and choose Monitor >
Signaling Trace > Signaling Trace Management. On the displayed page, choose
Trace Type > NR > Application Layer > Uu Interface Trace.
Step 2 Check whether the cellReselectionPriority and CellReselectionSubPriority IEs
corresponding to the NG-RAN cell are contained in SIB2 sent by the gNodeB. If
they are contained and share the same values as the
NRCellReselConfig.CellReselPriority and
NRCellReselConfig.CellReselSubPriority parameters, respectively, cell reselection
has taken effect.
Step 3 In inter-frequency networking, check whether the cellReselectionPriority and
CellReselectionSubPriority IEs corresponding to a non-serving frequency are
contained in SIB4 sent by the gNodeB. If they are contained and share the same
values as the NRCellFreqRelation.CellReselPriority and
NRCellFreqRelation.CellReselSubPriority parameters, respectively, inter-
frequency cell reselection has taken effect.
----End
After the related configurations are complete on the gNodeB, check SIB2, SIB4, or
SIB5 in the current serving cell.
1. Start Uu signaling tracing: Log in to the MAE-Access and choose Monitor >
Signaling Trace > Signaling Trace Management. On the displayed page,
choose Trace Type > NR > Application Layer > Uu Interface Trace.
2. When the speed-based cell reselection function is enabled by selecting the
SPEED_BASED_RESEL_SW option of the
NRCellReselConfig.SibOptionalIeInd parameter, this function has taken
effect if the gNodeB-delivered SIB2 contains the IEs t-Evaluation, n-
CellChangeMedium, n-CellChangeHigh, sf-Medium in q-HystSF, sf-High in q-
HystSF, sf-Medium in SpeedStateScaleFactors, and sf-High in
SpeedStateScaleFactors, with their values the same as the settings of
parameters NRCellReselConfig.MobStateEvalPeriod,
NRCellReselConfig.ReselThldForMediumMob,
NRCellReselConfig.ReselThldForHighMob,
NRCellReselConfig.AddlHystForMediumMob,
NRCellReselConfig.AddlHystForHighMob,
NRCellReselConfig.ReselTimeSfForMediumMob, and
NRCellReselConfig.ReselTimeSfForHighMob, respectively.
3. In inter-frequency or inter-RAT networking, when the
INTER_FREQ_RAT_SPEED_RESEL_SW option of the
NRCellReselConfig.SibOptionalIeInd parameter is selected, the function of
speed-based cell reselection to inter-frequency or inter-RAT neighboring cells
has taken effect if the gNodeB-delivered SIB4 or SIB5 contains the IEs sf-
Medium and sf-High in SpeedStateScaleFactors, with their values the same as
the settings of parameters NRCellReselConfig.ReselTimeSfForMediumMob
and NRCellReselConfig.ReselTimeSfForHighMob, respectively.
Other sub-functions: No activation verification method is available.
This chapter describes SA mobility management policies for UEs in the inactive
state.
6.1 Principles
The RRC_INACTIVE state is introduced to NR. A UE in this state suspends data
processing and, when moving inside a RAN-based Notification Area (RNA), does
not need to exchange information with the gNodeB. (For details about RNA, see
6.1.1 RNA Introduction.) As the gNodeB continues to maintain the UE's context
information, the core network considers that the UE remains in the CM-
CONNECTED state (as if it were still in the RRC_CONNECTED state). When data
transmission is required, the UE can quickly transit to the RRC_CONNECTED state.
The UE in the RRC_INACTIVE state can maintain the similar level of power
consumption as it did in the RRC_IDLE state while resuming data transmission
after a short delay.
● The switch for the RRC_INACTIVE state is turned on, and the UE supports this
state.
● The no-data-transmission duration of the UE exceeds the value of the
NRDUCellQciBearer.UeInactivityTimer parameter. If the UE has multiple
data radio bearers (DRBs), the maximum
NRDUCellQciBearer.UeInactivityTimer parameter value among all DRBs is
used.
● The RNA ID of the serving cell has been planned. That is, the
NRDUCell.RanNotificationAreaId parameter is set to a valid value (not
65535).
● Cell search, PLMN selection, cell selection, and cell reselection: Their
mechanisms are the same as those in idle mode. For details, see 5 SA
Mobility Management in Idle Mode.
● RNA update: This procedure helps acquire the correct RNA of the moving UE.
For details, see 6.1.2 RNA Update.
● State transition: The UE changes its state to RRC_CONNECTED or RRC_IDLE in
response to the change in service status. For details, see 6.1.3 State
Transition from RRC_INACTIVE.
NOTE
When a UE enters the RRC_INACTIVE state, the last serving gNodeB allocates an
RNA ID to the UE. The RNA ID consists of the TAC and RAN area code. In scenarios
other than multi-operator sharing, the RAN area code is specified by the
RNA update is classified into intra-gNodeB RNA update and inter-gNodeB RNA
update, depending on whether the gNodeB currently serving the UE is the last
serving gNodeB.
● In the case of intra-gNodeB RNA update (when the current gNodeB is the last
serving gNodeB), the gNodeB sends the UE an RRCRelease message
containing the suspendConfig IE to complete the RNA update.
● In the case of inter-gNodeB RNA update (when the current gNodeB is not the
last serving gNodeB), the gNodeB sends a RETRIEVE UE CONTEXT REQUEST
message to the last serving gNodeB over the Xn interface to retrieve the UE
context. For details, see 6.1.4 UE Context Retrieval.
For details about the signaling procedure for RNA update, see section 9.2.2.5 "RNA
update" in 3GPP TS 38.300.
NOTE
If the RAN paging fails due to reasons such as no available Xn connection to the last
serving gNodeB, the gNodeB triggers the UE to transit to RRC_IDLE after 10s and waits for
the core network to initiate a 5GC paging.
During an inter-gNodeB state transition for an RRC_INACTIVE UE, the RETRIEVE UE
CONTEXT REQUEST message sent over the Xn interface carries the PLMN, gNBID, CellId,
PCI, and DL ARFCN IEs corresponding to the target cell, in accordance with a Huawei
proprietary protocol. These IEs help the last serving gNodeB derive keys.
To ensure that the target gNodeB can send the request to the correct last serving
gNodeB, the least significant 20 bits of each gNodeB ID must be unique in the
contiguous coverage areas. If the least significant 20 bits of gNodeB IDs are not
unique, the target gNodeB may find and send Retrieve UE Context Request
messages to multiple gNodeBs meeting the requirements, causing context
retrieval failures.
6.2.1 Benefits
UEs in the RRC_INACTIVE state can maintain the similar level of power
consumption as they did in the RRC_IDLE state while resuming data transmission
after a short delay because less signaling is exchanged over the air interface and
with the core network. The specific delay varies with factors such as UE processing
and core network capabilities.
6.2.2 Impacts
Network Impacts
After the RRC_INACTIVE state function is enabled, messaging over the Uu and Xn
interfaces may undergo the following changes:
● The signaling over the Uu interface changes, which is mainly caused by state
transitions and periodic RNA updates.
● The number of paging messages over the Uu interface may increase. This is
mainly because RRC_INACTIVE UEs are paged when the network needs to
send data to these UEs.
● The number of messages over the Xn interface may increase, which is mainly
caused by RAN paging for RRC_INACTIVE UEs.
● The numbers of RRC connection setups, security mode setups, and RRC
connection reconfigurations decrease, whereas the number of RRC connection
resumptions increases. Such signaling changes cause a change in the number
of scheduling times, a slight increase in the average modulation and coding
scheme (MCS) index, and a decrease in the average control channel element
(CCE) aggregation level.
● The first packet delay indicated by the N.Traffic.DL.RlcFirstPktDelay.Time
counter increases because the data from the core network arrives at
RRC_INACTIVE UEs faster than at RRC_IDLE UEs.
● Due to the differences in UE processing capabilities, the timing for reporting
CSI-RS measurement results may change. As a result, the service delay
decreases, the HARQ retransmission rate for data transmission of the cell
decreases, and the throughput slightly increases.
● As RRCResume and RRCReconfiguration messages are scheduled differently,
the SRB HARQ retransmission rate changes, and the values of the
N.DL.SCH.QPSK.TB and N.DL.SCH.QPSK.TB.Retrans counters slightly
increase.
● As the number of RNA update messages increases, the uplink resource
overhead increases and the uplink block error rate (BLER) slightly increases.
As a result, the value of Cell Uplink Average Throughput (DU) slightly
decreases.
Function Impacts
RAT Function Function Reference Description
Name Switch
6.3 Requirements
6.3.1 Licenses
There are no license requirements.
6.3.2 Software
Prerequisite Functions
None
6.3.3 Hardware
Base Station Models
3900 and 5900 series base stations. 3900 series base stations must be configured
with the BBU3910.
DBS3900 LampSite and DBS5900 LampSite. DBS3900 LampSite must be
configured with the BBU3910.
Boards
All NR-capable main control boards and baseband processing units support this
function. For details, see the BBU technical specifications in 3900 & 5900 Series
Base Station Product Documentation.
RF Modules
All NR-capable RF modules that work in low frequency bands support this
function. For details, see the technical specifications of RF modules in 3900 & 5900
Series Base Station Product Documentation.
6.3.4 Others
● UE requirements:
UEs for which SUL takes effect do not enter the RRC_INACTIVE state due to
restrictions defined in 3GPP specifications.
UEs must support the RRC_INACTIVE state. The inactiveState IE in the
UECapabilityInformation message over the Uu interface indicates support for
the state.
● Networking requirements:
– An Xn interface must be set up between gNodeBs in an RNA and
between gNodeBs in adjacent RNAs so that the target gNodeB can
retrieve context information from the last serving gNodeB over the Xn
interface during an RNA update.
– gNodeB IDs of long lengths, if required, must be properly planned on the
live network so that the least significant 20 bits of each gNodeB ID are
unique in contiguous coverage areas.
▪ If this option is selected, Huawei base stations signal the Service Area
Information IE and process this IE in compliance with 3GPP TS 38.423
V15.5.0 or later.
Step 1 Start Uu signaling tracing for the cell that is enabled with RRC_INACTIVE state
function as follows: Log in to the MAE-Access and choose Monitor > Signaling
Trace > Signaling Trace Management. On the displayed page, choose Trace Type
> NR > Application Layer > Uu Interface Trace.
Step 2 Check for the suspendConfig IE in the RRC_REL messages of the tracing result. If
the IE is found, the UE has entered the RRC_INACTIVE state and this function has
taken effect.
Step 3 Check for the resumeCause IE in the RRC_RESUME_REQ_1 messages of the tracing
result. If the IE with the value rna-update is found, the RNA has been updated.
----End
Service Setup Delay Observation:
The service setup delay of a UE in the RRC_INACTIVE state is shorter than that in
the RRC_IDLE state due to less signaling being exchanged over the air interface
and with the core network.
Step 1 When a UE is in the RRC_INACTIVE state, observe its service setup duration from
the time when the UE sends a preamble to the time when the UE sends an
RRCResumeComplete message.
Step 2 When the UE is in the RRC_IDLE state, observe the service setup duration from the
time when the UE sends a preamble to the time when the bearer setup is
complete (indicated by the RRCReconfigurationComplete message).
----End
NOTE
According to 3GPP specifications, EN-DC UEs must support all the following types of inter-
frequency handovers in NSA networking: intra-FR1 FDD inter-frequency handover, intra-FR1
TDD inter-frequency handover, intra-FR2 TDD inter-frequency handover, FDD-TDD inter-
frequency handover, and FR1-FR2 inter-frequency handover. For details, see section 4.2.9
"MeasAndMobParameters" in 3GPP TS 38.306 V15.9.0. As such, the gNodeB does not use
the information indicated by the UECapabilityInformation IE reported by a UE over the Uu
interface to determine the inter-frequency handover capability of the UE. Instead, the
gNodeB considers that the UE supports all types of inter-frequency handovers by default.
In NSA networking, measurement gap configuration varies with UE capabilities.
The per UE or per FR1 measurement gap is calculated on the LTE side based on the NR
cell's SMTC information carried in the messages sent over the X2 interface. Therefore, SMTC
parameters must be set to the same values for intra-frequency cells on the NR side to
ensure that the NR cells can be measured. For details, see NSA Networking based on EPC.
The per FR2 measurement gap is calculated on the NR side and forwarded to the eNodeB
over the X2 interface. Then, the eNodeB delivers it to UEs.
For details about UE measurement gap capabilities, see section 9 "Measurement Procedure"
in 3GPP TS 38.133 V15.5.0.
The principles and configurations for the PSCell change mechanisms in different
scenarios are similar to those in SA networking. Therefore, this chapter will only
describe the principles and configurations that are different. For detailed signaling
procedures for PSCell change, see NSA Networking based on EPC. Inter-frequency
PSCell change must be performed within the EN-DC band combinations supported
by the UE's EN-DC capability.
The blind mode and measurement-based mode share the same parameters for
event A2 related to coverage-based inter-frequency measurements. If a UE
reports an event A2 related to coverage-based inter-frequency measurements
and neighboring cells for blind handover are configured, the blind mode, instead
of the measurement-based mode, is triggered.
● Target cell or frequency decision
After receiving an event A2 report related to coverage-based inter-frequency
measurements:
– The neighboring cell with the COV_BASED_BLIND_HO_FLAG option of
the NRCellRelation.BlindHoFlag selected is selected for blind handover.
If there are multiple such cells, the cell on the frequency with a higher
connected-mode priority (specified by the
NRCellFreqRelation.ConnFreqPriority parameter) is preferentially
selected.
– If there are no neighboring cells configured for blind handover (with the
COV_BASED_BLIND_HO_FLAG option of the
NRCellRelation.BlindHoFlag parameter deselected), measurement-
based inter-frequency handover, instead of blind handover, is performed.
The operation and maintenance of blind inter-frequency PSCell change in NSA
networking is as follows:
● Data preparation
Activating blind inter-frequency PSCell change requires that neighboring cells
for blind handover be already configured. For details, see Table 7-1.
Table 7-1 Configuring neighboring cells and the switch for blind handover
Parameter Parameter ID Setting Notes
Name
8 Appendix
configured RNA, the last serving gNodeB sends the UE context to the gNodeB
which then manages the UE context. This is referred to as UE context
relocation. Figure 8-5 illustrates the procedure for RNA update in this case.
a. The UE resumes from the RRC_INACTIVE state, and provides the I-RNTI
assigned by the last serving gNodeB and an appropriate cause value, for
example, RNA update.
b. The gNodeB, if able to resolve the last serving gNodeB's identity
contained in the I-RNTI, requests the last serving gNodeB to provide the
UE context.
c. The last serving gNodeB provides the UE context.
d. The gNodeB instructs the UE to transit back to the RRC_INACTIVE state.
e. The gNodeB provides forwarding addresses if the loss of the downlink
user data buffered in the last serving gNodeB should be prevented. That
is, the gNodeB sends an XN-U ADDRESS INDICATION message to the last
serving gNodeB.
f. The gNodeB performs path switching. That is, the gNodeB sends a PATH
SWITCH REQUEST message to the AMF.
g. The AMF returns a PATH SWITCH REQUEST Acknowledge message to the
gNodeB.
Figure 8-6 Procedure for periodic RNA update without UE context relocation
a. The UE resumes from the RRC_INACTIVE state, and provides the I-RNTI
assigned by the last serving gNodeB and an appropriate cause value, for
example, RNA update.
b. The gNodeB, if able to resolve the last serving gNodeB's identity
contained in the I-RNTI, requests the last serving gNodeB to provide the
UE context, providing the cause value received in step 1.
c. The last serving gNodeB stores received information (such as C-RNTI and
PCI related to the resumption cell) for use in the next resume attempt,
and responds to the gNodeB with a RETRIEVE UE CONTEXT FAILURE
message that includes an encapsulated RRCRelease message. The
RRCRelease message includes the suspendConfig IE.
d. The gNodeB forwards the RRCRelease message to the UE. The UE then
updates the RNA based on the received RRCRelease message including
the suspendConfig IE.
● RNA update with transition to the RRC_IDLE state
If a UE in the RRC_INACTIVE state does not perform any service for a long
time (specified by the UE inactive-to-idle timer
gNBConnStateTimer.UeInactiveToIdleTimer) and the serving gNodeB
remains unchanged, the last serving gNodeB decides to push the UE to the
RRC_IDLE state. Figure 8-7 illustrates the procedure for RNA update in this
case. Particularly, when RAN paging fails for reasons such as no Xn connection
to the last serving gNodeB, the gNodeB also pushes the UE to the RRC_IDLE
state after 10s. The UE then waits for 5GC paging. The procedure for RNA
update for this case is the same as that illustrated in Figure 8-7.
Figure 8-7 Procedure for RNA update with transition to the RRC_IDLE state
a. The UE resumes from the RRC_INACTIVE state, and provides the I-RNTI
assigned by the last serving gNodeB and an appropriate cause value, for
example, RNA update.
b. The gNodeB, if able to resolve the last serving gNodeB's identity
contained in the I-RNTI, requests the last serving gNodeB to provide the
UE context, providing the cause value received in step 1.
c. Instead of providing the UE context, the last serving gNodeB provides an
RRCRelease message that does not include the suspendConfig IE to push
the UE to the RRC_IDLE state.
d. The last serving gNodeB deletes the UE context.
e. The gNodeB sends an RRCRelease message (not including the
suspendConfig IE) which triggers the UE to transit from the
RRC_INACTIVE state to the RRC_IDLE state.
1. The UE resumes from the RRC_INACTIVE state and provides the I-RNTI
assigned by the last serving gNodeB.
2. The gNodeB, if able to resolve the last serving gNodeB's identity contained in
the I-RNTI, requests the last serving gNodeB to provide the UE context.
3. The last serving gNodeB provides the UE context.
4. The gNodeB instructs the UE to resume the RRC_CONNECTED state. That is,
the gNodeB sends an RRCResume message to the UE.
5. The UE enters the RRC_CONNECTED state and returns an
RRCResumeComplete message to the gNodeB.
6. The gNodeB provides forwarding addresses if the loss of the downlink user
data buffered in the last serving gNodeB should be prevented. That is, the
gNodeB sends an XN-U ADDRESS INDICATION message to the last serving
gNodeB.
7. The gNodeB performs path switching. That is, the gNodeB sends a PATH
SWITCH REQUEST message to the AMF.
8. The AMF returns a PATH SWITCH REQUEST RESPONSE message to the
gNodeB.
9. The gNodeB triggers the release of the UE resources at the last serving
gNodeB.
Figure 8-9 illustrates the procedure for network-triggered transition from
RRC_INACTIVE to RRC_CONNECTED.
9 Parameters
The following hyperlinked EXCEL files of parameter reference match the software
version with which this document is released.
● Node Parameter Reference: contains device and transport parameters.
● gNodeBFunction Parameter Reference: contains all parameters related to
radio access functions, including air interface management, access control,
mobility control, and radio resource management.
NOTE
You can find the EXCEL files of parameter reference for the software version used on the
live network from the product documentation delivered with that version.
----End
10 Counters
The following hyperlinked EXCEL files of performance counter reference match the
software version with which this document is released.
● Node Performance Counter Summary: contains device and transport counters.
● gNodeBFunction Performance Counter Summary: contains all counters related
to radio access functions, including air interface management, access control,
mobility control, and radio resource management.
NOTE
You can find the EXCEL files of performance counter reference for the software version used
on the live network from the product documentation delivered with that version.
----End
11 Glossary
12 Reference Documents