Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 38.413  Word version:  18.2.0

Top   Top   Up   Prev   Next
1…   4…   8…   8.2…   8.2.3…   8.3…   8.3.4…   8.4…   8.4.3…   8.5…   8.7…   8.8…   8.10…   8.12…   8.17…   9…   9.2…   9.2.2…   9.2.3…   9.2.4…   9.2.6…   9.2.7…   9.2.9…   9.2.11…   9.2.16…   9.2.17…   9.3…   9.3.1.21…   9.3.1.41…   9.3.1.61…   9.3.1.81…   9.3.1.101…   9.3.1.121…   9.3.1.141…   9.3.1.161…   9.3.1.181…   9.3.1.205…   9.3.1.222…   9.3.1.245…   9.3.2…   9.3.3…   9.3.3.21…   9.3.3.42…   9.3.4…   9.3.4.10…   9.3.5…   9.4…   9.4.4   9.4.5   9.4.6…   9.5…   10…

 

8.4  UE Mobility Management Proceduresp. 65

8.4.1  Handover Preparationp. 65

8.4.1.1  Generalp. 65

The purpose of the Handover Preparation procedure is to request the preparation of resources at the target side via the 5GC. There is only one Handover Preparation procedure ongoing at the same time for a certain UE. The procedure uses UE-associated signalling.

8.4.1.2  Successful Operationp. 65

