Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 38.413  Word version:  16.3.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…   9…   9.2.5…   9.3…   9.3.2…   10…

 

8.4  UE Mobility Management Procedures

8.4.1  Handover Preparation

8.4.1.1  General

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.

8.4.1.2  Successful Operation

Reproduction of 3GPP TS 38.413, Figure 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.
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.
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 within the Handover Command Transfer IE for a given PDU session, then the source NG-RAN node should initiate data forwarding for the listed QoS flows over the forwarding tunnel specified in the DL Forwarding UP TNL Information IE 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.
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 OperationWord‑p. 53
Reproduction of 3GPP TS 38.413, Figure 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 ConditionsWord‑p. 54
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.

8.4.2  Handover Resource Allocation

8.4.2.1  General

The purpose of the Handover Resource Allocation procedure is to reserve resources at the target NG-RAN node for the handover of a UE.

8.4.2.2  Successful Operation

Reproduction of 3GPP TS 38.413, Figure 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.
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, 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.
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.
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.
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.
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. 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).
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 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 e.g. 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 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.
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.
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 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 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 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 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 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.
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 OperationWord‑p. 59
Reproduction of 3GPP TS 38.413, Figure 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.

8.4.2.4  Abnormal Conditions

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.
Up

Up   Top   ToC