Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 29.502  Word version:  18.7.0

Top   Top   Up   Prev   Next
1…   5…   5.2.2…   5.2.2.2.4…   5.2.2.3…   5.2.2.3.2…   5.2.2.3.3…   5.2.2.3.6…   5.2.2.3.8…   5.2.2.3.10…   5.2.2.3.17…   5.2.2.3.23…   5.2.2.4…   5.2.2.8…   5.2.2.8.2…   5.2.2.8.2.7…   5.2.2.8.2.12…   5.2.2.8.2.20…   5.2.2.8.3…   5.2.2.8.3.6…   5.2.2.9…   5.2.3…   6…   6.1.2…   6.1.3…   6.1.3.3…   6.1.3.5…   6.1.3.6…   6.1.3.7…   6.1.4…   6.1.6…   6.1.6.2…   6.1.6.2.5…   6.1.6.2.11…   6.1.6.2.18…   6.1.6.2.27…   6.1.6.2.40…   6.1.6.2.54…   6.1.6.2.65…   6.1.6.3…   6.1.6.4…   6.1.7…   A…   B…   C… 
5.2.2.3.3 Xn Handover  5.2.2.3.4 N2 Handover  5.2.2.3.4.1 General  5.2.2.3.4.2 N2 Handover Preparation  5.2.2.3.4.3 N2 Handover Execution  5.2.2.3.4.4 N2 Handover Cancellation  5.2.2.3.5 Handover between 3GPP and untrusted non-3GPP access procedures  5.2.2.3.5.1 General  5.2.2.3.5.2 Handover of a PDU session without AMF change or with target AMF in same PLMN 
...

 