Reproduction of 3GPP TS 38.413, Fig. 8.4.1.2-1: Handover preparation: successful operation
Up
The source NG-RAN node initiates the handover preparation by sending the HANDOVER REQUIRED message to the serving AMF. When the source NG-RAN node sends the HANDOVER REQUIRED message, it shall start the timer TNGRELOCprep. The source NG-RAN node shall indicate the appropriate cause value for the handover in the Cause IE.
Upon reception of the HANDOVER REQUIRED message the AMF shall, for each PDU session indicated in the PDU Session ID IE, transparently transfer the Handover Required Transfer IE to the SMF associated with the concerned PDU session. If the UE is a mobile IAB-MT and the PDU Session ID IE contained in the HANDOVER REQUIRED message indicates no PDU session identity assigned as defined in TS 24.007, the AMF shall, if supported, consider the mobile IAB-MT has no PDU session, ignore the PDU Session Resource List IE, and behave as specified in TS 23.501.
In case of intra-system handover, the information in the Source to Target Transparent Container IE shall be encoded according to the definition of the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE.
If the DL Forwarding IE is included for a given QoS flow in the PDU Session Resource Information Item IE within the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE of the HANDOVER REQUIRED message and it is set to "DL forwarding proposed", it indicates that the source NG-RAN node proposes forwarding of downlink data for that QoS flow.
If the UL Forwarding IE is included for a given QoS flow in the PDU Session Resource Information Item IE within the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE of the HANDOVER REQUIRED message and it is set to "UL forwarding proposed", it indicates that the source NG-RAN node proposes forwarding of uplink data for that QoS flow.
If the DRBs to QoS Flows Mapping List IE is included in the PDU Session Resource Information Item IE within the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE of the HANDOVER REQUIRED message, it implicitly indicates that the source NG-RAN node proposes forwarding of downlink data for those DRBs.
If the QoS Flow Mapping Indication IE for a QoS flow is included in the Associated QoS Flow List IE within the DRBs to QoS Flows Mapping List IE within the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE of the HANDOVER REQUIRED message, it indicates that the source NG-RAN node has mapped only the uplink or downlink of the QoS flow to the DRB.
The source NG-RAN node shall, for each MRB of each MBS session contained in the MBS Session Information Target to Source List IE, start data forwarding to the TNL address contained in the DL Forwarding UP TNL Information IE. If the MRB Progress Information IE is contained for an MRB in the Data Forwarding Response MRB List IE in the MBS Session Information Target to Source List IE, the source NG-RAN node may use this information to determine when to stop data forwarding.
In case of intra-system handover, if the HANDOVER COMMAND message contains the DL Forwarding UP TNL Information IE for a given DRB within the Data Forwarding Response DRB List IE in the Handover Command Transfer IE, the source NG-RAN node shall consider that the forwarding of downlink data for this DRB is accepted by the target NG-RAN node. If the HANDOVER COMMAND message contains the UL Forwarding UP TNL Information IE for a given DRB in the Data Forwarding Response DRB List IE within the Handover Command Transfer IE, it means the target NG-RAN node has requested the forwarding of uplink data for this DRB.
In case direct data forwarding is applied for inter-system handover, if the Data Forwarding Response E-RAB List IE in the Handover Command Transfer IE is included in the HANDOVER COMMAND message, the source NG-RAN node shall consider that forwarding of downlink data for this E-RAB is accepted by the target eNB.
If the HANDOVER COMMAND message contains the UL Forwarding UP TNL Information IE for a given PDU session within the Handover Command Transfer IE, the source NG-RAN node shall consider that the forwarding of uplink data of the QoS flows is accepted by the target NG-RAN node.
In case of inter-system handover to LTE, the information in the Source to Target Transparent Container IE shall be encoded according to the Source eNB to Target eNB Transparent Container IE definition as specified in TS 36.413.
If the Direct Forwarding Path Availability IE is included in the HANDOVER REQUIRED message the AMF shall handle it as specified in TS 23.502.
If the Direct Forwarding Path Availability IE is included within the Handover Required Transfer IE of the HANDOVER REQUIRED message the SMF shall handle it as specified in TS 23.502.
When the preparation, including the reservation of resources at the target side is ready, the AMF responds with the HANDOVER COMMAND message to the source NG-RAN node. In case of intra-system handover, the AMF shall include the PDU Session Resource Handover List IE in the HANDOVER COMMAND message.
Upon reception of the HANDOVER COMMAND message the source NG-RAN node shall stop the timer TNGRELOCprep and start the timer TNGRELOCoverall.
If there are any PDU sessions that could not be admitted in the target, they shall be indicated in the PDU Session Resource to Release List IE.
If the HANDOVER COMMAND message contains the QoS Flow to be Forwarded List IE and/or Data Forwarding Response DRB List IE within the Handover Command Transfer IE for a given PDU session, then the source NG-RAN node should initiate data forwarding for the QoS flows as specified in TS 38.300.
If the HANDOVER COMMAND message contains the Additional DL Forwarding UP TNL Information IE within the Handover Command Transfer IE, the source NG-RAN node should initiate data forwarding of the PDU session split in different tunnel and shall use the received UP transport layer information for the forwarding QoS flows associated to it.
If the HANDOVER COMMAND message contains the Additional UL Forwarding UP TNL Information IE within the Handover Command Transfer IE, the source NG-RAN node should initiate data forwarding of the PDU session split in different tunnels using the received UP transport layer information.
If the NAS Security Parameters from NG-RAN IE is included in the HANDOVER COMMAND message the NG-RAN node shall use it as specified in TS 33.501.
If the Target to Source Transparent Container IE has been received by the AMF from the handover target then the transparent container shall be included in the HANDOVER COMMAND message.
If the HANDOVER COMMAND message contains the QoS Flow Failed to Setup List IE within the Handover Command Transfer IE, the source NG-RAN node shall consider that the listed QoS flows are failed to be handed over.
In case of inter-system handover to LTE, the information in the Target to Source Transparent Container IE shall be encoded according to the definition of the Target eNB to Source eNB Transparent Container IE as specified in TS 36.413.
If the Index to RAT/Frequency Selection Priority IE is contained in the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE, the target NG-RAN node shall store the content of the received Index to RAT/Frequency Selection Priority IE in the UE context and use it as defined in TS 23.501.
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 REQUIRED message, it indicates that the request concerns a DAPS Handover for that DRB, as described in TS 38.300.
Interactions with other NGAP procedures:
If, after a HANDOVER REQUIRED message is sent and before the Handover Preparation procedure is terminated, the source NG-RAN node receives an AMF initiated PDU Session Management procedure on the same UE-associated signalling connection, the source NG-RAN node shall either:
  1. Cancel the Handover Preparation procedure by executing the Handover Cancellation procedure with an appropriate cause value. After successful completion of the Handover Cancellation procedure, the source NG-RAN node shall continue the AMF initiated PDU Session Management procedure.
or
  1. Terminate the AMF initiated PDU Session Management procedure by sending the appropriate response message with an appropriate cause value, e.g. "NG intra-system handover triggered" or "NG inter-system handover triggered" to the AMF and then the source NG-RAN node shall continue with the handover procedure.
Up

8.4.1.3  Unsuccessful Operationp. 67

Reproduction of 3GPP TS 38.413, Fig. 8.4.1.3-1: Handover preparation: unsuccessful operation
Up
If the 5GC or the target side is not able to accept any of the PDU session resources or a failure occurs during the Handover Preparation, the AMF sends the HANDOVER PREPARATION FAILURE message with an appropriate cause value to the source NG-RAN node.
If the Target to Source Failure Transparent Container IE has been received by the AMF from the handover target then the transparent container shall be included in the HANDOVER PREPARATION FAILURE message.
If the Target to Source Failure Transparent Container IE is received in the HANDOVER PREPARATION FAILURE message including the Cell CAG Information IE, the source NG-RAN node shall, if supported, store and replace the PNI-NPN information associated with the indicated cell.
Interaction with Handover Cancel procedure:
If there is no response from the AMF to the HANDOVER REQUIRED message before timer TNGRELOCprep expires in the source NG-RAN node, the source NG-RAN node should cancel the Handover Preparation procedure by initiating the Handover Cancel procedure with the appropriate value for the Cause IE. The source NG-RAN node shall ignore any HANDOVER COMMAND message or HANDOVER PREPARATION FAILURE message received after the initiation of the Handover Cancel procedure.
Up

