The purpose of the Handover Resource Allocation procedure is to reserve resources at the target NG-RAN node for the handover of a UE. The procedure uses UE-associated signalling.
The AMF initiates the procedure by sending the HANDOVER REQUEST message to the target NG-RAN node.
If the
Masked IMEISV IE is contained in the HANDOVER REQUEST message the target NG-RAN node shall, if supported, use it to determine the characteristics of the UE for subsequent handling.
Upon receipt of the HANDOVER REQUEST message the target NG-RAN node shall
-
attempt to execute the requested PDU session configuration and associated security;
-
store the received UE Aggregate Maximum Bit Rate in the UE context, and use the received UE Aggregate Maximum Bit Rate for all Non-GBR QoS flows for the concerned UE as specified in TS 23.501;
-
store the received Mobility Restriction List in the UE context;
-
store the received UE Security Capabilities in the UE context;
-
store the received Security Context in the UE context and take it into use as defined in TS 33.501;
-
if supported, store the received UE Slice Maximum Bit Rate List in the UE context and use the received UE Slice Maximum Bit Rate List for each S-NSSAI for the concerned UE as specified in TS 23.501.
-
if supported, store the received PDU Set QoS parameters in the UE context and use it as specified in TS 23.501.
Upon reception of the
UE History Information IE, which is included within the
Source to Target Transparent Container IE of the HANDOVER REQUEST message, the target NG-RAN node shall collect the information defined as mandatory in the
UE History Information IE and shall, if supported, collect the information defined as optional in the
UE History Information IE, for as long as the UE stays in one of its cells, and store the collected information to be used for future handover preparations.
Upon receiving the
PDU Session Resource Setup List IE contained in the HANDOVER REQUEST message and the HANDOVER REQUEST message does not contain the
No PDU Session Indication IE, the target NG-RAN node shall behave the same as defined in the PDU Session Resource Setup procedure. The target NG-RAN node shall report to the AMF in the HANDOVER REQUEST ACKNOWLEDGE message the result for each PDU session resource requested to be setup. In particular, for each PDU session resource successfully setup, it shall include the
Handover Request Acknowledge Transfer IE containing the following information:
-
The list of QoS flows which have been successfully established in the QoS Flow Setup Response List IE.
-
The Data Forwarding Accepted IE if the data forwarding for the QoS flow is accepted.
-
The list of QoS flows which have failed to be established, if any, in the QoS Flow Failed to Setup List IE.
-
The UP transport layer information to be used for the PDU session.
-
The security result associated to the PDU session.
-
The redundant UP transport layer information to be used for the redundant transmission for the PDU session.
-
The PDU Set based Handling Indicator if the HANDOVER REQUEST message includes the PDU Set QoS Parameters IE.
-
The ECN Marking or Congestion Information Reporting Status if the HANDOVER REQUEST message includes the ECN Marking or Congestion Information Reporting Request IE.
For each PDU session resource which failed to be setup, the
Handover Resource Allocation Unsuccessful Transfer IE shall be included in the HANDOVER REQUEST ACKNOWLEDGE message containing a cause value that should be precise enough to enable the SMF to know the reason for the unsuccessful establishment.
For each PDU session included in the HANDOVER REQUEST ACKNOWLEDGE message, if the
Current QoS Parameters Set Index IE is included for a QoS flow in the
QoS Flow Setup Response List IE within the
Handover Request Acknowledge Transfer IE the SMF shall consider it as the currently fulfilled QoS parameters set among the alternative QoS parameters for the involved QoS flow.
Upon reception of the HANDOVER REQUEST ACKNOWLEDGE message the AMF shall, for each PDU session indicated in the
PDU Session ID IE, transfer transparently the
Handover Request Acknowledge Transfer IE or
Handover Resource Allocation Unsuccessful Transfer IE to the SMF associated with the concerned PDU session.
If the HANDOVER REQUEST message contains the
Data Forwarding Not Possible IE associated with a given PDU session within the
Handover Request Transfer IE set to
"data forwarding not possible", the target NG-RAN node may not include the
DL Forwarding UP TNL Information IE and for intra-system handover the
Data Forwarding Response DRB List IE within the
Handover Request Acknowledge Transfer IE in the HANDOVER REQUEST ACKNOWLEDGE message for that PDU session.
If the HANDOVER REQUEST message contains the
Redundant PDU Session Information IE associated with a given PDU session within the
Handover Request Transfer IE, the target NG-RAN node shall, if supported, store the received information in the UE context and use it for redundant PDU session setup as specified in TS38.300 [8] and
TS 23.501. If the
PDU Session Type IE is set to
"ethernet" and the redundancy requirement is fulfilled using a secondary NG-RAN node, the NG-RAN node shall, if supported, include the
Global RAN Node ID of Secondary NG-RAN Node IE in the
Handover Request Acknowledge Transfer IE of the HANDOVER REQUEST ACKNOWLEDGE message. If the
PDU Session Pair ID IE is included in the
Redundant PDU Session Information IE, the NG-RAN node may use it to identify the paired PDU sessions.
For each PDU session for which the
Global RAN Node ID of Secondary NG-RAN Node IE is included in the
Handover Request Acknowledge Transfer IE of the HANDOVER REQUEST ACKNOWLEDGE message, the SMF shall, if supported, handle this information as specified in
TS 23.501.
In case of intra-system handover, if the target NG-RAN node accepts the downlink data forwarding for at least one QoS flow for which the
DL Forwarding IE is set to
"DL forwarding proposed", it may include the
DL Forwarding UP TNL Information IE in the
Handover Request Acknowledge Transfer IE as forwarding tunnel for the QoS flows listed in the
QoS Flow Setup Response List IE of the HANDOVER REQUEST ACKNOWLEDGE message.
In case of intra-system handover, if the target NG-RAN node accepts the uplink data forwarding for at least one QoS flow for which the
UL Forwarding IE is set to
"UL forwarding proposed", it may include the
UL Forwarding UP TNL Information IE in the
Handover Request Acknowledge Transfer IE for the PDU session within the
PDU Session Resource Admitted List IE of the HANDOVER REQUEST ACKNOWLEDGE message.
In case of intra-system handover, for each PDU session for which the
Additional DL UP TNL Information for HO List IE is included in the
Handover Request Acknowledge Transfer IE of the HANDOVER REQUEST ACKNOWLEDGE message, the SMF shall consider the included
Additional DL NG-U UP TNL Information IE as the downlink termination point for the associated flows indicated in the
Additional QoS Flow Setup Response List IE for this PDU session split in different tunnels and shall consider the
Additional DL Forwarding UP TNL Information IE, if included, as the forwarding tunnel associated to these QoS flows.
In case of intra-system handover, for each PDU session for which the
Additional UL Forwarding UP TNL Information IE is included in the
Handover Request Acknowledge Transfer IE of the HANDOVER REQUEST ACKNOWLEDGE message, the SMF shall consider it as the termination points for the uplink forwarding tunnels for this PDU session split in different tunnels.
In case of intra-system handover, if the target NG-RAN node accepts the data forwarding for a successfully configured DRB, the target NG-RAN node may include the
DL Forwarding UP TNL Information IE for the DRB within the
Data Forwarding Response DRB List IE within
Handover Request Acknowledge Transfer IE of the HANDOVER REQUEST ACKNOWLEDGE message.
In case of intra-system handover, if the target NG-RAN node receives the
Direct Forwarding Path Availability IE set to
"direct path available" within the
PDU Session Resource Setup Request Transfer IE, the target NG-RAN node shall, if supported, assign the UP transport layer information for intra-system direct data forwarding from the appropriate address space, if applicable.
If the HANDOVER REQUEST ACKNOWLEDGE message contains the
UL Forwarding UP TNL Information IE for a given DRB in the
Data Forwarding Response DRB List IE within the
Handover Request Acknowledge Transfer IE, it indicates the target NG-RAN node has requested the forwarding of uplink data for the DRB.
In case of inter-system handover from E-UTRAN, if the
PDU Session Resource Setup Request Transfer IE contains the
Direct Forwarding Path Availability IE set to
"direct path available", the target NG-RAN node shall, if supported, and if it accepts downlink data forwarding for the QoS flows mapped to an E-RAB of an admitted PDU session, include the
DL Forwarding UP TNL Information IE in the
Data Forwarding Response E-RAB List IE in the
Handover Request Acknowledge Transfer IE in the HANDOVER REQUEST ACKNOWLEDGE message for that mapped E-RAB.
In case of inter-system handover from E-UTRAN, the target NG-RAN node includes the
Data Forwarding Accepted IE for each QoS flow that the
DL Forwarding IE is set to
"DL forwarding proposed" for the corresponding E-RAB in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE and that the target NG-RAN node has admitted the proposed forwarding of downlink data for the QoS flow. If indirect data forwarding is applied for inter-system handover, if the target NG-RAN node accepts the downlink data forwarding for at least one QoS flow of an admitted PDU session it shall include the
DL Forwarding UP TNL Information IE in the
PDU Session Resource Setup Response Transfer IE for that PDU session within the
PDU Session Resources Admitted List IE of the HANDOVER REQUEST ACKNOWLEDGE message.
In case of inter-system handover from E-UTRAN with direct forwarding, if the target NG-RAN node receives the
SgNB UE X2AP ID IE in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE, it may use it for internal forwarding as described in
TS 37.340.
In case of inter-system handover from E-UTRAN, if the target cell is a CAG cell, the target NG-RAN node shall include the
NPN Access Information IE in the HANDOVER REQUEST ACKNOWLEDGE message, and the AMF shall consider that the included information is associated to the target cell and to the UE's serving PLMN Identity, and use it as specified in
TS 23.501.
The target NG-RAN node shall use the information in the
Mobility Restriction List IE if present in the HANDOVER REQUEST message to
-
determine a target for subsequent mobility action for which the target NG-RAN node provides information about the target of the mobility action towards the UE;
-
select a proper SCG during dual connectivity operation;
-
assign proper RNA(s) for the UE when moving the UE to RRC_INACTIVE state.
If the
Mobility Restriction List IE is not contained in the HANDOVER REQUEST message, the target NG-RAN node shall consider that no roaming and no access restriction apply to the UE except for the PNI NPN mobility as described in
TS 23.501. The target NG-RAN node shall also consider that no roaming and no access restriction apply to the UE when:
-
one of the QoS flows includes a particular ARP value (TS 23.501).
The NG-RAN node shall consider that roaming or access to CAG cells is only allowed if the
Allowed PNI-NPN List IE is contained in the HANDOVER REQUEST message, as described in
TS 23.501.
If the
Trace Activation IE is included in the HANDOVER REQUEST message the target NG-RAN node shall, if supported, initiate the requested trace function as described in
TS 32.422. In particular, the NG-RAN node shall, if supported:
-
if the Trace Activation IE includes the MDT Activation IE set to "Immediate MDT and Trace", initiate the requested trace session and MDT session as described in TS 32.422;
-
if the Trace Activation IE includes the MDT Activation IE set to "Immediate MDT Only", "Logged MDT only", initiate the requested MDT session as described in TS 32.422 and the target NG-RAN node shall ignore the Interfaces To Trace IE and the Trace Depth IE;
-
if the Trace Activation IE includes the MDT Location Information IE within the MDT Configuration IE, store this information and take it into account in the requested MDT session;
-
if the Trace Activation IE includes the Signalling Based MDT PLMN List IE within the MDT Configuration IE, the NG-RAN node may use it to propagate the MDT Configuration as described in TS 37.320.
-
if the Trace Activation IE includes the Bluetooth Measurement Configuration IE within the MDT Configuration IE, take it into account for MDT Configuration as described in TS 37.320.
-
if the Trace Activation IE includes the WLAN Measurement Configuration IE within the MDT Configuration IE, take it into account for MDT Configuration as described in TS 37.320.
-
if the Trace Activation IE includes the Sensor Measurement Configuration IE within the MDT Configuration IE, take it into account for MDT Configuration as described in TS 37.320.
-
if the Trace Activation IE includes the MDT Configuration IE and if the NG-RAN node is a gNB at least the MDT Configuration-NR IE shall be present, while if the NG-RAN node is an ng-eNB at least the MDT Configuration-EUTRA IE shall be present.
-
if the Trace Activation IE includes the MN Only MDT Collection IE and the MN Only MDT Collection IE is set to "MN only", consider that the MDT Configuration-NR IE or the MDT Configuration-EUTRA IE is only applicable for the MN if the UE is configured with MR-DC.
If the
Location Reporting Request Type IE is included in the HANDOVER REQUEST message, the target NG-RAN node should perform the requested location reporting functionality for the UE as described in
subclause 8.12.
If the
Core Network Assistance Information for RRC INACTIVE IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information in the UE context and use it for the RRC_INACTIVE state decision and RNA configuration for the UE and RAN paging if any for a UE in RRC_INACTIVE state, as specified in
TS 38.300. If the
MICO All PLMN IE is included in the
Core Network Assistance Information for RRC INACTIVE IE the NG-RAN node shall, if supported, consider that the registration area for the UE is the full PLMN and ignore the
TAI List for RRC Inactive IE. If the
Paging Cause Indication for Voice Service IE is included in the
Core Network Assistance Information for RRC INACTIVE IE, the NG-RAN node shall, if supported, store and use it as specified in
TS 38.300. If the
PEIPS Assistance Information IE is included in the
Core Network Assistance Information for RRC INACTIVE IE, the NG-RAN node shall, if supported, store it and use it for paging subgrouping the UE in RRC_INACTIVE state, as specified in
TS 38.300. If the
CN MT Communication Handling IE is included in the
Core Network Assistance Information for RRC INACTIVE IE, the NG-RAN node shall, if supported, store it and may subsequently request, based on implementation, the CN for MT communication handling as described in
TS 23.502.
If the
CN Assisted RAN Parameters Tuning IE is included in the HANDOVER REQUEST message, the NG-RAN node may use it as described in
TS 23.501.
If the
New Security Context Indicator IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall use the information as specified in
TS 33.501.
If the
NASC IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall use it towards the UE as specified in
TS 33.501.
If the
RRC Inactive Transition Report Request IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, store this information in the UE context.
If the
Redirection for Voice EPS Fallback IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, store it and use it in a subsequent decision of EPS fallback for voice as specified in
TS 23.502.
If the
SRVCC Operation Possible IE is included in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the content of the received
SRVCC Operation Possible IE in the UE context and use it as defined in
TS 23.216.
If the
IAB Authorized IE is contained in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, consider that the handover is for an IAB node and use it as specified in
TS 38.401.
If the
Mobile IAB Authorized IE is contained in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, consider that the handover is for a mobile IAB-node. In addition, if the
No PDU Session Indication IE is contained in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, consider the mobile IAB-MT does not have any PDU sessions, ignore the
PDU Session Resource Setup List IE, and it shall not take any action with respect to PDU session setup. Subsequently, the AMF shall, if supported, ignore the
PDU Session Resources Admitted List IE in the HANDOVER REQUEST ACKNOWLEDGE message.
If the
Enhanced Coverage Restriction IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, store this information in the UE context and use it as defined in
TS 23.501.
If the
UE Differentiation Information IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, store this information in the UE context for further use according to
TS 23.501.
If the
UE User Plane CIoT Support Indicator IE is included in the HANDOVER REQUEST message the NG-RAN node shall, if supported, store this information in the UE context and consider that User Plane CIoT 5GS Optimisation as specified in
TS 23.501 is supported for the UE.
Upon reception of the
UE History Information from UE IE, which is included within the
Source to Target Transparent Container IE of the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the collected information and use it for future handover preparations.
After all necessary resources for the admitted PDU session resources have been allocated, the target NG-RAN node shall generate the HANDOVER REQUEST ACKNOWLEDGE message.
If the
RedCap Indication IE or the
eRedCap Indication IE is included in the HANDOVER REQUEST ACKNOWLEDGE message, the AMF shall, if supported, consider the
UE respectively as a RedCap UE or an eRedCap UE that was previously served by a E-UTRA cell, and use the IE according to
TS 23.501.
For each QoS flow which has been established in the target NG-RAN node, if the
QoS Monitoring Request IE was included in the
QoS Flow Level QoS Parameters IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall store this information, and, if supported, perform delay measurement and QoS monitoring, as specified in
TS 23.501. If the
QoS Monitoring Reporting Frequency IE was included in the
QoS Flow Level QoS Parameters IE contained in the HANDOVER REQUEST message, the target NG-RAN node shall store this information and, if supported, use it for RAN part delay reporting.
If the
NR V2X Services Authorized IE is contained in the HANDOVER REQUEST message and it contains one or more IEs set to
"authorized", the NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).
If the
LTE V2X Services Authorized IE is contained in the HANDOVER REQUEST message and it contains one or more IEs set to
"authorized", the NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).
If the
NR A2X Services Authorized IE is contained in the
HANDOVER REQUEST message and it contains one or more IEs set to
"authorized", the NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).
If the
LTE A2X Services Authorized IE is contained in the
HANDOVER REQUEST message and it contains one or more IEs set to
"authorized", the NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).
If the
NR UE Sidelink Aggregate Maximum Bit Rate IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use the received value for the concerned UE's sidelink communication in network scheduled mode for NR V2X services.
If the
LTE UE Sidelink Aggregate Maximum Bit Rate IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use the received value for the concerned UE's sidelink communication in network scheduled mode for LTE V2X services.
If the
NR A2X UE PC5Aggregate Maximum Bit Rate IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use the received value for the concerned UE's sidelink communication in network scheduled mode for NR A2X services.
If the
LTE A2X UE PC5 Aggregate Maximum Bit Rate IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use the received value for the concerned UE's sidelink communication in network scheduled mode for LTE A2X services.
If the
PC5 QoS Parameters IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use it as defined in
TS 23.287.
If the
A2X PC5 QoS Parameters IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use it as defined in
TS 23.256.
If the
CE-mode-B Restricted IE is included in the HANDOVER REQUEST message and the
Enhanced Coverage Restriction IE is not set to
"restricted" and the Enhanced Coverage Restriction information stored in the UE context is not set to
"restricted", the NG-RAN node shall, if supported, store this information in the UE context and use it as defined in
TS 23.501.
If the
Management Based MDT PLMN List IE is contained in the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store the received information in the UE context, and use this information to allow subsequent selections of the UE for management based MDT defined in
TS 32.422.
If the HANDOVER REQUEST message contains the
UE Radio Capability ID IE, the NG-RAN node shall, if supported, use it as specified in
TS 23.501 and
TS 23.502.
If the
DAPS Request Information IE is included for a DRB in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE within the HANDOVER REQUEST message, the target NG-RAN node shall consider that the request concerns a DAPS Handover for that DRB, as described in
TS 38.300. The target NG-RAN node shall include the
DAPS Response information List IE in the
Target NG-RAN Node to Source NG-RAN Node Transparent Container IE within the HANDOVER REQUEST ACKNOWLEDGE message, containing the
DAPS Response Information IE for each DRB requested to be configured with DAPS Handover.
If the
Extended Connected Time IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use it as described in
TS 23.501.
If the target NG-RAN node receives the
UE Context Reference at Source IE in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE within the HANDOVER REQUEST message, it may use it to identify an existing UE.
If the
Source Node ID IE is included in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE within the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, use it to decide whether direct forwarding path is available between the target NG-RAN node and this source RAN node. If the direct forwarding path is available, the target NG-RAN node shall include the
Direct Forwarding Path Availability IE in the
Target NG-RAN Node to Source NG-RAN Node Transparent Container IE within the HANDOVER REQUEST ACKNOWLEDGE message.
In case there are MBS sessions the UE has joined, for all the MBS sessions the UE has joined, the SMF shall, if supported, include the
MBS Session Setup Request List IE within the
PDU Session Resource Setup Request Transfer IE in the HANDOVER REQUEST message.
If the HANDOVER REQUEST message contains the
MBS Session Setup Request List IE in a
PDU Session Resource Setup Request Transfer IE the NG-RAN node shall, if supported, use it as specified in
TS 23.247 and
TS 38.300.
If the
MBS Active Session Information Source to Target List IE is contained in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE within the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, assume the indicated MBS sessions to be active and establish MBS session resources as specified in
TS 23.247 and
TS 38.300, if applicable. The target NG-RAN node shall, if supported, consider that the MBS sessions the UE has joined which are not included in the
MBS Active Session Information Source to Target List IE are inactive.
If the
MBS Area Session ID IE is included in the
MBS Active Session Information Source to Target List IE in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE within the HANDOVER REQUEST message, the target NG-RAN shall use this information as indication from which MBS Area Session ID the UE is handed over.
If the
MBS Service Area IE is included in the
MBS Active Session Information Source to Target List IE in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE within the HANDOVER REQUEST message, the target NG-RAN shall use this information to setup respective MBS session resources, if applicable.
If the target NG-RAN node decides to allocate resource for data forwarding for an active MBS session, respective information is provided for that MBS session within the
Data Forwarding Response MRB List IE in the
MBS Active Session Information Target to Source List IE in the
Target NG-RAN Node to Source NG-RAN Node Transparent Container IE.
If the
Time Synchronisation Assistance Information IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, store the information in the UE context and use it as defined in
TS 23.501.
If the
5G ProSe Authorized IE is contained in the
HANDOVER REQUEST message and it contains one or more IEs set to
"authorized", the NG-RAN node shall, if supported, consider that the UE is authorized for the relevant service(s).
If the
5G ProSe UE PC5 Aggregate Maximum Bit Rate IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use the received value for the concerned UE's sidelink communication in network scheduled mode for 5G ProSe services.
If the
5G ProSe PC5 QoS Parameters IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use it as defined in
TS 23.304.
If for a given QoS flow the
Source Transport Layer Address IE is included within the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE of the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information and use it as part of its ACL functionality configuration actions for direct data forwarding, if such ACL functionality is deployed and if direct forwarding path is available between the target NG-RAN node and this source RAN node.
If for a given QoS flow the
Source Node Transport Layer Address IE is included within the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE of the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information and use it as part of its ACL functionality configuration actions for direct data forwarding, if such ACL functionality is deployed and if direct forwarding path is available between the target NG-RAN node and this source RAN node.
If for a given E-RAB the
Source Transport Layer Address IE is included within the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE of the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information and use it as part of its ACL functionality configuration actions for direct data forwarding, if such ACL functionality is deployed and if direct forwarding path is available between the target NG-RAN node and this source RAN node.
If for a given E-RAB the
Source Node Transport Layer Address IE is included within the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE of the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, store this information and use it as part of its ACL functionality configuration actions for direct data forwarding, if such ACL functionality is deployed and if direct forwarding path is available between the target NG-RAN node and this source RAN node.
If the HANDOVER REQUEST message contains within the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE the
NGAP IE Support Information Request List IE, the target NG-RAN node shall, if supported and the target NG-RAN node accepts the request for handover, for each included NGAP Protocol IE-Id provided within the
Target NG-RAN Node to Source NG-RAN Node Transparent Container IE in the HANDOVER REQUEST ACKNOWLEDGE message
-
set the NGAP Protocol IE Support Information IE to "supported" if the target NG-RAN node has information that the functionality associated with the indicated IE is supported
-
set the NGAP Protocol IE Support Information IE to "not-supported" if the target NG-RAN node has information that the functionality associated with the indicated IE is not supported
on the interface instance via which the HANDOVER REQUEST message has been received, and
-
set the NGAP Protocol IE Presence Information IE to "present" if the target NG-RAN node has received the respective NGAP Protocol IE-Id in the HANDOVER REQUEST message, and "not-present" otherwise.
If the HANDOVER REQUEST message contains within the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE the
Time Based Handover Information IE, the target NG-RAN node may use this information to allocate necessary resources for the incoming handover.
If the
Candidate Relay UE Information List IE is included in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE within the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, use it to configure the path switch to indirect path as specified in
TS 38.300.
If the
QMC Configuration Information IE is included in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE within the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, take it into account for QoE management handling, as described in
TS 38.300.
If the
Source SN to Target SN QMC Information IE is included in the
Source NG-RAN Node to Target NG-RAN Node Transparent Container IE within the HANDOVER REQUEST message, the target NG-RAN node shall, if supported, take it into account for QoE management handling, as described in
TS 37.340.
If the
Aerial UE Subscription Information IE is included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, store this information in the UE context and use it as defined in
TS 38.300.
If the
PNI-NPN Area Scope of MDT IE is included in the
MDT Configuration-NR IE included in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, use it to derive the MDT area scope for MDT measurement collection in PNI-NPN areas. Upon reception of the
PNI-NPN Area Scope of MDT IE, the NG-RAN node shall consider that the area scope for MDT measurement collection in PNI-NPN areas is defined only by the areas included in the
PNI-NPN Area Scope of MDT IE.
If the
Partially Allowed NSSAI IE is contained in the HANDOVER REQUEST message, the NG-RAN node shall, if supported, deduce from it the partially allowed network slices for the UE, store and replace any previously received Partially Allowed NSSAI and use it as specified in
TS 23.501.
If the
MBS Support Indicator IE is included in the
Handover Request Acknowledge Transfer IE in the HANDOVER REQUEST ACKNOWLEDGE message, the SMF shall, if supported, handle this information as specified in
TS 23.247.
If the
ECN Marking or Congestion Information Reporting Status IE is included in the
Handover Request Acknowledge Transfer IE, the SMF shall, if supported, use it to deduce if ECN marking at NG-RAN or ECN marking at UPF or congestion information reporting is active or not active as described in
TS 23.501.
Interactions with RRC Inactive Transition Report procedure:
If the
RRC Inactive Transition Report Request IE is included in the HANDOVER REQUEST message and set to
"subsequent state transition report", the NG-RAN node shall, if supported, send the RRC INACTIVE TRANSITION REPORT message to the AMF to report the RRC state of the UE when the UE enters or leaves RRC_INACTIVE state.