5.2.2.3.3  Xn Handover  p. 35
The NF Service Consumer (e.g. AMF) shall request the SMF to switch the downlink N3 tunnel of the PDU session towards a new GTP tunnel endpoint as follows.
Reproduction of 3GPP TS 29.502, Fig. 5.2.2.3.3-1: Xn handover
Figure 5.2.2.3.3-1: Xn handover
Up
Step 1.
The NF Service Consumer shall request the SMF to switch the downlink N3 tunnel of the PDU session towards a new GTP tunnel endpoint by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:
  • the indication that the PDU session is to be switched;
  • N2 SM information received from the target 5G-AN (see Path Switch Request Transfer IE in clause 9.3.4.8 of TS 38.413), including the new transport layer address and tunnel endpoint of the downlink termination point for the user data for this PDU session (i.e. 5G-AN's GTP-U F-TEID for downlink traffic);
  • additional N2 SM information received from the source 5G-AN (see Secondary RAT Data Usage Report Transfer IE in clause 9.3.4.23 of TS 38.413), if any;
  • the user location associated to the PDU session;
  • the indication that the UE is inside or outside of the LADN service area, if the DNN of the established PDU session corresponds to a LADN;
  • other information, if necessary.
Step 2a.
If the SMF can proceed with switching the user plane connection of the PDU session, the SMF shall return a 200 OK response including the following information:
  • N2 SM information (see Path Switch Request Acknowledge Transfer IE in clause 9.3.4.9 of TS 38.413), including the transport layer address and tunnel endpoint of the uplink termination point for the user data for this PDU session (i.e. UPF's GTP-U F-TEID for uplink traffic).
If the request does not include the "UE presence in LADN service area" indication and the SMF determines that the DNN corresponds to a LADN, then the SMF shall consider that the UE is outside of the LADN service area. The SMF shall proceed as specified in clause 5.6.5 of TS 23.501.
Step 2b.
If the SMF cannot proceed with switching the user plane connection of the PDU session, the SMF shall return an error response, as specified for step 2b of Figure 5.2.2.3.1-1, including:
For a PDU session that is rejected by the target RAN (i.e. a PDU session indicated as failed to setup in the PATH SWITCH REQUEST), the NF Service Consumer (e.g. AMF) shall indicate the failure to setup the PDU session in the target RAN as follows.
Reproduction of 3GPP TS 29.502, Fig. 5.2.2.3.3-2: Xn handover - PDU session rejected by the target RAN
Figure 5.2.2.3.3-2: Xn handover - PDU session rejected by the target RAN
Up
Step 1.
The NF Service Consumer shall indicate to the SMF that the PDU session could not be setup in the target RAN by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:
  • the indication that the PDU session failed to be switched;
  • N2 SM information received from the target 5G-AN (see Path Switch Request Setup Failed Transfer IE in clause 9.3.4.15 of TS 38.413), including the cause why the session could not be setup;
  • additional N2 SM information received from the source 5G-AN (see Secondary RAT Data Usage Report Transfer IE in clause 9.3.4.23 of TS 38.413), if any;
  • other information, if necessary.
Step 2a.
Upon receipt of such a request, the SMF shall return a "204 No Content" response. The SMF shall decide whether to release the PDU session or deactivate the user plane connection of the PDU session, as specified in clause 4.9.1.2 of TS 23.502.
Step 2b.
Same as step 2b of Figure 5.2.2.3.1-1.
Up
5.2.2.3.4  N2 Handover  p. 37
5.2.2.3.4.1  General  p. 37
The hoState attribute of an SM context represents the handover state of the PDU session. The hoState attribute may take the following values:
  • NONE: no handover is in progress for the PDU session;
  • PREPARING: a handover is in preparation for the PDU session; SMF is preparing the N3 tunnel between the target 5G-AN and UPF, i.e. the UPF's F-TEID is assigned for uplink traffic;
  • PREPARED: a handover is prepared for the PDU session; SMF is updated for the N3 tunnel between the target 5G-AN and UPF, with the target 5G-AN's F-TEID to be assigned for downlink traffic upon handover execution;
  • COMPLETED: the handover is completed (successfully);
  • CANCELLED: the handover is cancelled.
Up
5.2.2.3.4.2  N2 Handover Preparation  p. 37
The NF Service Consumer (e.g. T-AMF) shall request the SMF to prepare the handover of an existing PDU session, i.e. prepare the N3 tunnel between the target 5G-AN and UPF, as follows.
Reproduction of 3GPP TS 29.502, Fig. 5.2.2.3.4.2-1: N2 Handover Preparation
Figure 5.2.2.3.4.2-1: N2 Handover Preparation
Up
Step 1.
The NF Service Consumer shall request the SMF to prepare the handover of the PDU session by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:
  • updating the hoState attribute of the individual SM Context resource in the SMF to PREPARING;
  • targetId identifying the target RAN Node ID and TAI received in the Handover Required from the source NG-RAN;
  • targetServingNfId set to the target AMF Id, for a N2 handover with AMF change;
  • N2 SM information received from the source NG-RAN (see Handover Required Transfer IE in clause 9.3.4.14 of TS 38.413), indicating whether a direct path is available;
  • the supportedFeatures IE indicating the features it supports, if at least one feature defined in clause 6.1.8 is supported;
  • other information, if necessary.
Step 2a.
Upon receipt of such a request, if the SMF can proceed with preparing the handover of the PDU session (see clause 4.9.1.3 of TS 23.502), the SMF shall set the hoState attribute to PREPARING and shall return a 200 OK response including the following information:
  • hoState attribute set to PREPARING;
  • N2 SM information to request the target 5G-AN to assign resources to the PDU session (see PDU Session Resource Setup Request Transfer IE in clause 9.3.4.1 of TS 38.413), including (among others) the transport layer address and tunnel endpoint of the uplink termination point for the user plane data for this PDU session (i.e. UPF's GTP-U F-TEID for uplink traffic);
  • the supportedFeatures IE in the response, if the supportedFeatures IE was received in the request and at least one feature defined in clause 6.1.8 is supported by the updated SM context resource.
The SMF shall store the targetServingNfId, if received in the request, but the SMF shall still consider the AMF (previously) received in the servingNfId IE as the serving AMF for the UE.
Step 2b.
If the SMF cannot proceed with preparing the handover of the PDU session (e.g. the UE moves into a non-allowed service area, the SMF cannot select a suitable I-UPF, or the UE is only reachable for regulatory prioritized services), the SMF shall set the hoState to NONE and return an error response, as specified in step 2b of Figure 5.2.2.3.1-1. For a 4xx/5xx response, the SmContextUpdateError structure shall include the following additional information:
  • N2 SM information (see Handover Preparation Unsuccessful Transfer IE in clause 9.3.4.18 of TS 38.413) indicating the cause of the failure;
  • the cause in the error attribute set to one of the application errors listed in Table 6.1.3.3.4.2.2-2.
When receiving a 4xx/5xx response from the SMF, the NF service consumer (e.g. the AMF) shall regard the hoState of the SM Context to be NONE.
Step 3.
If the SMF returned a 200 OK response in step 2a, the NF Service Consumer (e.g. AMF) shall subsequently update the SM context in the SMF by sending POST request, as specified in clause 5.2.2.3.1, with the following information:
  • hoState attribute set to PREPARED;
  • N2 SM information received from the target 5G-AN (see Handover Request Acknowledge Transfer IE in clause 9.3.4.11 of TS 38.413), including (among others) the transport layer address and tunnel endpoint of the downlink termination point for the user data for this PDU session (i.e. target 5G-AN's GTP-U F-TEID for downlink traffic), if the target 5G-AN succeeded in establishing resources for the PDU session;
  • N2 SM information received from the target 5G-AN (see Handover Resource Allocation Unsuccessful Transfer IE in clause 9.3.4.19 of TS 38.413), including the Cause of the failure, if resources failed to be established for the PDU sessions.
Step 4a.
If the target 5G-AN succeeded in establishing resources for the PDU sessions, the SMF shall set the hoState attribute to PREPARED and return a 200 OK response including the following information:
Step 4b.
If the SMF cannot proceed with preparing the handover of the PDU session (e.g. the target 5G-AN failed to establish resources for the PDU session), the SMF shall set the hoState to NONE, release resources reserved for the handover to the target 5G-AN, and return an error response as specified in step 2b of Figure 5.2.2.3.1-1. For a 4xx/5xx response, the SmContextUpdateError structure shall include the following additional information:
  • N2 SM information (see Handover Preparation Unsuccessful Transfer IE in clause 9.3.4.18 of TS 38.413) indicating the cause of the failure;
  • the cause in the error attribute set to HANDOVER_RESOURCE_ALLOCATION_FAILURE, if the target 5G-AN failed to establish resources for the PDU session.
When receiving a 4xx/5xx response from the SMF, the NF service consumer (e.g. the AMF) shall regard the hoState of the SM Context to be NONE.
If the handover preparation fails completely on the target 5G-AN (i.e. target 5G-AN returns a NGAP HANDOVER_FAILURE), the (T-)AMF shall request the SMF to cancel the handover of the PDU session as described in clause 5.2.2.3.4.4.
Up
5.2.2.3.4.3  N2 Handover Execution  p. 39
The NF Service Consumer (e.g. T-AMF) shall request the SMF to complete the execution the handover of an existing PDU session, upon being notified by the target 5G-AN that the handover to the target 5G-AN has been successful, as follows.
Reproduction of 3GPP TS 29.502, Fig. 5.2.2.3.4.3-1: N2 Handover Execution
Figure 5.2.2.3.4.3-1: N2 Handover Execution
Up
Step 1.
The NF Service Consumer shall request the SMF to complete the execution of the handover of the PDU session by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:
  • updating the hoState attribute of the individual SM Context resource in the SMF to COMPLETED;
  • servingNfId set to the new serving AMF Id, for a N2 handover with AMF change;
  • the indication that the UE is inside or outside of the LADN service area, if the DNN of the established PDU session corresponds to a LADN;
  • N2 SM information received from the source 5G-AN (see Secondary RAT Data Usage Report Transfer IE in clause 9.3.4.23 of TS 38.413), if any;
  • other information, if necessary.
Step 2.
Upon receipt of such a request, the SMF shall return a 200 OK response including the following information:
  • hoState attribute set to COMPLETED.
The SMF shall complete the execution of the handover, e.g. switch the PDU session towards the downlink termination point for the user data received from the target 5G-AN (i.e. target 5G-AN's GTP-U F-TEID for downlink traffic), set the hoState to NONE and delete any stored targetServingNfId. For PDU session with I-SMF insertion, the I-SMF shall complete the execution of the handover by initiating an Update service operation towards the anchor SMF in order to switch the PDU session towards the I-UPF controlled by I-SMF (see clause 5.2.2.8.2.12).
If the request does not include the "UE presence in LADN service area" indication and the SMF determines that the DNN corresponds to a LADN, then the SMF shall consider that the UE is outside of the LADN service area. The SMF shall proceed as specified in clause 5.6.5 of TS 23.501.
The (T-)AMF shall request the SMF to complete the execution of the handover of the PDU session only for those PDU sessions that successfully completed the handover procedure.
If there are PDU sessions that failed to handover due to timeout of SMF responses in any step of the handover preparation phase (e.g. if the Update SM Context Response arrived too late or not at all during the handover preparation phase, see step 7 of clause 4.9.1.3.3 of TS 23.502), then the (T-)AMF shall inform the SMF about this failure, by sending a POST request with the cause attribute set to "HO_FAILURE" for every such PDU session, upon receipt of the NGAP HANDOVER NOTIFY. The SMF shall then consider that the PDU session is deactivated and that the handover attempt is terminated for the PDU session. The SMF may subsequently release the PDU session, or the SMF may keep the PDU session with the User Plane deactived by setting the hoState to NONE and deleting any stored targetServingNfId. If the SMF decided to keep the PDU session, the SMF shall forward DL traffic towards the target 5G-AN, i.e. activate the User Plane via the target AMF upon reception of DL traffic. For PDU session with I-SMF insertion, the I-SMF shall handle the HO Failure following the procedure described in clause 5.2.2.8.2.12.
If the handover fails completely on the target 5G-AN due to the execution phase not completed successfully (i.e. missing NGAP HANDOVER NOTIFY), the (T-)AMF shall request the SMF to cancel the handover of the PDU session as described in clause 5.2.2.3.4.4.
Up
5.2.2.3.4.4  N2 Handover Cancellation  p. 40
The NF Service Consumer (e.g. T-AMF) shall request the SMF to cancel the handover of an existing PDU session, e.g. upon receipt of such a request from the source 5G-AN, as follows.
Reproduction of 3GPP TS 29.502, Fig. 5.2.2.3.4.4-1: N2 Handover Cancellation
Figure 5.2.2.3.4.4-1: N2 Handover Cancellation
Up
Step 1.
The NF Service Consumer shall request the SMF to cancel the execution of the handover of the PDU session by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:
  • updating the hoState attribute of the individual SM Context resource in the SMF to CANCELLED;
  • cause information;
  • other information, if necessary.
Step 2.
Upon receipt of such a request, the SMF return a 200 OK response including the following information:
  • hoState attribute set to CANCELLED.
The SMF shall cancel the execution of the handover, e.g. release resources reserved for the handover to the target 5G-AN, set the hoState to NONE and delete any stored targetServingNfId. For PDU Session with I-SMF insertion, the I-SMF shall cancel the handover by initiating an Update service operation towards the anchor SMF in order to release resources at the SMF and PSA UPF reserved during handover preparation (see clause 5.2.2.8.2.13).
Up
5.2.2.3.5  Handover between 3GPP and untrusted non-3GPP access procedures  p. 41
5.2.2.3.5.1  General  p. 41
The handover of a PDU session between 3GPP and untrusted non-3GPP access shall be supported as specified in clause 4.9.2 of TS 23.502. Such a handover may involve:
For a Home-Routed PDU session, the target AMF may be located in the VPLMN, or in the HPLMN when the N3IWF is in the HPLMN.
Up
5.2.2.3.5.2  Handover of a PDU session without AMF change or with target AMF in same PLMN  p. 41
In these scenarios, the same V-SMF is used before and after the handover.
The NF Service Consumer (e.g. AMF) shall request the SMF to handover an existing PDU session from 3GPP access to untrusted non-3GPP access, or vice-versa, as follows.
Reproduction of 3GPP TS 29.502, Fig. 5.2.2.3.5.2-1: Handover between 3GPP and untrusted non-3GPP access
Figure 5.2.2.3.5.2-1: Handover between 3GPP and untrusted non-3GPP access
Up
Step 1.
The NF Service Consumer shall request the SMF to handover an existing PDU session from 3GPP access to untrusted non-3GPP access, or vice-versa, by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:
  • updating the anType attribute of the individual SM Context resource in the SMF to the target access type, i.e. to 3GPP_ACCESS or NON_3GPP_ACCESS;
  • other information, if necessary.
Step 2a.
Same as step 2a of Figure 5.2.2.3.1-1.
Step 2b.
If the SMF cannot proceed with handing over the PDU session to the target access type, the SMF shall return an error response, as specified for step 2b of Figure 5.2.2.3.1-1. For a 4xx/5xx response, the SmContextUpdateError structure shall include the following additional information:
  • N1 SM Information to reject the UE request.
The anchor SMF may perform Network Slice Admission Control before the PDU Session is moved to the target access (i.e., before the N3 tunnel for the PDU Session is established).
Up

Up   Top   ToC