8.4.1.4  Abnormal Conditionsp. 67

In case of inter-system handover, if the NG-RAN node receives at least one PDU Session ID included in the PDU Session Resource Handover List IE without at least one valid associated GTP tunnel address pair (in either UL or DL), then the NG-RAN node shall consider it as a logical error and act as described in subclause 10.4. A GTP tunnel address pair is considered valid if both the GTP-TEID IE and the Endpoint IP Address IE are present.
Up

8.4.2  Handover Resource Allocationp. 68

8.4.2.1  Generalp. 68

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.

8.4.2.2  Successful Operationp. 68

Reproduction of 3GPP TS 38.413, Fig. 8.4.2.2-1: Handover resource allocation: successful operation
Up
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.
Up

8.4.2.3  Unsuccessful Operationp. 75

Reproduction of 3GPP TS 38.413, Fig. 8.4.2.3-1: Handover resource allocation: unsuccessful operation
Up
If the target NG-RAN node does not admit any of the PDU session resources, or a failure occurs during the Handover Preparation, it shall send the HANDOVER FAILURE message to the AMF with an appropriate cause value.
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 does not accept the request for handover, for each included NGAP Protocol IE-Id provided within the Target NG-RAN Node to Source NG-RAN Node Failure Transparent Container IE in the HANDOVER FAILURE 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.
Up

8.4.2.4  Abnormal Conditionsp. 76

If the supported algorithms for encryption defined in the Encryption Algorithms IE in the UE Security Capabilities IE, plus the mandated support of EEA0 and NEA0 in all UEs (TS 33.501), do not match any allowed algorithms defined in the configured list of allowed encryption algorithms in the NG-RAN node (TS 33.501), the target NG-RAN node shall reject the procedure using the HANDOVER FAILURE message.
If the supported algorithms for integrity defined in the Integrity Protection Algorithms IE in the UE Security Capabilities IE, plus the mandated support of the EIA0 and NIA0 algorithm in all UEs (TS 33.501), do not match any allowed algorithms defined in the configured list of allowed integrity protection algorithms in the NG-RAN node (TS 33.501), the target NG-RAN node shall reject the procedure using the HANDOVER FAILURE message.
If the target NG-RAN node receives a HANDOVER REQUEST message which does not contain the Mobility Restriction List IE, and the serving PLMN cannot be determined otherwise by the NG-RAN node, the target NG-RAN node shall reject the procedure using the HANDOVER FAILURE message.
If the target NG-RAN node receives a HANDOVER REQUEST message containing the Mobility Restriction List IE, and the serving PLMN indicated is not supported by the target cell, the target NG-RAN node shall reject the procedure using the HANDOVER FAILURE message.
If the target NG-RAN node receives a HANDOVER REQUEST message containing an Allowed PNI-NPN List IE in the Mobility Restriction List IE which does not allow access to the cell indicated in the Target Cell ID IE, the target NG-RAN node shall reject the procedure using the HANDOVER FAILURE message with an appropriate cause value and may include the Cell CAG Information IE corresponding to this cell and the selected PLMN.
If the target NG-RAN node receives a HANDOVER REQUEST message containing a Serving PLMN IE and Serving NID IE in the Mobility Restriction List IE which does not allow access to the cell indicated in the Target Cell ID IE, the target NG-RAN node shall reject the procedure using the HANDOVER FAILURE message with an appropriate cause value.
If the PNI-NPN Area Scope of MDT IE is included in the MDT Configuration-NR IE in the HANDOVER REQUEST message, and the Area Scope of MDT IE is set to "PNI-NPN Based MDT", the NG-RAN node shall, if supported, use the Area Scope of MDT IE to derive the MDT area scope for MDT measurement collection in PNI-NPN areas, and ignore the PNI-NPN Area Scope of MDT IE.
If the Partially Allowed NSSAI IE is received in the HANDOVER REQUEST message and the total number of S-NSSAIs included in the Allowed NSSAI and Partially Allowed NSSAI exceeds eight, the NG-RAN node shall consider the procedure as failed.
If any of the S-NSSAI which is present in the Partially Allowed NSSAI IE is also present in the Allowed NSSAI IE, the NG-RAN node shall consider the procedure as failed.
Up

Up   Top   ToC