5.2.2 Service Operations

29.5023GPP5G SystemRelease 16Session Management ServicesStage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.2.2.1 Introduction

See Table 5.2.1-1 for an overview of the service operations supported by the Nsmf_PDUSession service.

5.2.2.2 Create SM Context service operation

5.2.2.2.1 General

The Create SM Context service operation shall be used to create an individual SM context, for a given PDU session, in the SMF, in the V-SMF for HR roaming scenarios, or in the I-SMF for a PDU session with an I-SMF.

It is used in the following procedures:

– UE requested PDU Session Establishment (see clauses 4.3.2 and 4.23.5.1 of 3GPP TS 23.502 [3]);

– EPS to 5GS Idle mode mobility, EPS to 5GS Idle mode mobility with data forwarding or handover using N26 interface (see clauses 4.11.1, 4.23.12.3, 4.23.12.5 and 4.23.12.7 of 3GPP TS 23.502 [3]);

– EPS to 5GS mobility without N26 interface (see clause 4.11.2.3 3GPP TS 23.502 [3]);

– Handover of a PDU session between 3GPP access and non-3GPP access, when the target AMF does not know the SMF resource identifier of the SM context used by the source AMF, e.g. when the target AMF is not in the PLMN of the N3IWF (see clause 4.9.2.3.2 of 3GPP TS 23.502 [3]), or when the UE is roaming and the selected N3IWF is in the HPLMN (see clause 4.9.2.4.2 of 3GPP TS 23.502 [3]);

– Handover from EPS to 5GC-N3IWF (see clause 4.11.3.1 of 3GPP TS 23.502 [3]);

– Handover from EPC/ePDG to 5GS (see clause 4.11.4.1 of 3GPP TS 23.502 [3]);

– Xn based or N2 based handover with I-SMF or V-SMF insertion and change (see clauses 4.23.7.3, 4.23.11 and 4.23.12 of 3GPP TS 23.502 [3]);

– UE Triggered Service Request with I-SMF insertion/change/removal or V-SMF change (see clause 4.23.4.3 of 3GPP TS 23.502 [3]);

– Registration procedure for a UE with a PDU session with I-SMF or V-SMF insertion, change and removal (see clause 4.23.3 of 3GPP TS 23.502 [3]);

– Handover from EPC/ePDG to 5GS with I-SMF insertion (see clause 4.23 of 3GPP TS 23.502 [3]);

– Handover from non-3GPP to 3GPP access with I-SMF insertion or V-SMF change, and Handover from 3GPP to non-3GPP access with I-SMF removal (see clause 4.23.16 of 3GPP TS 23.502 [3]);

– SMF Context Transfer procedure, LBO or no Roaming, no I-SMF (see clause 4.26.5.3 of 3GPP TS 23.502 [3]);

– I-SMF Context Transfer procedure (see clause 4.26.5.2 of 3GPP TS 23.502 [3]);

– 5G-RG requested PDU Session Establishment via W-5GAN (see clause 7.3.1 of 3GPP TS 23.316 [36]);

– FN-RG related PDU Session Establishment via W-5GAN (see clause 7.3.4 of 3GPP TS 23.316 [36]);

– Non-5G capable device behind 5G-CRG and FN-CRG requested PDU Session Establishment via W-5GAN (see clause 4.10a of 3GPP TS 23.316 [36]);

– Handover from 3GPP access/EPS to W-5GAN/5GC (see clause 7.6.4.1 of 3GPP TS 23.316 [36]).

There shall be only one individual SM context per PDU session.

The NF Service Consumer (e.g. AMF) shall create an SM context by using the HTTP POST method as shown in Figure 5.2.2.2.1-1.

Figure 5.2.2.2.1-1: SM context creation

1. The NF Service Consumer shall send a POST request to the resource representing the SM contexts collection resource of the SMF. The payload body of the POST request shall contain:

– a representation of the individual SM context resource to be created;

– the Request Type IE, if it is received from the UE for a single access PDU session and if the request refers to an existing PDU session or an existing Emergency PDU session; the Request Type IE shall not be included for a MA-PDU session establishment request; it may be included otherwise;

– the Old PDU Session ID, if it is received from the UE (i.e. for a PDU session establishment for the SSC mode 3 operation);

– the indication that the UE is inside or outside of the LADN (Local Area Data Network) service area, if the DNN corresponds to a LADN;

– the indication that a MA-PDU session is requested if a MA-PDU session is requested to be established by the UE, or the indication that the PDU session is allowed to be upgraded to a MA-PDU session if so indicated by the UE;

– the anType;

– the additionalAnType, if the UE is registered over both 3GPP and Non-3GPP accesses;

– the cpCiotEnabled IE with the value "True", if the NF service consumer (e.g. the AMF) has verified that the CIOT feature is supported by the SMF (and for a home-routed session, that it is also supported by the H-SMF), and Control Plane CIoT 5GS Optimisation is enabled for this PDU session;

– the cpOnlyInd IE with the value "True", if the PDU session shall only use Control Plane CIoT 5GS Optimisation;

– the Invoke NEF indication with the value "True" for a home-routed PDU session, if the cpCiotEnabled IE is set to "True" and data delivery via NEF is selected for the PDU session;

– a subscription for SM context status notification;

– the servingNfId identifying the serving AMF;

– trace control and configuration parameters, if trace is to be activated (see 3GPP TS 32.422 [22]);

– identifiers (i.e. FQDN or IP address) of N3 terminations at the W-AGF, TNGF or TWIF, if available;

– a subscription for DDN failure notification, if the Availability after DDN failure event is subscribed by the UDM.

For the UE requested PDU Session Establishment procedure in home routed roaming scenario (see clause 4.3.2.2.2 of 3GPP TS 23.502 [3]), the NF Service Consumer shall provide the URI of the Nsmf_PDUSession service of the H-SMF in the hSmfUri IE and optionally the corresponding SMF ID, and may provide the URI of the Nsmf_PDUSession service of additional H-SMF(s) with the corresponding SMF ID(s). The V-SMF shall try to create the PDU session using the hSmfUri IE. If due to communication failure on the N16 interface the V-SMF does not receive any response from the H-SMF, then:

– depending on operator policy, the V-SMF may try reaching the hSmfUri via an alternate path; or

– if additional H-SMF URI is provided, the V-SMF may try to create the PDU session on one of the additional H-SMF(s) provided.

For a PDU session establishment with an I-SMF (see clause 4.23.5.1 of of 3GPP TS 23.502 [3]), the NF Service Consumer shall provide the URI of the Nsmf_PDUSession service of the SMF in the smfUri IE and optionally the corresponding SMF ID, and may provide the URI of the Nsmf_PDUSession service of additional SMF(s) with the corresponding SMF ID(s). The I-SMF shall try to create the PDU session using the smfUri IE. If due to communication failure on the N16a interface the I-SMF does not receive any response from the SMF, then:

– depending on operator policy, the I-SMF may try reaching the smfUri via an alternate path; or

– if additional SMF URI is provided, the I-SMF may try to create the PDU session on one of the additional SMF(s) provided.

For the UE requested PDU Session Establishment procedure, if the AMF determines that the RAT type is NB-IoT and the UE has already 2 PDU Sessions with user plane resources activated, the AMF may continue with the PDU Session establishment and include the cpCiotEnabled IE or cpOnlyInd IE with the value "True" to the SMF as specified in clause 4.3.2.2.1 of 3GPP TS 23.502 [3].

The payload body of the POST request may further contain:

– the name of the AMF service to which SM context status notification are to be sent (see clause 6.5.2.2 of 3GPP TS 29.500 [4]), encoded in the serviceName attribute.

2a. On success, "201 Created" shall be returned, the payload body of the POST response shall contain the representation describing the status of the request and the "Location" header shall be present and shall contain the URI of the created resource. The authority and/or deployment-specific string of the apiRoot of the created resource URI may differ from the authority and/or deployment-specific string of the apiRoot of the request URI received in the POST request.

If the Request Type was received in the request and set to EXISTING_PDU_SESSION or EXISTING_EMERGENCY_PDU_SESSION (i.e. indicating that this is a UE request for an existing PDU session or an existing emergency PDU session), the SMF shall identify the existing PDU session or emergency PDU session based on the PDU Session ID; in this case, the SMF shall not create a new SM context but instead update the existing SM context and provide the representation of the updated SM context in the "201 Created" response to the NF Service Consumer.

The POST request shall be considered as colliding with an existing SM context if:

– it includes the same SUPI, or PEI for an emergency registered UE without a UICC or without an authenticated SUPI, and the same PDU Session ID as for an existing SM context; and

– this is a request to establish a new PDU session, i.e.:

– the RequestType IE is present in the request and set to INITIAL_REQUEST or INITIAL_EMERGENCY_REQUEST (e.g. single access PDU session establishment request);

– the RequestType IE and the maRequestInd IE are both absent in the request (e.g. EPS to 5GS mobility); or

– the maRequestInd IE is present in the request (i.e. MA-PDU session establishment request) and the access type indicated in the request corresponds to the access type of the existing SM context.

A POST request that collides with an existing SM context shall be treated as a request for a new SM context. Before creating the new SM context, the SMF should delete the existing SM context locally and any associated resources in the UPF and PCF. See also clause 5.2.3.3.1 for the handling of requests which collide with an existing SM context. If the smContextStatusUri of the existing SM context differs from the smContextStatusUri received in the POST request, the SMF shall also send an SM context status notification (see clause 5.2.2.5) targeting the smContextStatusUri of the existing SM context to notify the release of the existing SM context. For a HR PDU session, if the H-SMF URI in the request is different from the H-SMF URI of the existing PDU session, the V-SMF should also delete the existing PDU session in the H-SMF by invoking the Release service operation (see clause 5.2.2.9). For a PDU session with an I-SMF, if the SMF URI in the request is different from the SMF URI of the existing PDU session, the I-SMF should also delete the existing PDU session in the SMF by invoking the Release service operation (see clause 5.2.2.9).

If the Request Type was received in the request and indicates this is a request for a new PDU session (i.e. INITIAL_REQUEST) and if the Old PDU Session ID was also included in the request, the SMF shall identify the existing PDU session to release and to which the new PDU session establishment relates, based on the Old PDU Session ID.

If no GPSI IE is provided in the request, e.g. for a PDU session moved from another access or another system, and the SMF knows that a GPSI is already associated with the PDU session (or a GPSI is received from h-SMF for a HR PDU session), the SMF shall include the GPSI in the response.

2b. 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 reject the request if the UE is outside of the LADN service area.

On failure, or redirection during a UE requested PDU Session Establishment, one of the HTTP status code listed in Table 6.1.3.2.3.1-3 shall be returned. For a 4xx/5xx response, the message body shall contain an SmContextCreateError structure, including:

– a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.2.3.1-3;

– N1 SM information (PDU Session Reject), if the request included N1 SM information, except if the error prevents the SMF from generating a response to the UE (e.g. invalid request format).

5.2.2.2.2 EPS to 5GS Idle mode mobility using N26 interface (with or without data forwarding)

The NF Service Consumer (e.g. AMF) shall request the SMF to move a UE EPS PDN connection to 5GS using N26 interface, as follows.

Figure 5.2.2.2.2-1: EPS to 5GS Idle mode mobility using N26 interface

1. The NF Service Consumer shall send a POST request towards the SMF (+PGW-C) of each UE EPS PDN connection, as specified in clause 5.2.2.2.1, with the following additional information:

– UE EPS PDN connection, including the EPS bearer contexts, received from the MME, representing the individual SM context resource to be created;

– the pduSessionsActivateList attribute, including the PDU Session ID of all the PDU session(s) to be re-activated;

– the epsBearerCxtStatus attribute, indicating the status of all the EPS bearer contexts in the UE, if corresponding information is received in the Registration Request from the UE;

– the dlDataWaitingInd attribute, indicating that DL data buffered in EPS needs to be forwarded to the UE, if such indication is present in the Context Response received from the MME.

2a. Upon receipt of such a request, if:

– a corresponding PDU session is found based on the EPS bearer contexts (after invoking a Create service operation towards the H-SMF for a Home Routed PDU session, or towards the SMF for a PDU session with an I-SMF);

– the default EPS bearer context of the corresponding PDU session is not reported as inactive by the UE in the epsBearerCtxStatus attribute, if received; and

– it is possible to proceed with moving the PDN connection to 5GS,

then the SMF shall return a 201 Created response including the following information:

– PDU Session ID corresponding to the default EPS bearer ID of the EPS PDN connection;

– S-NSSAI assigned to the PDU session; in home routed roaming case, the S-NSSAI for home PLMN shall be returned;

– the allocatedEbiList attribute, containing the EBI(s) allocated to the PDU session;

and, if the PDU session that is derived by the SMF based on the EPS bearer contexts was requested to be re-activated, i.e. if the PDU Session ID was present in the pduSessionsActivateList,or if DL data buffered in EPS needs to be forwarded to the UE:

– the upCnxState attribute set to ACTIVATING;

– N2 SM information to request the 5G-AN to assign resources to the PDU session (see PDU Session Resource Setup Request Transfer IE in clause 9.3.4.1 of 3GPP TS 38.413 [9]), 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 "Location" header shall be present in the POST response and shall contain the URI of the created SM context resource.

If the epsBearerCxtStatus attribute is received in the request, the SMF shall check whether some EPS bearer(s) of the corresponding PDU session have been deleted by the UE but not notified to the EPS, and if so, the SMF shall release these EPS bearers, corresponding QoS rules and QoS flow level parameters locally, as specified in clause 4.11.1.3.3 of 3GPP TS 23.502 [3].

The NF Service Consumer (e.g. AMF) shall store the association of the PDU Session ID and the SMF ID, and store the allocated EBI(s) associated to the PDU Session ID.

NOTE: The behaviour specified in this step also applies if the POST request collides with an existing SM context, i.e. if the POST request includes the same SUPI, or PEI for an emergency registered UE without a UICC or without an authenticated SUPI, and the default EPS bearer ID received in the UE EPS PDN connection is the same as in the existing SM context.

2b. Same as step 2b of figure 5.2.2.2.1-1. Steps 3 to 4 are skipped in this case.

If the SMF determines that seamless session continuity from EPS to 5GS is not supported for the PDU session, the SMF shall set the "cause" attribute in the ProblemDetails structure to "NO_EPS_5GS_CONTINUITY".

If the default EPS bearer context of the PDU session is reported as inactive by the UE in the epsBearerCtxStatus attribute, the SMF shall set the "cause" attribute in the ProblemDetails structure to "DEFAULT_EPS_BEARER_INACTIVE".

3. Same as step 3 of figure 5.2.2.3.2.2-1, if the SMF returned a 201 Created response with the upConnectionState set to ACTIVATING and N2 SM Information,

4. Same as step 4 of figure 5.2.2.3.2.2-1. During an EPS to 5GS Idle mode mobility using N26 interface with data forwarding (see clause 4.11.1.3.3A of 3GPP TS 23.502 [3]), the 200 OK response shall additionally contain the CN tunnel information for data forwarding from EPS, i.e. the forwardingFTeid attribute or the forwarding bearer contexts to be sent to the MME in the Context Acknowledge, based on the association between the EPS bearer ID(s) and QFI(s) for the QoS flow(s).

5.2.2.2.3 EPS to 5GS Handover Preparation using N26 interface

The NF Service Consumer (e.g. AMF) shall request the SMF to handover a UE EPS PDN connection to 5GS using N26 interface, as follows.

Figure 5.2.2.2.3-1: EPS to 5GS handover using N26 interface

1. The NF Service Consumer shall send a POST request, as specified in clause 5.2.2.2.1, with the following additional information:

– UE EPS PDN connection, including the EPS bearer contexts, representing the individual SM context resource to be created;

– hoState attribute set to PREPARING (see clause 5.2.2.3.4.1);

– the indication of whether direct or indirect DL data forwarding applies;

– targetId identifying the target RAN Node ID and TAI based on the Target ID IE received in the Forward Relocation Request message from the source MME.

NOTE 1: The Target ID IE can be set to the Target NG-RAN Node ID containing a Global RAN Node ID and selected TAI with 3-octets length, or the Target eNB ID containing a Global eNB ID and selected TAI with 2-octets length; for the latter case, the NF Service Consumer, i.e. the AMF needs determine a value for the Target NG-RAN Node ID and TAI with 3-octets length based on the local configuration to be provided to the SMF.

2a. Upon receipt of such a request, if a corresponding PDU session is found based on the EPS bearer contexts (after invoking a Create service operation towards the H-SMF, for a Home Routed PDU session) and it is possible to proceed with handing over the PDN connection to 5GS, the SMF shall return a 201 Created response including the following information:

– hoState attribute set to PREPARING and N2 SM information to request the target 5G-AN to assign resources to the PDU session, as specified in step 2 of Figure 5.2.2.3.4.2-1; if the SMF was indicated in step 1 that direct data forwarding is applicable, the SMF shall include an indication that a direct forwarding path is available in the N2 SM information;

– PDU Session ID corresponding to the default EPS bearer ID of the EPS PDN connection;

– S-NSSAI assigned to the PDU session; in home routed roaming case, the S-NSSAI for home PLMN shall be returned;

– allocatedEbiList, containing the EBI(s) allocated to the PDU session.

The "Location" header shall be present in the POST response and shall contain the URI of the created SM context resource.

The NF Service Consumer (e.g. AMF) shall store the association of the PDU Session ID and the SMF ID, and store the allocated EBI(s) associated to the PDU Session ID.

NOTE 2: The behaviour specified in this step also applies if the POST request collides with an existing SM context, i.e. if the POST request includes the same SUPI, or PEI for an emergency registered UE without a UICC or without an authenticated SUPI, and the default EPS bearer ID received in the UE EPS PDN connection is the same as in the existing SM context.

2b. Same as step 2b of figure 5.2.2.2.1-1 with the following additions. Steps 3 and 4 of figure 5.2.2.3.8.2-1 are skipped in this case.

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.

5.2.2.2.4 I-SMF Insertion, Change or Removal during Xn based Handover

The NF Service Consumer (e.g. AMF) shall request the I-SMF (for I-SMF insertion or change) or the SMF (for I-SMF removal) to create a SM context during Xn based handover, as follows.

1. The NF Service Consumer shall send a POST request, with the following additional information:

– N2 SM information received from the target 5G-AN (see Path Switch Request Transfer IE in clause 9.3.4.8 of 3GPP TS 38.413 [9]);

– 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 3GPP TS 38.413 [9]), if any;

– the smContextRef attribute set to the identifier of the SM Context resource in the SMF during I-SMF insertion, or the SM Context resource in the source I-SMF during I-SMF change or removal, and optionally the NF instance identifier of the SMF hosting the SM Context resource;

– the smfUri IE attribute set to the API URI of the Nsmf_PDUSession service of the SMF during I-SMF insertion or change, and optionally the NF instance identifier of the SMF, if the "ACSCR" feature is not supported by the AMF and I-SMF.

2a. On success, the SMF shall return a 201 Created response.

The "Location" header shall be present in the POST response and shall contain the URI of the created SM context resource.

The NF Service Consumer (e.g. AMF) shall store the association of the PDU Session ID and the SMF ID.

2b. Same as step 2b of figure 5.2.2.2.1-1.

If the Path Swith Request Transfer IE is included within the N2 SM Information in the request message but the path switch failed, the message body shall contain an SmContextCreateError structure, including:

– N2 SM information (Path Swith Request Unsuccessful Transfer).

5.2.2.2.5 I-SMF Insertion, Change or Removal during N2 based Handover

The NF Service Consumer (e.g. AMF) shall request the I-SMF (for I-SMF insertion or change) or the SMF (for I-SMF removal) to create a SM context during N2 based handover, as follows.

1. The NF Service Consumer shall send a POST request, with the following additional information:

– N2 SM information received from the source NG-RAN (see Handover Required Transfer IE in clause 9.3.4.14 of 3GPP TS 38.413 [9]);

– the hoState attribute set to PREPARING (see clause 5.2.2.3.4.1);

– the smContextRef attribute set to the identifier of the SM Context resource in the SMF during I-SMF insertion,,or the SM Context resource in the source I-SMF during I-SMF change or removal, and optionally the NF instance identifier of the SMF hosting the SM Context resource;

2a. On success, the SMF shall return a 201 Created response including the following information:

– hoState attribute set to PREPARING and N2 SM information to request the target 5G-AN to assign resources to the PDU session, as specified in step 2 of Figure 5.2.2.3.4.2-1;

The "Location" header shall be present in the POST response and shall contain the URI of the created SM context resource.

The NF Service Consumer (e.g. AMF) shall store the association of the PDU Session ID and the SMF ID.

2b. Same as step 2b of figure 5.2.2.2.1-1.

5.2.2.2.6 Service Request with I-SMF insertion/change/removal or with V-SMF change

The NF Service Consumer (e.g. AMF) shall request the new I-SMF or new V-SMF to create a SM context during a Service Request with I-SMF insertion/change or with V-SMF change, or shall request the SMF to create a SM context during a Service Request with I-SMF removal, as follows.

Figure 5.2.2.2.6-1: Service Request with I-SMF insertion/change/removal or with V-SMF change

1. The NF Service Consumer shall send a POST request as specified in clause 5.2.2.2.1, with the following additional information:

– the smContextRef attribute set to the identifier of the SM Context resource in the SMF (for a Service Request with an I-SMF insertion) or in the old I-SMF (for a Service Request with an I-SMF change or removal) or in the old V-SMF (for a Service Request with a V-SMF change), and optionally the NF instance identifier of the SMF hosting the SM Context resource.

– the upCnxState attribute set to ACTIVATING (see clause 5.2.2.3.2.1) to indicate the establishment of N3 tunnel User Plane resources for the PDU Session;

– the smfUri IE attribute set to the API URI of the Nsmf_PDUSession service of the SMF (for a Service Request with an I-SMF insertion or change), and optionally the NF instance identifier of the SMF, if the "ACSCR" feature is not supported by the AMF and I-SMF;

– the hSmfUri IE attribute set to the API URI of the Nsmf_PDUSession service of the H-SMF (for a Service Request with an V-SMF change), and optionally the NF instance identifier of the H-SMF, if the "ACSCR" feature is not supported by the AMF and V-SMF.

2a. On success, the SMF shall return a 201 Created response as specified in clause 5.2.2.2.1 with the following additional information:

– the upCnxState attribute set to ACTIVATING;

– N2 SM information to request the 5G-AN to assign resources to the PDU session (see PDU Session Resource Setup Request Transfer IE in clause 9.3.4.1 of 3GPP TS 38.413 [9]), including 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).

2b. Same as step 2b of figure 5.2.2.2.1-1. Steps 3 to 4 of figure 5.2.2.3.2.2-1 are skipped in this case.

5.2.2.2.7 Registration procedure for a UE with a PDU session with I-SMF insertion, change and removal

The NF Service Consumer (e.g. AMF) shall request the SMF to create a SM context during UE Registration procedure for a PDU session with I-SMF insertion, change and removal, as follows.

1. Same as step 1 of 5.2.2.2.1-1, the NF Service Consumer shall send a POST request, with the following additional information:

– the smContextRef attribute set to the identifier of the SM Context resource in the SMF during I-SMF insertion or the SM Context resource in the I-SMF during I-SMF removal or the SM Context resource in the old I-SMF during I-SMF change, and optionally the NF instance identifier of the SMF hosting the SM Context resource;

– the upCnxState attribute set to ACTIVATING (see clause 5.2.2.3.2.1) to indicate the establishment of N3 tunnel User Plane resources for the PDU Session, if the UE requested to activate the PDU session;

– if the UE is in CM-CONNECTED state during the registration procedure (see clause 4.11.1.3.3 of 3GPP TS 23.502 [3]), ranUnchangedInd attribute shall be set to indicate that NG-RAN is not changed for the PDU Session (i.e. for this case, the NG-RAN tunnel info shall be included in SM context retrieved from old I-SMF or SMF);

2a. On success, the SMF shall return a 201 Created response.

If the SMF establishes N3 tunnel User Plane resources for the PDU Session, e.g. due to the NF Service Consumer requesting so or due to buffered DL data in the old I-SMF/I-UPF (see clause 4.23.3 of 3GPP TS 23.502 [3]), the 201 Created response shall contain the following additional information:

– the upCnxState attribute set to ACTIVATING;

– N2 SM information to request the 5G-AN to assign resources to the PDU session (see PDU Session Resource Setup Request Transfer IE in clause 9.3.4.1 of 3GPP TS 38.413 [9]), including 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).

If the SMF receives the ranUnchangedInd attribute set to indicate that NG-RAN is not changed for the PDU Session, the SMF shall respond with a 201 Created with the following additional information:

– N2 SM information to request the 5G-AN to update UPF tunnel info of the PDU session (see PDU Session Resource Modify Request Transfer IE in clause 9.3.4.3 of 3GPP TS 38.413 [9]), including 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 and NG-RAN’s GTP-U F-TEID for downlink traffic).

The "Location" header shall be present in the POST response and shall contain the URI of the created SM context resource.

The NF Service Consumer (e.g. AMF) shall store the association of the PDU Session ID and the SMF ID.

2b. Same as step 2b of figure 5.2.2.2.1-1.

5.2.2.2.8 SMF Context Transfer procedure, LBO or no Roaming, no I-SMF

The NF Service Consumer (e.g. AMF) shall request the SMF to create a SM context during an SMF Context Transfer procedure, LBO or no Roaming, no I-SMF, as follows.

1. Same as step 1 of 5.2.2.2.1-1, the NF Service Consumer shall send a POST request, with the following additional information:

– SMF transfer indication, Old SMF ID, the identifier of the SM Context resource in old SMF.

2a. On success, the SMF shall return a 201 Created response.

The "Location" header shall be present in the POST response and shall contain the URI of the created SM context resource.

The NF Service Consumer (e.g. AMF) shall store the association of the PDU Session ID and the SMF ID.

2b. Same as step 2b of figure 5.2.2.2.1-1.

5.2.2.2.9 I-SMF Context Transfer procedure

The NF Service Consumer (e.g. AMF) shall request the SMF to create a SM context during I-SMF Context Transfer procedure, as follows.

1. Same as step 1 of 5.2.2.2.1-1, the NF Service Consumer shall send a POST request, with the following additional information:

– SMF transfer indication, Old SMF ID, the identifier of the SM Context resource in old SMF.

2a. On success, the SMF shall return a 201 Created response.

The "Location" header shall be present in the POST response and shall contain the URI of the created SM context resource.

The NF Service Consumer (e.g. AMF) shall store the association of the PDU Session ID and the SMF ID.

2b. Same as step 2b of figure 5.2.2.2.1-1.

5.2.2.2.10 Handover between 3GPP and non-3GPP accesses with I-SMF insertion/removal or V-SMF change

The NF Service Consumer (e.g. AMF) shall request the I-SMF (for I-SMF insertion during a handover from non-3GPP to 3GPP access), the V-SMF (for V-SMF change during a handover from non-3GPP to 3GPP access) or the SMF (for I-SMF removal during a handover from 3GPP to non-3GPP access) to create a SM context as follows.

1. The NF Service Consumer shall send a POST request as specified in clause 5.2.2.2.1, with the following additional information:

– the smContextRef attribute set to the identifier of the SM Context resource in the SMF (during I-SMF insertion), the SM Context resource in the source I-SMF during I-SMF removal, or the SM Context resource in the source V-SMF during V-SMF change, and optionally the NF instance identifier of the SMF hosting the SM Context resource;

– the smfUri IE attribute set to the API URI of the Nsmf_PDUSession service of the SMF (during I-SMF insertion), and optionally the NF instance identifier of the SMF, if the "ACSCR" feature is not supported by the AMF and I-SMF;

– the hSmfUri IE attribute set to the API URI of the Nsmf_PDUSession service of the H-SMF (during V-SMF change), and optionally the NF instance identifier of the H-SMF, if the "ACSCR" feature is not supported by the AMF and V-SMF.

2a. Same as step 2a of figure 5.2.2.2.1-1.

2b. Same as step 2b of figure 5.2.2.2.1-1.

5.2.2.3 Update SM Context service operation

5.2.2.3.1 General

The Update SM Context service operation shall be used to update an individual SM context and/or provide N1 or N2 SM information received from the UE or the AN, for a given PDU session, towards the SMF, or the V-SMF for HR roaming scenarios, or the I-SMF for a PDU session with an I-SMF.

It is used in the following procedures:

– PDU Session modification (see clause 4.3.3 of 3GPP TS 23.502 [3]);

– UE or network requested PDU session release (see clause 4.3.4.2 and clause 4.3.4.3 of 3GPP TS 23.502 [3]);

– UE requested MA PDU session establishment over the other access (see clause 4.22.7 of 3GPP TS 23.502 [3]);

– UE or network-initiated MA PDU session release over a single access (see clause 4.22 of 3GPP TS 23.502 [3]);

– Activation or Deactivation of the User Plane connection of an existing PDU session, i.e. establishment or release of the N3 tunnel between the AN and serving CN (see clause 5.6.8 of 3GPP TS 23.501 [2], clauses 4.2.2.2, 4.2.3, 4.2.6, 4.2.10 and 4.9.1.3.3 of 3GPP TS 23.502 [3] and clauses 7.2.2.1, 7.2.2.2, 7.2.5.2 and 7.2.5.3 of 3GPP TS 23.316 [36]);

– Xn and N2 Handover procedures (see clauses 4.9.1, 4.23.7 and 4.23.11 of 3GPP TS 23.502 [3]);

– Handover between 3GPP and untrusted non-3GPP access procedures (see clause 4.9.2 of 3GPP TS 23.502 [3]);

– Inter-AMF change due to AMF planned maintenance or AMF failure (see clause 5.21.2 of 3GPP TS 23.501 [2]), or inter-AMF mobility in CM-IDLE mode (see clauses 4.2.2.2 and 4.23.3 of 3GPP TS 23.502 [3]);

– RAN Initiated QoS Flow Mobility (see clause 4.14.1 of 3GPP TS 23.502 [3] and clause 8.2.5 of 3GPP TS 38.413 [9]);

– All procedures requiring to provide N1 or N2 SM information to the SMF, e.g. UE requested PDU Session Establishment procedure (see clause 4.3.2.2 of 3GPP TS 23.502 [3]), session continuity procedure (see clause 4.3.5 of 3GPP TS 23.502 [3]);

– EPS to 5GS Idle mode mobility, EPS to 5GS Idle mode mobility with data forwarding or handover using N26 interface (see clause 4.11 of 3GPP TS 23.502 [3]);

– 5GS to EPS Handover using N26 interface (see clause 4.11.1.2 of 3GPP TS 23.502 [3]);

– 5GS to EPS Idle mode mobility using N26 interface with data forwarding (see clause 4.11.1.3.2A of 3GPP TS 23.502 [3]);

– PDU Session Reactivation during P-CSCF Restoration procedure via AMF (see clause 5.8.4.3 of 3GPP TS 23.380 [21]);

– AMF requested PDU session release due to a change of the set of network slices for a UE where a network slice instance is no longer available (see clause 4.3.4.2 of 3GPP TS 23.502 [3]);

– AMF receives an "initial request" with PDU Session Id which already exists in PDU session context of the UE (see clause 5.4.5.2.5 of 3GPP TS 24.501 [7]);

– Secondary RAT Usage Data Reporting (see clause 4.21 of 3GPP TS 23.502 [3]);

– Service Request Procedures with I-SMF change or I-SMF removal when downlink data packets are buffered at the I-UPF (See clause 4.23.4 of 3GPP TS 23.502 [3]);

– Connection Suspend procedure (see clause 4.8.1.2 of 3GPP TS 23.502 [3]);

– Connection Resume in CM-IDLE with Suspend procedure (see clause 4.8.2.3 of 3GPP TS 23.502 [3]);

– 5G-RG or Network requested PDU Session Modification via W-5GAN (see clause 7.3.2 of 3GPP TS 23.316 [36]);

– 5G-RG or Network requested PDU Session Release via W-5GAN (see clause 7.3.3 of 3GPP TS 23.316 [36]);

– FN-RG or Network requested PDU Session Modification via W-5GAN (see clause 7.3.6 of 3GPP TS 23.316 [36]);

– FN-RG or Network requested PDU Session Release via W-5GAN (see clause 7.3.7 of 3GPP TS 23.316 [36]);

– Handover between 3GPP access/5GC and W-5GAN access (see clause 7.6.3 of 3GPP TS 23.316 [36]);

– AMF requested PDU session release due to Network Slice-Specific (Re-)Authentication and (Re-)Authorization failure or revocation (see clauses 4.2.9.2, 4.2.9.3 and 4.2.9.4 of 3GPP TS 23.502 [3]);

– 5G-RG requested PDU Session Establishment via W-5GAN (see clause 7.3.1 of 3GPP TS 23.316 [36]);

– FN-RG related PDU Session Establishment via W-5GAN (see clause 7.3.4 of 3GPP TS 23.316 [36]);

– Non-5G capable device behind 5G-CRG and FN-CRG requested PDU Session Establishment via W-5GAN (see clause 4.10a of 3GPP TS 23.316 [36]);

– Non-5G capable device behind 5G-CRG and FN-CRG or Network requested PDU Session Modification via W-5GAN (see clause 4.10a of 3GPP TS 23.316 [36]);

– Non-5G capable device behind 5G-CRG and FN-CRG or Network requested PDU Session Release via W-5GAN (see clause 4.10a of 3GPP TS 23.316 [36]);

– CN-initiated selective deactivation of UP connection of an existing PDU Session associated with W-5GAN Access (see clause 7.3.5 of 3GPP TS 23.316 [36]);

– Handover between 3GPP access / EPS and W-5GAN/5GC access (see clause 7.6.4 of 3GPP TS 23.316 [36]);

– AMF requested PDU session release due to Control Plane Only indication associated with PDU Session is not applicable any longer as described in 3GPP TS 23.501 [2] clause 5.31.4.1;

– Subscribe to / unsubscribe from the DDN failure status notification (see clauses 4.15.3.2.7 and 4.15.3.2.9 of 3GPP TS 23.502 [3]).

The NF Service Consumer (e.g. AMF) shall update an individual SM context and/or provide N1 or N2 SM information to the SMF by using the HTTP POST method (modify custom operation) as shown in Figure 5.2.2.3.1-1.

Figure 5.2.2.3.1-1: SM context update

1. The NF Service Consumer shall send a POST request to the resource representing the individual SM context resource in the SMF. The payload body of the POST request shall contain the modification instructions and/or the N1 or N2 SM information, or the indication that the PDU session is allowed to be upgraded to a MA PDU session if so indicated by the UE as specified in clause 6.4.2.2 of 3GPP TS 24.501 [7], or subscribe/unsubscribe of the DDN failure notification as specified in clause 4.15.3.2.7 of 3GPP TS 23.502 [3]. If the request contains EBI(s) to revoke, then the SMF shall disassociate the EBI(s) with the QFI(s) with which they are associated.

2a. On success, "204 No Content" or "200 OK" shall be returned; in the latter case, the payload body of the POST response shall contain the representation describing the status of the request and/or N1 or N2 SM information.

If the ExemptionInd IE is included in the request message, indicating that the NAS SM message included in the request was exempted from NAS congestion control by the AMF, the SMF shall verify that the included 5G SM message can be exempted from a NAS SM congestion control activated in the AMF as specified in clause 5.19.7 of 3GPP TS 23.501 [2].

The SMF may indicate to the NF Service Consumer that it shall release EBI(s) that were assigned to the PDU session by including the releaseEbiList IE, e.g. when a QoS flow is released.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.3.2-3 shall be returned. For a 4xx/5xx response, the message body shall contain an SmContextUpdateError structure, including:

– a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.3.3.2-3;

– N1 SM information, if the SMF needs and can return a response to the UE;

– N2 SM information, if the SMF needs and can return a response to the NG-RAN.

The following clauses specify additional requirements applicable to specific scenarios.

5.2.2.3.2 Activation and Deactivation of the User Plane connection of a PDU session

5.2.2.3.2.1 General

The upCnxState attribute of an SM context represents the state of the User Plane connection of the PDU session. The upCnxState attribute may take the following values:

– ACTIVATED: a N3 tunnel is established between the 5G-AN and UPF (F-TEIDs assigned for both uplink and downlink traffic);

– DEACTIVATED: no N3 tunnel is established between the 5G-AN and UPF;

– ACTIVATING: a N3 tunnel is being established (5G-AN’s F-TEID for downlink traffic is not assigned yet).

Clauses 5.2.2.3.2.2 and 5.2.2.3.2.3 specify how the NF Service Consumer (e.g. AMF) request the SMF to activate or deactivate the User Plane connection of the PDU session, e.g. upon receiving a Service Request from the UE requesting to activate a PDU session or upon an AN release procedure respectively.

In scenarios where the SMF takes the initiative to activate or deactivate the User Plane connection of the PDU session, e.g. during a Network Triggered Service Request or CN-initiated selective deactivation of the User Plane connection of a PDU session respectively, the SMF invokes the Namf_N1N2MessageTransfer procedure with the inclusion of N2 SM Information (and optionally of a N1 SM Container) as specified in 3GPP TS 23.502 [3] to request the establishment or release of the PDU session’s resources in the 5G-AN. The Update SM Context service operation is then used as specified in clause 5.2.2.3.1 to transfer the response to the SMF.

Clause 5.2.2.3.2.4 specifies how the NF Service Consumer (e.g. AMF) indicates to the SMF that the access type of a PDU session can be changed from non-3GPP access to 3GPP access, during a Network Triggered Service Request initiated for a PDU session associated to the non-3GPP access, if the PDU Session for which the UE was paged or notified is in the List Of Allowed PDU Sessions provided by the UE and if the AMF has received N2 SM Information only or N1 SM Container and N2 SM Information for that PDU session from the SMF in step 3a of clause 4.2.3.3 of 3GPP TS 23.502 [3].

5.2.2.3.2.2 Activation of User Plane connectivity of a PDU session

The NF Service Consumer (e.g. AMF) shall request the SMF to activate the User Plane connection of an existing PDU session, i.e. establish the N3 tunnel between the 5G-AN and UPF, as follows.

Figure 5.2.2.3.2.2-1: Activation of the User Plane connection of a PDU session

1. The NF Service Consumer shall request the SMF to activate the user plane connection of the PDU session by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:

– the upCnxState attribute set to ACTIVATING;

– the user location and access type associated to the PDU session, if modified;

– 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;

– the access type for which the user plane connection needs to be re-activated, for a MA PDU session (i.e. the access type over which a Registration or Service Request was received);

– the "MO Exception Data Counter" if the UE has accessed the network by using "MO exception data" RRC establishment cause;

– other information, if necessary.

2a. Upon receipt of such a request, if the SMF can proceed with activating the user plane connection of the PDU session (see clause 4.2.3 of 3GPP TS 23.501 [2]), the SMF shall set the upCnxState attribute to ACTIVATING and shall return a 200 OK response including the following information:

– upCnxState attribute set to ACTIVATING;

– N2 SM information to request the 5G-AN to assign resources to the PDU session (see PDU Session Resource Setup Request Transfer IE in clause 9.3.4.1 of 3GPP TS 38.413 [9]), including 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).

If the SMF finds the PDU session already activated when receiving the request in step 1, the SMF shall delete the N3 tunnel information and update the UPF accordingly (see step 8a of clause 4.2.3.2 of 3GPP TS 23.502 [3]).

For a MA-PDU session, the SMF shall perform the above requirements for the access type for which the user plane connection is requested to be re-activated (i.e. the access type indicated in the anTypeToReactivate attribute). The SMF shall not modify the user plane connection status for the other access type, e.g. if the user plane connection is already established for the other access type, it shall remain established.

If the "MO Exception Data Counter" is included in the request and Small Data Rate Control is enabled for the PDU session, then the V-SMF/I-SMF shall forward the counter to the H-SMF/SMF.

If the SMF cannot proceed with activating the user plane connection of the PDU session (e.g. if the PDU session corresponds to a PDU session of SSC mode 2 and the SMF decides to change the PDU Session Anchor), 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:

– upCnxState attribute set to DEACTIVATED.

3. If the SMF returned a 200 OK response, 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:

– N2 SM information received from the 5G-AN (see PDU Session Resource Setup Response Transfer IE in clause 9.3.4.2 of 3GPP TS 38.413 [9]), including the transport layer address and tunnel endpoint of one or two downlink termination point(s) and the associated list of QoS flows for this PDU session (i.e. 5G-AN’s GTP-U F-TEID(s) for downlink traffic), if the 5G-AN succeeded in establishing resources for the PDU sessions; or

– N2 SM information received from the 5G-AN (see PDU Session Resource Setup Unsuccessful Transfer IE in clause 9.3.4.16 of 3GPP TS 38.413 [9]), including the Cause of the failure, if resources failed to be established for the PDU session.

Upon receipt of this request, the SMF shall:

– update the UPF with the 5G-AN’s F-TEID(s) and set the upCnxState attribute to ACTIVATED, if the 5G-AN succeeded in establishing resources for the PDU sessions; or

– consider that the activation of the User Plane connection has failed and set the upCnxState attribute to DEACTIVATED" otherwise.

4. The SMF shall then return a 200 OK response including the upCnxState attribute representing the final state of the user plane connection. If the activation of the User Plane connection failed due to insufficient resources, the cause IE shall be included in the response and set to "INSUFFICIENT_UP_RESOURCES".

5.2.2.3.2.3 Deactivation of User Plane connectivity of a PDU session

The NF Service Consumer (e.g. AMF) shall request the SMF to deactivate the User Plane connectivity of an existing PDU session, i.e. release the N3 tunnel, as follows.

Figure 5.2.2.3.2.2-1: Deactivation of the User Plane connection of a PDU session

1. The NF Service Consumer shall request the SMF to deactivate the user plane connection of the PDU session by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:

– upCnxState attribute set to DEACTIVATED;

– user location and user location timestamp;

– cause of the user plane deactivation; the cause may indicate a cause received from the 5G-AN or due to an AMF internal event;

– other information, if necessary.

2. Upon receipt of such a request, the SMF shall deactivate release the N3 tunnel of the PDU session, set the upCnxState attribute to DEACTIVATED and return a 200 OK response including the upCnxState attribute set to DEACTIVATED.

5.2.2.3.2.4 Changing the access type of a PDU session from non-3GPP access to 3GPP access during a Service Request procedure

The NF Service Consumer (e.g. AMF) shall indicate to the SMF that the access type of a PDU session can be changed as follows:

Figure 5.2.2.3.2.4-1: Indicating that the access type of a PDU session can be changed

1. The NF Service Consumer shall indicate that the access type of a PDU session can be changed by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:

– anTypeCanBeChanged attribute set to "true";

– other information, if necessary.

2a. Same as step 2a of figure 5.2.2.3.1-1. In HR roaming scenarios, the V-SMF shall invoke the Update service operation towards the H-SMF to notify that the access type of the PDU session can be changed (see clause 5.2.2.8.2.2).

2b. Same as step 2b of figure 5.2.2.3.1-1.

NOTE: This is used during a Service Request procedure (see clause 4.2.3.2 of 3GPP TS 23.502 [3]), in response to paging or NAS notification indicating non-3GPP access, if the PDU Session for which the UE was paged or notified is in the List Of Allowed PDU Sessions provided by the UE and if the AMF has received N2 SM Information only or N1 SM Container and N2 SM Information for that PDU session from the SMF in step 3a of clause 4.2.3.3 of 3GPP TS 23.502 [3].

If the PDU Session is moved from the non-3GPP access to 3GPP access (i.e. N3 tunnel for the PDU Session is established successfully), the SMF and NF Service Consumer (e.g. AMF) updates the associated access of the PDU Session.

5.2.2.3.3 Xn Handover

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.

Figure 5.2.2.3.3-1: Xn handover

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 3GPP TS 38.413 [9]), 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 3GPP TS 38.413 [9]), 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.

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 3GPP TS 38.413 [9]), 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 3GPP TS 23.501 [2].

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:

– N2 SM information (see Path Switch Request Unsuccessul Transfer IE in clause 9.3.4.20 of 3GPP TS 38.413 [9]), including the cause of the failure.

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.

Figure 5.2.2.3.3-2: Xn handover – PDU session rejected by the target RAN

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 3GPP TS 38.413 [9]), 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 3GPP TS 38.413 [9]), if any;

– other information, if necessary.

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 3GPP TS 23.502 [3].

2b. Same as step 2b of figure 5.2.2.3.1-1.

5.2.2.3.4 N2 Handover

5.2.2.3.4.1 General

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.

5.2.2.3.4.2 N2 Handover Preparation

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.

Figure 5.2.2.3.4.2-1: N2 Handover Preparation

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 3GPP TS 38.413 [9]), indicating whether a direct path is available;

– the supportedFeatures IE indicating the optional features it supports, if at least one optional feature defined in clause 6.1.8 is supported;

– other information, if necessary.

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 3GPP TS 23.501 [2]), 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 3GPP TS 38.413 [9]), 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 optional 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.

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 shall return an error response, as specified in step 2b of figure 5.2.2.3.1-1.

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.

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 3GPP TS 38.413 [9]), 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 3GPP TS 38.413 [9]), including the Cause of the failure, if resources failed to be established for the PDU sessions.

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:

– hoState attribute to PREPARED;

– N2 SM information (see Handover Command Transfer IE in clause 9.3.4.10 of 3GPP TS 38.413 [9]) containing DL forwarding tunnel information to be sent to the source 5G-AN by the AMF if direct or indirect data forwarding applies (see step 11f of clause 4.9.1.3.2 of 3GPP TS 23.502 [3]).

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 3GPP TS 38.413 [9]) 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.

5.2.2.3.4.3 N2 Handover Execution

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.

Figure 5.2.2.3.4.3-1: N2 Handover Execution

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 3GPP TS 38.413 [9]), if any;

– other information, if necessary.

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

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 3GPP TS 23.502 [3]), 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 release the resources prepared for the handover and consider that the PDU session is deactivated and that the handover attempt is terminated for the PDU session.

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.

5.2.2.3.4.4 N2 Handover Cancellation

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.

Figure 5.2.2.3.4.3-1: N2 Handover Cancellation

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.

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

5.2.2.3.5 Handover between 3GPP and untrusted non-3GPP access procedures

5.2.2.3.5.1 General

The handover of a PDU session between 3GPP and untrusted non-3GPP access shall be supported as specified in clause 4.9.2 of 3GPP TS 23.502 [3]. Such a handover may involve:

– the same AMF, or a target AMF in the same PLMN as the source AMF (see clauses 4.9.2.1, 4.9.2.2, 4.9.2.3.1 and 4.9.2.4.1 of 3GPP TS 23.502 [3]). The Update SM Context service operation is used in these cases; or

– a target AMF in a different PLMN than the source AMF (see clauses 4.9.2.3.2 and 4.9.2.4.2 of 3GPP TS 23.502 [3]). The Create SM Context service operation is used in this case (see clause 5.2.2.2).

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.

5.2.2.3.5.2 Handover of a PDU session without AMF change or with target AMF in same PLMN

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.

Figure 5.2.2.3.5.2-1: Handover between 3GPP and untrusted non-3GPP access

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.

2a. Same as step 2a of Figure 5.2.2.3.1-1.

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.

5.2.2.3.6 Inter-AMF change or mobility

The NF Service Consumer (e.g. new AMF) shall inform the SMF that it has taken over the role of serving the UE (e.g. it has taken the responsibility of the signalling towards the UE), when so required by 3GPP TS 23.501 [2] and 3GPP TS 23.502 [3], as follows.

Figure 5.2.2.3.6-1: Inter-AMF change or mobility

1. The NF Service Consumer shall update the SMF with the new serving AMF, by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:

– servingNfId set to the new serving AMF Id;

– the supportedFeatures IE indicating the optional features it supports, if at least one optional feature defined in clause 6.1.8 is supported;

– other information, if necessary, e.g. to activate the user plane connection of the PDU session (see clause 5.2.2.3.2.2).

2a. Same as step 2a of Figure 5.2.2.3.1-1. In addition, the SMF shall include the supportedFeatures IE in the response, if the supportedFeatures IE was received in the request and at least one optional feature defined in clause 6.1.8 is supported by the updated SM context resource.

2b. Same as step 2b of figure 5.2.2.3.1-1.

5.2.2.3.7 RAN Initiated QoS Flow Mobility

The NF Service Consumer (e.g. AMF) shall request the SMF to transfer QoS flows to and from Secondary RAN node, or more generally, handle a NG-RAN PDU Session Resource Modify Indication, as follows.

Figure 5.2.2.3.7-1: RAN Initiated QoS Flow Mobility

1. The NF Service Consumer shall request the SMF to modify the PDU session, as requested by the NG-RAN, by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:

– N2 SM information received from the 5G-AN (see PDU Session Resource Modify Indication Transfer IE in clause 9.3.4.6 of 3GPP TS 38.413 [9]), including the transport layer information for the QoS flows of this PDU session (i.e. 5G-AN’s GTP-U F-TEIDs for downlink traffic);

– other information, if necessary.

2a. Upon receipt of such a request, if the SMF can proceed with switching the QoS flows of the PDU session, the SMF shall return a 200 OK response including the following information:

– N2 SM information (see PDU Session Resource Modify Confirm Transfer IE in clause 9.3.4.7 of 3GPP TS 38.413 [9]), including the list of QoS flows which were modified successfully and the list of QoS flows which failed to be modified if available.

2b. If the SMF cannot proceed with switching the QoS flows 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:

– N2 SM information (see PDU Session Resource Modify Indication Unsuccessful Transfer IE in clause 9.3.4.22 of 3GPP TS 38.413 [9]).

5.2.2.3.8 EPS to 5GS Handover using N26 interface

5.2.2.3.8.1 General

The NF Service Consumer (e.g. AMF) shall request the SMF to handover a UE EPS PDN connection to 5GS using N26 interface, following the same requirements as specified for N2 handover in clause 5.2.2.3.4 with the modifications specified in this clause.

5.2.2.3.8.2 EPS to 5GS Handover Preparation

The requirements specified in clause 5.2.2.3.4.2 shall apply with the following modifications.

Figure 5.2.2.3.8.2-1: EPS to 5GS Handover Preparation

1. Same as step 1 of Figure 5.2.2.2.3-1.

2a. Same as step 2 of Figure 5.2.2.2.3-1.

2b. Same as step 2b of figure 5.2.2.3.1-1.

3. Same as step 3 of Figure 5.2.2.3.4.2-1.

4a. Same as step 4 of Figure 5.2.2.3.4.2-1, with the following modifications:

The 200 OK response shall not include N2 SM information for DL forwarding tunnel setup, but shall additionally contain:

– the epsBearerSetup IE(s), containing the list of EPS bearer context(s) successfully handed over to the 5GS and DL data forwarding information, containing either:

– CN tunnel information generated based on the list of accepted QFI(s) received from the 5G-RAN, if indirect data forwarding applies; or

– NG-RAN F-TEID per E-RAB accepted for direct data forwarding, as received from the target NG-RAN, if direct data forwarding applies.

4b. Same as step 2b of figure 5.2.2.3.4.2-1.

5.2.2.3.8.3 EPS to 5GS Handover Execution

The requirements specified in clause 5.2.2.3.4.3 shall apply, with the following modifications.

In step 2 of Figure 5.2.2.3.4.3-1, for a Home Routed PDU session, the SMF shall complete the execution of the handover by initiating an Update service operation towards the H-SMF in order to switch the PDU session towards the V-UPF (see clause 5.2.2.8.2.3).

5.2.2.3.8.4 EPS to 5GS Handover Cancellation

The requirements specified in clause 5.2.2.3.4.4 shall apply, with the following modifications.

In step 2 of Figure 5.2.2.3.4.4-1, for a Home Routed PDU session, the V-SMF shall cancel the handover by initiating an Update service operation towards the H-SMF in order to release resources at H-SMF and H-UPF reserved for handover (see clause 5.2.2.8.2.14).

5.2.2.3.8.5 EPS to 5GS Handover Failure

If the handover to 5GS failed, e.g. rejected by the target NG-RAN, the requirements specified in clause 5.2.2.3.4.4 shall apply, with the following modifications:

– the hoState attribute set to "CANCELLED", to indicate the handover is cancelled;

– the cause attribute set to "HO_FAILURE".

5.2.2.3.9 5GS to EPS Handover using N26 interface

5.2.2.3.9.1 General

The NF Service Consumer (e.g. AMF) shall request the SMF to setup data forwarding tunnels if data forwarding applies to the 5GS to EPS handover using N26 interface, and to remove the indirect data forwarding tunnels previously established when the handover is cancelled or failed.

5.2.2.3.9.2 Data forwarding tunnels setup during 5GS to EPS handover

If data forwarding applies to the 5GS to EPS handover, the NF Service Consumer (e.g. AMF) shall provide the SMF with the data forwarding information received from the MME, as specified in clause 4.11.1.2.1 of 3GPP TS 23.502 [3]), as follows.

Figure 5.2.2.3.9-1: 5GS to EPS Handover using N26 interface (data forwarding tunnels setup)

1. The NF Service Consumer shall send a POST request, as specified in clause 5.2.2.3.1, with the following information:

– dataForwarding IE set to true;

– EPS bearer contexts received from the MME in the Forward Relocation Response, including F-TEID(s) for DL data forwarding tunnel(s) towards the target eNB (for direct data forwarding) or towards the forwarding SGW (for indirect data forwarding).

2a. If indirect data forwarding applies, the SMF shall map the EPS bearers for Data Forwarding to the 5G QoS flows based on the association between the EPS bearer ID(s) and QFI(s) for the QoS flow(s).

The SMF shall return a 200 OK response including the following information:

If direct data forwarding applies, the DL forwarding tunnel information shall contain the E-UTRAN tunnel info for data forwarding per EPS bearer received from the MME.

If indirect data forwarding applies, the DL forwarding tunnel information shall contain the CN transport layer address and tunnel endpoint (i.e. UPF’s GTP-U F-TEID) for Data Forwarding and the QoS flows for Data Forwarding for this PDU session.

2b. If the SMF cannot proceed with the request, the SMF shall return an error response, as specified for step 2b of figure 5.2.2.3.1-1.

5.2.2.3.9.3 Indirect data forwarding tunnels removal for 5GS to EPS handover cancellation or failure

During 5GS to EPS handover, if indirect data forwarding tunnel(s) have been previously established during the preparation phase and the handover is cancelled, the AMF shall update the SMF of handover cancellation by sending a POST request with the cause attribute set to "HO_CANCEL" and dataForwarding IE set to false with an empty list of EPS bearer contexts. The SMF shall then release the resources prepared for the handover and proceed with the PDU session as if no handover procedure had taken place.

If no resources for EPS bearer(s) can be assigned for any PDU session attempted to be handed over, the AMF shall update the SMF with the information that the handover preparation failed by sending a POST request with the cause attribute set to "HO_FAILURE" and with an empty list of EPS bearer contexts (and without the dataForwarding IE). The SMF shall then release the resources prepared for the handover and proceed with the PDU session as if no handover procedure had taken place.

5.2.2.3.10 P-CSCF Restoration Procedure via AMF

The requirements specified in clause 5.2.2.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.3.1-1, with the following modifications.

The POST request shall contain:

– the release IE set to true;

– the cause IE set to REL_DUE_TO_REACTIVATION.

5.2.2.3.11 AMF requested PDU Session Release due to duplicated PDU Session Id

When the AMF receives an "initial request" with PDU Session Id which already exists in PDU session context of the UE (see clause 5.4.5.2.5 of 3GPP TS 24.501 [7]), the AMF shall request the SMF to release the existing PDU Session; upon subsequent receipt of an SM context status notification indicating that the SM context has been deleted in the SMF, the AMF shall release the stored context for the PDU session and proceed with the "initial request" with the PDU Session Id.

The requirements for releasing the existing PDU Session specified in clause 5.2.2.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.3.1-1, with the following modifications.

The POST request shall contain:

– the release IE set to true;

– the cause IE set to REL_DUE_TO_DUPLICATE_SESSION_ID.

NOTE: The SMF does not send NAS signaling to UE for the PDU session release in this procedure.

5.2.2.3.12 AMF requested PDU Session Release due to slice not available

The requirements specified in clause 5.2.2.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.3.1-1, with the following modifications.

The POST request shall contain:

– the release IE set to true;

– the cause IE set to REL_DUE_TO_SLICE_NOT_AVAILABLE;

– optionally the skipN2PduSessionResRelInd IE with the value "true" to skip RAN resources release for the PDU session, e.g. for a PDU session with active UP associated with a slice that is no longer available after a handover.

5.2.2.3.13 Indirect Data Forwarding Tunnel establishment during N2 based Handover with I-SMF

During N2 based handover with I-SMF insertion/change/removal, the NF Service Consumer (e.g. target I-SMF) shall use this procedure to exchange N3/N9 forwarding tunnel information with the NF Service Producer (e.g. source I-SMF).

The NF Service Consumer (e.g. target I-SMF) shall request the SMF to establish one or more downlink and/or uplink indirect data forwarding tunnels, as follows.

Figure 5.2.2.3.13-1: Indirect Data Forwarding Tunnel establishment during N2 based Handover with I-SMF

1. The NF Service Consumer shall send a POST request, as specified in clause 5.2.2.3.1, with the following information:

– dataForwarding attribute set to true, for the N2 based handover with I-SMF insertion/change/removal;

– n9DlForwardingTnlList attribute carrying the N9 downlink indirect data forwarding tunnel(s) info of target I-UPF;

– n9UlForwardingTnlList attribute carrying the N9 uplink indirect data forwarding tunnel(s) info of target I-UPF;

– other information, if necessary.

2a. Same as step 2a of Figure 5.2.2.3.1-1, with the following information:

– n3DlForwardingTnlList attribute carrying the N3 downlink indirect data forwarding tunnel(s) info of source I-UPF or source UPF;

– n3UlForwardingTnlList attribute carrying the N3 uplink indirect data forwarding tunnel(s) info of source I-UPF or source UPF;

– other information, if necessary.

2b. If the source SMF cannot proceed with the request, the source I-SMF shall return an error response, as specified for step 2b of figure 5.2.2.3.1-1.

5.2.2.3.13A Indirect Data Forwarding Tunnel removal during N2 based Handover with I-SMF

During N2 based handover cancellation with I-SMF insertion/change/removal, the NF Service Consumer (e.g. target I-SMF) shall use this procedure to remove previously established Indirect Data Forwarding Tunnel(s) at NF Service Producer (e.g. source I-SMF).

The NF Service Consumer (e.g. target I-SMF) shall request the NF service producer to remove the established Indirect Data Forwarding Tunnel(s), as follows.

Figure 5.2.2.3.13A-1: Indirect Data Forwarding Tunnel Removal during N2 based Handover with I-SMF

1. The NF Service Consumer shall send a POST request, as specified in clause 5.2.2.3.1, with the following information:

– dataForwarding attribute set to false;

– other information, if necessary.

2a. If successful, the SMF shall return a 204 No Content response.

2b. If the SMF cannot proceed with the request, the SMF shall return an error response, as specified for step 2b of figure 5.2.2.3.1-1.

5.2.2.3.14 Request to forward buffered downlink data packets at I-UPF

For I-SMF change or I-SMF removal when downlink data packets are buffered at the I-UPF, the new I-SMF (for I-SMF change) or SMF (for I-SMF removal) shall request the (old) I-SMF to forward buffered downlink data packets as following:

Figure 5.2.2.3.14-1: Request to forward buffered downlink data packets at I-UPF

1. The NF Service Consumer shall send a POST request, as specified in clause 5.2.2.3.1, with the following information:

– n9ForwardingTunnel IE indicating the allocated tunnel endpoints information to receive the buffered downlink data packets.

2a. On success, the SMF shall initiate N4 session modification to the I-UPF trigger the sending of buffered DL data towards received tunnel endpoints and shall return "204 No Content" response.

2b. If the SMF cannot proceed with the request, the SMF shall return an error response, as specified for step 2b of figure 5.2.2.3.1-1.

5.2.2.3.15 Connection Suspend procedure

The NF Service Consumer (e.g. AMF) shall request the SMF to suspend the User Plane connection of an existing PDU session, as follows.

Figure 5.2.2.3.15-1: Connection Suspend

1. The NF Service Consumer shall request the SMF to suspend the user plane connection of the PDU session by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:

– upCnxState attribute set to SUSPENDED;

– user location and user location timestamp;

– N2 SM information received from the 5G-AN, including UE Context Suspend Request Transfer IE, if available;

– other information, if necessary.

2. Upon receipt of such a request, the SMF shall deactivate the N3 tunnel of the PDU session, set the upCnxState attribute to SUSPENDED and return a 200 OK response including the upCnxState attribute set to SUSPENDED.

5.2.2.3.16 Connection Resume in CM-IDLE with Suspend procedure

The NF Service Consumer (e.g. AMF) shall request the SMF to resume the User Plane connection of an existing PDU session, i.e. establish the N3 tunnel between the 5G-AN and UPF, as follows.

Figure 5.2.2.3.16-1: Connection Resume in CM-IDLE with Suspend

1. The NF Service Consumer shall request the SMF to resume the user plane connection of the PDU session by sending a POST request, as specified in clause 5.2.2.3.1, with the following information:

– the upCnxState attribute set to ACTIVATING;

– user location and user location timestamp;

– cause attribute set to "PDU_SESSION_RESUMED";

– N2 SM information received from the 5G-AN, i.e. Path Switch Request Transfer 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), or UE Context Resume Request Transfer;

– additional N2 SM information received from the 5G-AN, if any;

– the "MO Exception Data Counter" if the UE has accessed the network by using "MO exception data" RRC establishment cause;

– other information, if necessary.

2a. If the SMF can proceed with resuming the user plane connection of the PDU session, the SMF shall return a 200 OK response including the following information:

– the upCnxState attribute set to ACTIVATED;

– N2 SM information, i.e. Path Switch Response Transfer 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), or UE Context Resume Response Transfer.

If the "MO Exception Data Counter is included in the request and Small Data Rate Control is enabled for the PDU session, the V-SMF shall update the H-SMF (see clause 5.2.2.8.2.2) for HR PDU Session (or I-SMF shall update the SMF for PDU session with I-SMF).

2b. If the SMF cannot proceed with resuming 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:

– the upCnxState attribute representing the final state of the user plane connection (e.g. SUSPENDED);

– N2 SM information, including the cause of the failure.

5.2.2.3.17 AMF requested PDU Session Release due to Network Slice-Specific Authentication and Authorization failure or revocation

The requirements specified in clause 5.2.2.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.3.1-1, with the following modifications.

The POST request shall contain:

– the release IE set to true;

– the cause IE set to REL_DUE_TO_SLICE_NOT_AUTHORIZED.

5.2.2.3.18 5GS to EPS Idle mode mobility using N26 interface with data forwarding

The NF Service Consumer (e.g. AMF) shall request the SMF to forward buffered DL data towards the EPS during a 5GS to EPS Idle mode mobility using N26 interface with data forwarding (see 4.11.1.3.2A of 3GPP TS 23.502 [3]), as follows.

Figure 5.2.2.3.18-1: 5GS to EPS Idle mode mobility using N26 interface with data forwarding

1. The NF Service Consumer shall send a POST request, as specified in clause 5.2.2.3.1, with the following information:

– forwardingFTeid received from the MME in the Context Acknowdge, if any; or

– forwarding bearer contexts received from the MME in Context Acknowdge, if any.

2a. Upon receipt of such a request, the SMF shall forward the buffered DL data on the forwarding tunnel(s).

2b. If the SMF cannot proceed with the request, the SMF shall return an error response, as specified for step 2b of figure 5.2.2.3.1-1.

5.2.2.3.19 AMF requested PDU Session Release due to Control Plane Only indication associated with PDU Session is not applicable any longer

The requirements specified in clause 5.2.2.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.3.1-1, with the following modifications.

The POST request shall contain:

– the release IE set to true;

– the cause IE set to REL_DUE_TO_CP_ONLY_NOT_APPLICABLE.

5.2.2.3.20 Void

5.2.2.3.21 Void

5.2.2.3.22 Void

5.2.2.3.23 AMF requested PDU Session Release due to V/I-SMF failure

The AMF may request PDU Session Release towards an alternative V/I-SMF in the same SMF Set when it detects the V/I-SMF has failed and if the V/I-SMF supports the DLSET feature while the (H-)SMF doesn’t support the PSETR feature as specified in clause 6.8.2 of 3GPP TS 23.527 [24]. When the AMF sends an Update SM Context Request, the requirements specified in clause 5.2.2.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.3.1-1, with the following modifications.

The POST request shall contain:

– the release IE set to true;

– the cause IE set to REL_DUE_TO_SMF_NOT_SUPPORT_PSETR.

5.2.2.4 Release SM Context service operation

5.2.2.4.1 General

The Release SM Context service operation shall be used to release the SM Context of a given PDU session, in the SMF, in the V-SMF for HR roaming scenarios, or in the I-SMF for a PDU session with an I-SMF, in the following procedures:

– Registration procedure with I-SMF/V-SMF change and removal (see clause 4.23.3 of 3GPP TS 23.502 [3]);

– UE Triggered Service Request with I-SMF change and removal or V-SMF change (see clause 4.23.4.3 of 3GPP TS 23.502 [3]);

– UE initiated Deregistration (see clause 4.2.2.3.2 of 3GPP TS 23.502 [3]);

– Network initiated Deregistration, e.g. AMF initiated deregistration (see clause 4.2.2.3.3 of 3GPP TS 23.502 [3]), UDM triggered deregistration by sending Deregistration notification with initial Registration indication (see clause 4.2.2.2.2 of 3GPP TS 23.502 [3]);

– Network requested PDU session release (see clause 4.3.4.2 of 3GPP TS 23.502 [3]), e.g. AMF initiated release when:

– there is a mismatch of the PDU session status between the UE and the; or

– there is a change of the set of network slices for a UE where a network slice instance is no longer available (as described in 3GPP TS 23.501 [2], clauses 5.15.5.2.2 and 4.2.2.2) and the PDU session is not activated;

– 5GS to EPS Idle mode mobility or handover, to release the SM context in the V-SMF only for a Home Routed PDU session or in the I-SMF only for a PDU session with an I-SMF (see clauses 4.23.12.2 and 4.23.12.6 of 3GPP TS 23.502 [3]), for the PDU sessions that are transferred to EPC;

– 5GS to EPS handover using N26 interface and 5GS to EPS Idle mode mobility using N26, to release the PDU session not transferred to EPC (see clauses 4.11.1.2.1 and 4.11.1.3.2 of 3GPP TS 23.502 [3]);

– Inter NG-RAN node Xn based handover and N2 based handover with I-SMF change and removal;

– 5G-SRVCC from NG-RAN to 3GPP UTRAN procedure (see clause 6.5.4 of 3GPP TS 23.216 [35]);

– 5G-RG Deregistration via W-5GAN (see clause 7.2.1.2 of 3GPP TS 23.316 [36]);

– FN-RG Deregistration via W-5GAN (see clause 7.2.1.4 of 3GPP TS 23.316 [36]);

– Non-5G capable device behind 5G-CRG and FN-CRG Deregistration via W-5GAN (see clause 4.10a of 3GPP TS 23.316 [36]);

– 5G-RG or Network requested PDU Session Release via W-5GAN (see clause 7.3.3 of 3GPP TS 23.316 [36]);

– FN-RG or Network Requested PDU Session Release via W-5GAN (see clause 7.3.7 of 3GPP TS 23.316 [36]);

– Non-5G capable device behind 5G-CRG and FN-CRG or Network Requested PDU Session Release via W-5GAN (see clause 4.10a of 3GPP TS 23.316 [36]);

– Mobility procedures with AMF changes (e.g. Registration / N2 based handover with AMF changes), to release the MA-PDU session if target AMF does not support MA-PDU session (see clause 4.22.9 of 3GPP TS 23.502 [3]).

The SMF shall release the SM context without sending any signalling towards the 5G-AN and the UE.

The NF Service Consumer (e.g. AMF) shall release the SM Context of a given PDU session by using the HTTP "release" custom operation as shown in Figure 5.2.2.4.1-1.

Figure 5.2.2.4.1-1: SM context release

1. The NF Service Consumer shall send a POST request to the resource representing the individual SM context to be deleted. The payload body of the POST request shall contain any data that needs to be passed to the SMF and/or N2 SM information (if Secondary RAT usage data needs to be reported).

For a 5GS to EPS Idle mode mobility or handover, for a Home Routed PDU session associated with 3GPP access and with assigned EBI(s), the POST request shall contain the vsmfReleaseOnly indication; for a PDU session with an I-SMF and assigned EBI(s), the POST request shall contain the ismfReleaseOnly indication.

For a 5GS to EPS Idle mode mobility or handover, for a Home Routed PDU session associated with 3GPP access and with no assigned EBI(s), the POST request shall not contain the vsmfReleaseOnly indication to release the PDU session in the V-SMF and H-SMF; for a PDU session with an I-SMF and with no assigned EBI(s), the POST request shall not contain the ismfReleaseOnly indication to release the PDU session in the I-SMF and SMF.

For Registration, UE Triggered Service Request, Inter NG-RAN node Xn based handover and N2 based handover procedures with I-SMF change or removal, the POST request shall contain the ismfReleaseOnly indication; if with V-SMF change or removal, the POST request shall contain the vsmfReleaseOnly indication.

For 5G-SRVCC from NG-RAN to 3GPP UTRAN, the POST request body shall contain the "cause" attribute with the value "REL_DUE_TO_PS_TO_CS_HO".

2a. On success, the SMF shall return a "200 OK" with message body containing the representation of the SmContextReleasedData when information needs to be returned to the NF Service Consumer, or a "204 No Content" response with an empty payload body in the POST response.

If the POST request contains a vsmfReleaseOnly indication (i.e. for a 5GS to EPS Idle mode mobility or handover, for a Home Routed PDU session with assigned EBI(s)), the V-SMF shall release its SM context and corresponding PDU session resource locally, i.e. without signalling towards the H-SMF.

If the POST request contains an ismfReleaseOnly indication (i.e. for a 5GS to EPS Idle mode mobility or handover, for a PDU session with an I-SMF and assigned EBI(s)), the I-SMF shall release its SM context and corresponding PDU session resource locally, i.e. without signalling towards the SMF.

If the POST request body contains the "cause" attribute with the value "REL_DUE_TO_PS_TO_CS_HO", the SMF shall indicate to the PCF within SM Policy Association termination that the PDU session is released due to 5G-SRVCC, or the cause value shall be passed from the V-SMF to the H-SMF (for a HR PDU session) or from the I-SMF to the SMF (for a PDU session with an I-SMF) within the Release service operation.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.4.3.2-2 shall be returned. For a 4xx/5xx response, the message body shall include a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.3.4.3.2-2.

5.2.2.5 Notify SM Context Status service operation

5.2.2.5.1 General

The Notify SM Context Status service operation shall be used by the SMF to notify the NF Service Consumer about the status of an SM context related to a PDU session (e.g. when the SM context is released and the release is not triggered by a Release SM Context Request, when the SM context is moved to another system, or when the control of the PDU session is taken over by another I-SMF/V-SMF/SMF in the same SMF set) in the SMF, or in the V-SMF for HR roaming scenarios, or in the I-SMF for a PDU session with an I-SMF.

The Notify SM Context Status service operation may also be used by the SMF to provide the SMF derived CN assisted RAN parameters tuning to the NF Service Consumer (e.g. AMF), if the NF Service Consumer has indicated support of the CARPT (CN Assisted RAN Parameters Tuning) feature.

The Notify SM Context Status service operation may also be used by the SMF to notify the DDN failure status.

The Notify SM Context Status service operation may also be used to inform the NF service consumer (e.g. AMF) that the V-SMF has created the PDU session towards an alternative H-SMF for a HR PDU session or the I-SMF has created the PDU session towards an alternative SMF for a PDU session with I-SMF, during the PDU session establishment procedure.

It is used in the following procedures:

– UE requested PDU Session Establishment procedure, when the PDU session establishment fails after the Create SM Context response or to provide the SMF derived CN assisted RAN parameters tuning, or when an alternative H-SMF is used by the V-SMF for a HR PDU session (see clause 4.3.2.2 of 3GPP TS 23.502 [3]), or when an alternative SMF is used by the I-SMF for a PDU session with an I-SMF (see clause 4.23.5.1 of 3GPP TS 23.502 [3]);

– UE or Network requested PDU session Modification (see clause 4.3.3.2 of 3GPP TS 23.502 [3]) to provide the SMF derived CN assisted RAN parameters tuning;

– UE or Network requested PDU session release (see clause 4.3.4.2 of 3GPP TS 23.502 [3]), e.g. SMF initiated release;

– Handover of a PDU Session procedure between untrusted non-3GPP to 3GPP access (see clauses 4.9.2.3.2, 4.9.2.4.2 and 4.23.16.2 of 3GPP TS 23.502 [3]);

– Interworking procedures without N26 interface, e.g. 5GS to EPS Mobility (see clause 4.11.2.2 of 3GPP TS 23.502 [3]);

– Handover from 5GC-N3IWF to EPS (see clause 4.11.3.2 of 3GPP TS 23.502 [3]);

– Handover from 5GS to EPC/ePDG (see clause 4.11.4.2 of 3GPP TS 23.502 [3]);

– I-SMF Context Transfer (see clause 4.26.5.2 of 3GPP TS 23.502 [3]);

– SMF Context Transfer procedure, LBO or no Roaming, no I-SMF (see clause 4.26.5.3 of 3GPP TS 23.502 [3]);

– Handover from W-5GAN/5GC to 3GPP access/EPS (see clause 7.6.4.2 of 3GPP TS 23.316 [36]);

– 5G-RG requested PDU Session Establishment via W-5GAN (see clause 7.3.1 of 3GPP TS 23.316 [36]);

– 5G-RG or Network requested PDU Session Modification via W-5GAN (see clause 7.3.2 of 3GPP TS 23.316 [36]);

– 5G-RG or Network requested PDU Session Release via W-5GAN (see clause 7.3.3 of 3GPP TS 23.316 [36])

– FN-RG related PDU Session Establishment via W-5GAN (see clause 7.3.4 of 3GPP TS 23.316 [36]);

– FN-RG or Network Requested PDU Session Modification via W-5GAN (see clause 7.3.6 of 3GPP TS 23.316 [36]);

– FN-RG or Network Requested PDU Session Release via W-5GAN (see clause 7.3.7 of 3GPP TS 23.316 [36]);

– Non-5G capable device behind 5G-CRG and FN-CRG requested PDU Session Establishment via W-5GAN (see clause 4.10a of 3GPP TS 23.316 [36]);

– Non-5G capable device behind 5G-CRG and FN-CRG or Network requested PDU Session Modification via W-5GAN (see clause 4.10a of 3GPP TS 23.316 [36]);

– Non-5G capable device behind 5G-CRG and FN-CRG or Network requested PDU Session Release via W-5GAN (see clause 4.10a of 3GPP TS 23.316 [36]);

– Handover between 3GPP access/5GC and W-5GAN access (see clause 7.6.3 of 3GPP TS 23.316 [36]);

– Handover from 3GPP access/EPS to W-5GAN/5GC (see clause 7.6.4.1 of 3GPP TS 23.316 [36]);

– Information flow for Availability after DDN Failure with SMF buffering (see clause 4.15.3.2.7 of 3GPP TS 23.502 [3]);

– Information flow for Availability after DDN Failure with UPF buffering (see clause 4.15.3.2.9 of 3GPP TS 23.502 [3]);

– The control of the PDU session is taken over by a new anchor SMF within the same SMF set (see clause 5.22 of 3GPP TS 29.244 [29]) or taken over by a new intermediate SMF (e.g. I-SMF or V-SMF) within the same SMF set, and the new SMF instance decides to notify the change of SMF.

The SMF shall notify the NF Service Consumer by using the HTTP POST method as shown in Figure 5.2.2.5.1-1.

Figure 5.2.2.5.1-1: SM context status notification

1. The SMF shall send a POST request to the SM Context Status callback reference provided by the NF Service Consumer during the subscription to this notification. The payload body of the POST request shall contain the notification payload.

If the notification is triggered by PDU session handover to release resources of the PDU session in the source access, the notification payload shall contain the resourceStatus IE with the value "RELEASED" and the Cause IE with the value "PDU_SESSION_HANDED_OVER" as specified in clause 4.9.2.3.2 of 3GPP TS 23.501 [2].

If the notification is triggered by PDU session handover to release only the SM Context with the I-SMF in the source access but without releasing the PDU session in the AMF, the notification payload shall contain the resourceStatus IE with the value "UPDATED" and the Cause IE with the value "PDU_SESSION_HANDED_OVER" as specified in clause 4.23.16.2 of 3GPP TS 23.502 [3].

If the notification is triggered by PDU session handover to release resources of the PDU session in the target access due to handover failure between 3GPP access and non-3GPP access, the notification payload shall contain the resourceStatus IE with the value "RELEASED" and the Cause IE with the value "PDU_SESSION_HAND_OVER_FAILURE".

If the NF Service Consumer indicated support of the HOFAIL feature (see clause 6.1.8) and if the notification is triggered by PDU session handover to update the access type of the PDU session due to a handover failure between 3GPP access and non-3GPP access, the notification payload shall contain the resourceStatus IE with the value "UPDATED", the anType IE with the value "3GPP" or "NON_3GPP" indicating the access type of the PDU session after the handover failure scenario and the Cause IE with the value "PDU_SESSION_HAND_OVER_FAILURE".

If the notification is triggered by the SMF derived CN assisted RAN parameters tuning, the notification payload shall contain the resourceStatus IE with the value "UNCHANGED" and the Cause IE with the value "CN_ASSISTED_RAN_PARAMETER_TUNING".

If the notification is triggered by SMF Context Transfer procedure, the notification payload shall contain the Cause IE with the value "ISMF_CONTEXT_TRANSFER" or "SMF_CONTEXT_TRANSFER".

If the notification is triggered by the report of the DDN failure, the notification payload shall contain the resourceStatus IE with the value "UNCHANGED" and the Cause IE with the value "DDN_FAILURE_STATUS".

If the notification is triggered to report that an alternative (H-)SMF has been used during a HR PDU session establishment or the establishment of a PDU session with an I-SMF, the notification payload shall contain the resourceStatus IE with the value "ALT_ANCHOR_SMF". The notification payload shall also include the altAnchorSmfUri IE containing the API URI of the alternative (H-)SMF used for the PDU session and if available the altAnchorSmfId IE containing the NF Instance Id of the alternative (H-)SMF. The Notification shall only be sent to the NF service consumer (e.g. AMF) supporting the AASN feature.

For a PDU session without an I-SMF or V-SMF, if upon a change of anchor SMF, the new anchor SMF instance decides to notify the change of anchor SMF, then the notification payload shall contain the resourceStatus IE with the value "UPDATED" and the Cause IE with the value "CHANGED_ANCHOR_SMF". In addition, the new anchor SMF shall include its SMF Instance ID in the notification payload, and/or carry an updated binding indication in the HTTP headers to indicate the change of anchor SMF (as per step 6 of clause 6.5.3.3 of 3GPP TS 29.500 [4]).

For a PDU session with an I-SMF or V-SMF, if upon a change of intermediate SMF (e.g. I-SMF or V-SMF), the new intermediate SMF instance decides to notify the change of intermediate SMF, then the notification payload shall contain the resourceStatus IE with the value "UPDATED" and the Cause IE with the value "CHANGED_INTERMEDIATE_SMF". In addition, the new intermediate SMF shall include its SMF Instance ID in the notification payload, and/or carry an updated binding indication in the HTTP headers to indicate the change of intermediate SMF (as per step 6 of clause 6.5.3.3 of 3GPP TS 29.500 [4]).

For a PDU session with an I-SMF or V-SMF, if the notification is triggered by the change of the anchor SMF (e.g. the PDU session is taken over by a new SMF within the same SMF Set selected by the UPF), the notification payload shall contain the resourceStatus IE with the value "UPDATED", the Cause IE with the value "CHANGED_ANCHOR_SMF" and the SMF Instance ID of the new anchor SMF.

2a. On success, "204 No Content" shall be returned and the payload body of the POST response shall be empty.

If the SMF indicated in the request that the SM context resource is released, the NF Service Consumer shall release its association with the SMF for the PDU session and release the EBI(s) that were assigned to the PDU session.

If the SMF indicated in the request that the SM context resource is updated with the anType IE, the NF Service Consumer shall change the access type of the PDU session with the value of anType IE.

If the notification request was triggered by PDU session handover to release only the SM Context with the I-SMF in the source access but without releasing the PDU session in the AMF, the AMF shall remove its resources associated to the SM context with the I-SMF, but the AMF shall not release the PDU session in the AMF, and the I-SMF shall remove its resources associated to the PDU session.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.7.3.1-2 shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.7.3.1-2.

If the NF Service Consumer (e.g. AMF) is not able to handle the notification but knows by implementation specific means that another NF Service Consumer (e.g. AMF) is able to handle the notification (e.g. AMF deployment with Backup AMF), it shall reply with an HTTP "307 temporary redirect" response pointing to the URI of the new NF Service Consumer. If the NF Service Consumer is not able to handle the notification but another unknown NF Service Consumer could possibly handle the notification (e.g. AMF deployment with UDSF), it shall reply with an HTTP "404 Not found" error response.

If the SMF receives a "307 temporary redirect" response, the SMF shall use this URI as Notification URI in subsequent communication and shall resend the notification to that URI.

If the SMF becomes aware that a new NF Service Consumer (e.g. AMF) is requiring notifications (e.g. via the "404 Not found" response or via Namf_Communication service AMFStatusChange Notifications, or via link level failures, see clause 6.5.2 of 3GPP TS 29.500 [4]), and the SMF knows alternate or backup Address(es) where to send Notifications (e.g. via the GUAMI and/or backupAmfInfo received when the SM context was established or via AMFStatusChange Notifications, or via the Nnrf_NFDiscovery service specified in 3GPP TS 29.510 [19] using the service name and GUAMI or backupAMFInfo obtained during the creation of the SM context, see clause 6.5.2.2 of 3GPP TS 29.500 [4]), the SMF shall exchange the authority part of the corresponding Notification URI with one of those addresses and shall use that URI in subsequent communication; the SMF shall resend the notification to that URI.

5.2.2.6 Retrieve SM Context service operation

5.2.2.6.1 General

The Retrieve SM Context service operation shall be used to retrieve an individual SM context, for a given PDU session, from the (H-)SMF, from the V-SMF during change or removal of V-SMF, or from the I-SMF during change or removal of I-SMF.

It is used in the following procedures:

– 5GS to EPS handover using N26 interface (see clause 4.11.1.2.1 of 3GPP TS 23.502 [3]), for PDU sessions associated with 3GPP access;

– 5GS to EPS Idle mode mobility using N26 interface (see clause 4.11.1.3.2 of 3GPP TS 23.502 [3]), for PDU sessions associated with 3GPP access;

– UE Triggered Service Request with I-SMF insertion/change/removal or with V-SMF insertion/change/removal (see clause 4.23.4.3 of of 3GPP TS 23.502 [3]);

– Xn based inter NG-RAN handover with insertion of intermediate SMF (see clause 4.23.11 of 3GPP TS 23.502 [3]), for PDU sessions associated with 3GPP access;

– Inter NG-RAN node N2 based handover, preparation phase, with I-SMF or V-SMF insertion/change (see clause 4.23.7.3.2 of 3GPP TS 23.502 [3]), for PDU sessions associated with 3GPP access;

– SMF Context Transfer procedure, LBO or no Roaming, no I-SMF (see clause 4.26.5.3 of 3GPP TS 23.502 [3]), for PDU sessions associated with 3GPP access.

The NF Service Consumer (e.g. AMF or SMF) shall retrieve an SM context by using the HTTP POST method (retrieve custom operation) as shown in Figure 5.2.2.6.1-1.

Figure 5.2.2.6.1-1: SM context retrieval

1. The NF Service Consumer shall send a POST request to the resource representing the individual SM context to be retrieved. The POST request may contain a payload body with the following parameters:

– target MME capabilities, if available, to allow the SMF to determine whether to include EPS bearer contexts for Ethernet PDN Type, non-IP PDN type or not;

– SM context type indicating that this is a request to retrieve the complete SM context (i.e. 5G SM context including EPS context information as defined in clause 6.1.6.2.39), during scenarios with an I-SMF or V-SMF insertion/change/removal or SMF Context Transfer procedure;

– serving core network operator PLMN ID of the new V-SMF, when the procedure is triggered by a new V-SMF, if the new V-SMF supports inter-PLMN V-SMF change;

– notToTransferEbiList IE, if the SM context type IE is absent or indicate a request to retrieve the EPS PDN connection, to request the SMF to not transfer EPS bearer context(s) corresponding to EBIs in the list, during an 5GS to EPS mobility when the target MME does not support 15 EPS bearers;

– ranUnchangedInd IE, if the NG-RAN Tunnel info is required in scenario of I-SMF/V-SMF change/insertion during registration procedure after EPS to 5GS handover, when the UE is in CM-CONNECTED state as specified in clause 5.2.2.2.7.

2a. On success, "200 OK" shall be returned; the payload body of the POST response shall contain the mapped EPS bearer contexts if this is a request for the UE EPS PDN connection, or the complete SM context if this is a request for retrieving the complete SM context.

If this is a request for the UE EPS PDN connection and the target MME capabilities were provided in the request parameters:

– if the target MME supports the non-IP PDN type, the SMF shall return, for a PDU session with PDU session type "Unstructured", an EPS bearer context with the "non-IP" PDN type;

– if the target MME supports the Ethernet PDN type, the SMF shall return, for a PDU session with PDU session type "Ethernet", an EPS bearer context with the "Ethernet" PDN type;

– if the target MME does not support the Ethernet PDN type but supports the non-IP PDN type, the SMF shall return, for a PDU session with PDU session type "Ethernet", an EPS bearer context with the "non-IP" PDN type.

If the notToTransferEbiList IE was included in the request, the SMF shall not provide EPS bearer context(s) corresponding to EBIs in the list.

If this is a request for retrieving the complete SM context and there are downlink data packets buffered at I-UPF, the SMF shall include the "forwardingInd" attribute with value "true" in the response body to indicate downlink data packets are buffered at the I-UPF. The NF Service Consumer receiving the "forwardingInd" attribute with the value "true" shall setup a forwarding tunnel for receiving the buffered downlink data packets.

If this is a request for retrieving the complete SM context for an inter-PLMN V-SMF change, i.e. if the request contains the serving core network operator PLMN ID indicating a different PLMN than the PLMN of the SMF (acting as the old V-SMF), the latter shall not include the chargingInfo IE and the roamingChargingProfile IE in the SM context returned in the response.

If this is a request for retrieving the complete SM context for an I-SMF or V-SMF insertion, and the smfUri IE or hSmfUri IE is provided by the AMF in the Create SM Context request and is different from the smfUri IE or hSmfUri IE in the SM context returned in the Retrieve SM Context response, the latter (i.e. the IEs received in the Retrieve SM Context response) shall prevail and be used by the I-SMF or V-SMF to trigger the create service operation to the (H-)SMF.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.4.4.2-2 shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.3.4.4.2-2.

If the EBI value of the QoS Flow associated with the default QoS Rule is included in the notToTransferEbiList IE, the SMF shall set the "cause" attribute in the ProblemDetails structure to "DEFAULT_EBI_NOT_TRANSFERRED".

5.2.2.7 Create service operation

5.2.2.7.1 General

The Create service operation shall be used to create an individual PDU session in the H-SMF for HR roaming scenarios, or in the SMF for PDU sessions involving an I-SMF.

It is used in the following procedures:

– UE requested PDU Session Establishment with or without an I-SMF insertion (see clauses 4.3.2.2.2 and 4.23.5.1 of 3GPP TS 23.502 [3]);

– when an I-SMF is inserted during the Registration, Service Request, Inter NG-RAN node N2 based handover, Xn based handover, Handover from EPC/ePDG to 5GS and Handover from non-3GPP to 3GPP access procedures (see clauses 4.23.3, 4.23.4, 4.23.7.3, 4.23.11.2 and 4.23.16 of 3GPP TS 23.502 [3]);

– EPS to 5GS Idle mode mobility or handover using N26 interface (see clauses 4.11, 4.23.12.3, 4.23.12.5 and 4.23.12.7 of 3GPP TS 23.502 [3]);

– EPS to 5GS mobility without N26 interface (see clause 4.11.2.3 of 3GPP TS 23.502 [3]);

– Handover from EPS to 5GC-N3IWF (see clause 4.11.3.1 of 3GPP TS 23.502 [3]);

– Handover from EPC/ePDG to 5GS (see clause 4.11.4.1 of 3GPP TS 23.502 [3]).

The NF Service Consumer (e.g. V-SMF or I-SMF) shall create a PDU session in the SMF (i.e. H-SMF for a HR PDU session, or SMF for a PDU session involving an I-SMF) by using the HTTP POST method as shown in Figure 5.2.2.7.1-1.

Figure 5.2.2.7.1-1: PDU session creation

1. The NF Service Consumer shall send a POST request to the resource representing the PDU sessions collection resource of the SMF. The payload body of the POST request shall contain:

– a representation of the individual PDU session resource to be created;

– the Request Type IE, if it is received from the UE for a single access PDU session and if the request refers to an existing PDU session or an existing Emergency PDU session; the Request Type shall not be included for a MA-PDU session establishment request; it may be included otherwise;

– the vsmfId IE or ismfId IE identifying the V-SMF or I-SMF respectively;

– the cpCiotEnabled IE with the value "True", if Control Plane CIoT 5GS Optimisation is enabled for this PDU session;

– the cpOnlyInd IE with the value "True", if the PDU session shall only use Control Plane CIoT 5GS Optimisation;

– the Invoke NEF indication with the value "True", if the cpCiotEnabled IE is set to "True" and data delivery via NEF is selected for the PDU session;

– the vcnTunnelInfo IE or icnTunnelInfo IE with the N9 tunnel information of the UPF controlled by the V-SMF or I-SMF respectively, except for EPS to 5GS handover using N26 interface and when Control Plane CIoT 5GS Optimisation is enabled and data delivery via NEF is selected for this PDU session;

– the additionalCnTunnelInfo IE with additional N9 tunnel information, if a MA PDU session is requested or if the PDU session is allowed to be upgraded to a MA PDU session, and if the UE is registered over both 3GPP and Non-3GPP accesses;

– the anType IE, indicating the access network type (3GPP or non-3GPP access) associated to the PDU session;

– the additionalAnType IE indicating an additional access network type associated to the PDU session, for a MA PDU session, if the UE is registered over both 3GPP and Non-3GPP accesses;

– the n9ForwardingTunnelInfo IE indicating the allocated N9 tunnel endpoints information for receiving the buffered downlink data packets, when downlink data packets are buffered at I-UPF controlled by the SMF during I-SMF insertion;

– a callback URI ({vsmfPduSessionUri} or {ismfPduSessionUri}) representing the PDU session resource in the V-SMF or I-SMF. The SMF shall construct the callback URIs based on the received {vsmfPduSessionUri} or {ismfPduSessionUri} as defined in clause 6.1, e.g. the callback URI "{vsmfPduSessionUri}/modify" to modify a PDU session in the V-SMF;

– the list of DNAIs supported by the I-SMF, for a PDU session with an I-SMF;

– the QoS constraints from the VPLMN for the QoS Flow associated with the default QoS rule and/or for the Session-AMBR if any, for the HR PDU session, if the VQOS feature is supported by the V-SMF.

As specified in clause 4.3.2.2.2 of 3GPP TS 23.502 [3], the NF Service Consumer shall be able to receive an Update request before receiving the Create Response, e.g. for EPS bearer ID allocation (see clause 4.11.1.4.1 of 3GPP TS 23.502 [3]) or Secondary authorization/authentication (see clause 4.3.2.3 of 3GPP TS 23.502 [3]).

NOTE: If the H-SMF supports the VQOS feature, when QoS constraints are received from the VPLMN and PCF is deployed, the H-SMF provides the QoS constraints from the VPLMN to the PCF; otherwise, in case dynamic PCC is not deployed, the SMF takes them into account when generating the default QoS rule.

2a. On success, "201 Created" shall be returned, the payload body of the POST response shall contain:

– the representation describing the status of the request;

– the QoS flow(s) to establish for the PDU session, except when Control Plane CIoT 5GS Optimisation is enabled for this PDU session;

– the epsPdnCnxInfo IE and, for each EPS bearer, an epsBearerInfo IE, if the PDU session is associated to (or handed over to) the 3GPP access type and may be moved to EPS during its lifetime;

– a MA PDU Session Accepted indication, if a MA PDU session is established;

– the smallDataRateControlEnabled indication set to "true" if small data rate control is applicable on the PDU session;

– the "Location" header containing the URI of the created resource.

The payload body of the POST response may also contain the upSecurity, maxIntegrityProtectedDataRateUl and maxIntegrityProtectedDataRateDl IEs, if the PDU session is associated to (or handed over to) the 3GPP access type.

The SMF may provide alternative QoS profiles for each GBR QoS flow with Notification control enabled, to allow the NG-RAN to accept the setup of the QoS flow if the requested QoS parameters or at least one of the alternative QoS parameters sets can be fulfilled at the time of setup.

The authority and/or deployment-specific string of the apiRoot of the created resource URI may differ from the authority and/or deployment-specific string of the apiRoot of the request URI received in the POST request.

If an Update Request was sent to the NF Service Consumer before the Create Response, the URI in the "Location" header and in the hsmfPduSessionUri IE (or smfPduSessionUri IE for a PDU session with an I-SMF) of the SMF initiated Update Request shall be the same. If the Request Type was received in the request and set to EXISTING_PDU_SESSION or EXISTING_EMERGENCY_PDU_SESSION (i.e. indicating that this is a UE request for an existing PDU session or an existing emergency PDU session), the SMF shall identify the existing PDU session or emergency PDU session based on the PDU Session ID; in this case, the SMF shall not create a new PDU session or emergency PDU session but instead update the existing PDU session or emergency PDU session and provide the representation of the updated PDU session or emergency PDU session in the response to the NF Service Consumer.

The POST request shall be considered as colliding with an existing PDU session context if:

– it includes the same SUPI, or PEI for an emergency registered UE without a UICC or without an authenticated SUPI, and the same PDU Session ID as for an existing PDU session context; and

– this is a request to establish a new PDU session, i.e.:

– the RequestType IE is present in the request and set to INITIAL_REQUEST or INITIAL_EMERGENCY_REQUEST (e.g. single access PDU session establishment request);

– the RequestType IE and the maRequestInd IE are both absent in the request (e.g. EPS to 5GS mobility); or

– the maRequestInd IE is present in the request (i.e. MA-PDU session establishment request) and the access type indicated in the request corresponds to the access type of the existing PDU session context.

A POST request that collides with an existing PDU session context shall be treated as a request for a new PDU session context. Before creating the new PDU session context, the SMF should delete the existing PDU session context locally and any associated resources in the UPF and PCF. See also clause 5.2.3.3.1 for the handling of requests which collide with an existing PDU session context. If the vsmfPduSessionUri or ismfPduSessionUri of the existing PDU session context differs from the vsmfPduSessionUri or ismfPduSessionUri received in the POST request, the SMF shall also send a status notification (see clause 5.2.2.10) targeting the vsmfPduSessionUri or ismfPduSessionUri of the existing PDU session context to notify the release of the existing PDU session context.

If the Request Type was received in the request and indicates this is a request for a new PDU session (i.e. INITIAL_REQUEST) and if the Old PDU Session ID was also included in the request, the SMF shall identify the existing PDU session to be released and to which the new PDU session establishment relates, based on the Old PDU Session ID.

The NF Service Consumer shall store any epsPdnCnxInfo and EPS bearer information received from the SMF.

If the response received from the SMF contains the alwaysOnGranted attribute set to true, the NF Service Consumer shall check and determine whether the PDU session can be established as an always-on PDU session based on local policy.

If no GPSI IE is provided in the request, e.g. for a PDU session moved from another access or another system, and the SMF knows that a GPSI is already associated with the PDU session, the SMF shall include the GPSI in the response.

If one or more requested QoS flow(s) fail to be established, the V-SMF or I-SMF shall send an Update Request including the qosFlowsRelNotifyList attribute to report the failure to the H-SMF or SMF (see clause 5.2.2.8.2.2), or a Release Request to release the PDU session if no QoS flow can be established (see clause 5.2.2.9).

For UE mobility with I-SMF/V-SMF insertion procedure, if a requested functionality is not supported for a PDU session with an I-SMF/V-SMF, the SMF shall accept the POST request and release the PDU Session after the mobility procedure, as specified in clause 4.23.1 of 3GPP TS 23.502 [3].

2b. On failure, or redirection during a UE requested PDU Session Establishment, one of the HTTP status code listed in Table 6.1.3.5.3.1-3 shall be returned. For a 4xx/5xx response, the message body shall contain a PduSessionCreateError structure, including:

– a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.5.3.1-3. The application error shall be set to "NOT_SUPPORTED_WITH_ISMF" during a UE requested PDU Session Establishment, if a requested functionality is not supported for a PDU session with an I-SMF/V-SMF.

– the n1SmCause IE with the 5GSM cause that the SMF proposes the NF Service Consumer to return to the UE, if the request included n1SmInfoFromUe;

– n1SmInfoToUe with any information to be sent to the UE (in the PDU Session Establishment Reject).

5.2.2.7.2 EPS to 5GS Idle mode mobility

The requirements specified in clause 5.2.2.7.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.7.1-1, with the following additions.

The POST request shall contain:

– the list of EPS Bearer Ids received from the MME;

– the PGW S8-C F-TEID received from the MME;

– the epsBearerCxtStatus attribute, indicating the status of all the EPS bearer contexts in the UE, if corresponding information has been received in the Create SM Context request (see clause 5.2.2.2.2).

2a. Same as step 2 of Figure 5.2.2.7.1-1, with the following modifications.

If:

– the SMF finds a corresponding PDU session based on the EPS Bearer Ids and PGW S8-C F-TEID received in the request;

– the default EPS bearer context of the corresponding PDU session is not reported as inactive by the UE in the epsBearerCtxStatus attribute, if received; and

– the SMF can proceed with moving the PDN connection to 5GS,

then the SMF shall return a 201 Created response including the following additional information:

– PDU Session ID corresponding to the EPS PDN connection;

– other PDU session parameters, such as PDU Session Type, Session AMBR, QoS flows information.

NOTE: The behaviour specified in this step also applies if the POST request collides with an existing PDU session context, i.e. if the POST request includes the same SUPI, or PEI for an emergency registered UE without a UICC or without an authenticated SUPI, and the received EPS bearer ID is the same as in the existing PDU session context.

2b. Same as step 2b of Figure 5.2.2.7.1-1, with the following additions.

5.2.2.7.3 EPS to 5GS Handover Preparation

The requirements specified in clause 5.2.2.7.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.7.1-1, with the following modifications.

The POST request shall contain:

– the list of EPS Bearer Ids received from the MME;

– the PGW S8-C F-TEID received from the MME;

– the hoPreparationIndication IE set to "true", to indicate that a handover preparation is in progress and the PGW-C/SMF shall not switch the DL user plane of the PDU session yet.

2a. Same as step 2 of Figure 5.2.2.7.1-1, with the following modifications.

If the SMF finds a corresponding PDU session based on the EPS Bearer Ids and PGW S8-C F-TEID received in the request, and if it can proceed with the procedure, the SMF shall return a 201 Created response including the following information:

– PDU Session ID corresponding to the EPS PDN connection;

– other PDU session parameters, such as PDU Session Type, Session AMBR, QoS flows information.

The SMF shall not switch the DL user plane of the PDU session, if the hoPreparationIndication IE was set to "true" in the request.

2b. Same as step 2b of Figure 5.2.2.7.1-1, with the following additions.

If the H-SMF determines that seamless session continuity from EPS to 5GS is not supported for the PDU session, the H-SMF shall set the "cause" attribute in the ProblemDetails structure to "NO_EPS_5GS_CONTINUITY".

5.2.2.7.4 N2 Handover Preparation with I-SMF Insertion

The requirements specified in clause 5.2.2.7.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.7.1-1, with the following modifications.

The POST request shall contain:

– the hoPreparationIndication IE set to "true", to indicate that a handover preparation is in progress and the SMF shall not switch the DL user plane of the PDU session yet.

2a. Same as step 2 of Figure 5.2.2.7.1-1, with the following modifications:

The SMF shall not switch the DL user plane of the PDU session, if the hoPreparationIndication IE was set to "true" in the request.

5.2.2.7.5 Xn Handover with I-SMF Insertion

The requirements specified in clause 5.2.2.7.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.7.1-1, with the following modifications.

The POST request shall contain:

– the upSecurityInfo IE, if received from the AMF.

2a. Same as step 2 of Figure 5.2.2.7.1-1, with the following modifications:

The SMF shall verify that the upSecurity IE included in the received upSecurityInfo IE is same as the security policy for integrity protection and encryption that the SMF has locally stored. If there is a mismatch, the SMF shall send its locally stored security policy for integrity protection and encryption in upSecurity IE to NG-RAN as specified in clause 6.6.1 of 3GPP TS 33.501 [17].

5.2.2.7.6 UE Triggered Service Request with I-SMF Insertion

The requirements specified in clause 5.2.2.7.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.7.1-1, with the following modifications.

The POST request shall additionally contain:

– the upCnxState IE set to ACTIVATING to indicate that User Plane resource for the PDU Session is going to be established by the I-SMF.

2a. Same as step 2 of Figure 5.2.2.7.1-1, with the following modifications:

The SMF shall behave as specified in clause 4.23.4.3 (step 8a) of 3GPP TS 23.502 [3].

The SMF handling of a subsequent Update request with the upCnxState IE set to ACTIVATED is specified in step 3 of clause 5.2.2.8.2.23.

NOTE: The upCnxState IE set to ACTIVATING implements the "Operation Type" parameter set to "UP Activate" specified in clause 4.23.4.3 (step 8a) in 3GPP TS 23.502 [3].

5.2.2.8 Update service operation

5.2.2.8.1 General

The Update service operation shall be used for HR PDU sessions or for PDU sessions involving an I-SMF to:

– update an individual PDU session in the H-SMF or SMF and/or provide the H-SMF or SMF with information received by the V-SMF or I-SMF in N1 SM signalling from the UE;

– update a MA PDU session to indicate an additional access type, if the UE requests establishment of MA PDU session via the other access after the UE is registered to both 3GPPP access and non-3GPP access and the MA PDU session was successfully established on the first access (see clause 4.22.2.2 of 3GPP TS 23.502 [3]);

– release a MA PDU session over a single access in the H-SMF or SMF;

– update an individual PDU session in the V-SMF or I-SMF and/or provide information necessary for the V-SMF or I-SMF to send N1 SM signalling to the UE.

It is invoked by the V-SMF or I-SMF in the following procedures:

– UE or network (e.g. V-SMF, I-SMF) requested PDU session modification (see clauses 4.3.3.3 and 4.23.5.3 of 3GPP TS 23.502 [3]);

– UE or network (e.g. AMF, V-SMF, I-SMF) requested PDU session release (see clause 4.3.4.3 of 3GPP TS 23.502 [3]);

– UE or network (e.g. AMF, V-SMF, I-SMF) initiated MA PDU session release over a single access (see clause 4.22 of 3GPP TS 23.502 [3]);

– EPS to 5GS handover execution using N26 interface (see clause 4.11 of 3GPP TS 23.502 [3]);

– Handover between 3GPP and untrusted or trusted non-3GPP access procedures (see clauses 4.9.2 and 4.9.3 of 3GPP TS 23.502 [3]), without AMF change or with target AMF in same PLMN;

– All procedures requiring to provide the H-SMF or SMF with information received by the V-SMF or I-SMF in N1 SM signalling from the UE to the H-SMF or SMF;

– Secondary RAT Usage Data Reporting (see clause 4.21 of 3GPP TS 23.502 [3]);

– UPF anchored Mobile Originated Data Transport in Control Plane CIoT 5GS Optimisation (see clause 4.24.1 of 3GPP TS 23.502 [3]);

– Connection Resume in CM-IDLE with Suspend procedure (see clause 4.8.2.3 of 3GPP TS 23.502 [3]);

– UE Triggered Service Request without I-SMF/V-SMF change/removal (see clause 4.23.4.2 of 3GPP TS 23.502 [2]) or UE Triggered Service Request with I-SMF/V-SMF change or with I-SMF insertion (see clause 4.23.4.3 of 3GPP TS 23.502 [2]).

It is invoked by the I-SMF in the following procedures:

– Addition of PDU Session Anchor and Branching Point or UL CL controlled by I-SMF (see clause 4.23.9.1 of 3GPP TS 23.502 [3]);

– Removal of PDU Session Anchor and Branching Point or UL CL controlled by I-SMF (see clause 4.23.9.2 of 3GPP TS 23.502 [3]);

– Change of PDU Session Anchor for IPv6 multi-homing or UL CL controlled by I-SMF (see clause 4.23.9.3 of 3GPP TS 23.502 [3]);

– Sending by I-SMF of N4 notifications related with traffic usage reporting (see clause 5.34.6 of 3GPP TS 23.501 [2]).

It is invoked by the H-SMF or SMF in the following procedures:

– Network (e.g. H-SMF, SMF) requested PDU session modification (see clauses 4.3.3.3 and 4.23.5.3 of 3GPP TS 23.502 [3]);

– Network (e.g. H-SMF, SMF) requested PDU session release (see clause 4.3.4.3 of 3GPP TS 23.502 [3]);

– Network (e.g. H-SMF, SMF) initiated MA PDU session release over a single access (see clause 4.22 of 3GPP TS 23.502 [3]);

– All procedures requiring to provide information necessary for the V-SMF or I-SMF to send N1 SM signalling to the UE;

– EPS Bearer ID allocation or revocation (see clauses 4.11.1.4.1 and 4.11.1.4.3 of 3GPP TS 23.502 [3]);

– Secondary authorization/authentication by an DN-AAA server (see clause 4.3.2.3 of of 3GPP TS 23.502 [3]).

It is invoked by the SMF in the following procedures:

– Addition of PDU Session Anchor and Branching Point or UL CL controlled by I-SMF (see clause 4.23.9.1 of 3GPP TS 23.502 [3]);

– Removal of PDU Session Anchor and Branching Point or UL CL controlled by I-SMF (see clause 4.23.9.2 of 3GPP TS 23.502 [3]);

– Change of PDU Session Anchor for IPv6 multi-homing or UL CL controlled by I-SMF (see clause 4.23.9.3 of 3GPP TS 23.502 [3]);

– Policy update procedures with an I-SMF (see clause 4.23.6.2 of 3GPP TS 23.502 [3]).

5.2.2.8.2 Update service operation towards H-SMF or SMF

5.2.2.8.2.1 General

The NF Service Consumer (i.e. the V-SMF for a HR PDU session, or the I-SMF for a PDU session with an I-SMF) shall update a PDU session in the H-SMF or SMF and/or provide the H-SMF or SMF with information received by the NF Service Consumer in N1 SM signalling from the UE, by using the HTTP POST method (modify custom operation) as shown in Figure 5.2.2.8.2-1.

Figure 5.2.2.8.2-1: PDU session update towards H-SMF or SMF

1. The NF Service Consumer shall send a POST request to the resource representing the individual PDU session resource in the H-SMF or SMF. The payload body of the POST request shall contain:

– the requestIndication IE indicating the request type. Unless specified otherwise in clause 5.2.2.8.2, the value of the requestIndication IE shall be set to NW_REQ_PDU_SES_MOD;

– the modification instructions and/or the information received by the NF Service Consumer in N1 signalling from the UE.

If the PDU session may be moved to EPS with N26 and the EPS PDN Connection Context information of the PDU session is changed, e.g. due to a new anchor SMF is reselected, the payload shall include the "epsPdnCnxInfo" IE including the updated EPS PDN Connection Context information. The NF Service consumer shall overwrite the locally stored EPS PDN Connection Context information with the new one if received.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.3.2-3 shall be returned. For a 4xx/5xx response, the message body shall contain an HsmfUpdateError structure, including:

– a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.3.3.2-3;

– the n1SmCause IE with the 5GSM cause the H-SMF or SMF proposes the NF Service Consumer to return to the UE, if the request included n1SmInfoFromUe;

– n1SmInfoToUe binary data, if the H-SMF or SMF needs to return NAS SM information which the NF Service Consumer does not need to interpret;

– the procedure transaction id that was received in the request, if this is a response sent to a UE requested PDU session modification.

5.2.2.8.2.2 UE or network (e.g. AMF, V-SMF, I-SMF) requested PDU session modification

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to UE_REQ_PDU_SES_MOD, and the modifications requested by the UE, e.g. UE requested QoS rules or UE requested Qos flow descriptions, in an N1 SM container IE as specified in clause 5.2.3.1, or indication that the PDU session is allowed to be upgraded to a MA PDU session as specified in clause 6.4.2.2 of 3GPP TS 24.501 [7], for a UE requested PDU session modification; or

– the requestIndication set to NW_REQ_PDU_SES_MOD, and the modifications requested by the visited network or the notifications initiated by the visited network, for a visited network requested PDU session modification, e.g. to:

– report the release of QoS flow(s) or notify QoS flow(s) whose targets QoS are no longer fulfilled; in the latter case, the V-SMF/I-SMF may also report an alternative QoS profile which the NG-RAN can currently fulfil in the currentQosProfileIndex IE or report that the NG-RAN cannot even fulfil the lowest alternative QoS profile by setting the nullQoSProfileIndex IE to "true" for the corresponding Qos flow(s);

– report that the user plane security enforcement with a value Preferred is not fulfilled or is fulfilled again, in the NotifyList IE and the securityResult IE, if the new security status is received from NG-RAN;

– report that access type of the PDU session can be changed; in this case, the anTypeCanBeChanged attribute shall be set to "true";

– report the "MO Exception Data Counter";

– request for QoS modification initiated by VPLMN, if the H-SMF supports the VPLMN QoS (VQOS) feature.

5.2.2.8.2.3 UE requested PDU session release

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to UE_REQ_PDU_SES_REL.

5.2.2.8.2.4 EPS to 5GS Handover Execution

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to PDU_SES_MOB;

– the list of EPS Bearer Ids successfully handed over to 5GS;

– the hoPreparationIndication IE set to "false", to indicate that there is no handover preparation in progress anymore and that the PGW-C/SMF shall switch the DL user plane of the PDU session.

2. Same as step 2 of Figure 5.2.2.8.2-1, with the following modifications.

The H-SMF or SMF shall return a 200 OK response. The H-SMF or SMF shall switch the DL user plane of the PDU session using the N9 tunnel information that has been received in the vcnTunnelInfo or icnTunnelInfo, if the hoPreparationIndication IE was set to "false" in the request.

If the handover preparation failed (e.g. the target 5G-AN failed to establish resources for the PDU session), the requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to PDU_SES_MOB;- the cause attribute set to "HO_FAILURE";

– an empty list of EPS Bearer Ids;

– the hoPreparationIndication IE set to "false", to indicate that there is no handover preparation in progress anymore.

2. Same as step 2 of Figure 5.2.2.8.2-1, with the following modifications.

The H-SMF or SMF shall return a 200 OK response. The H-SMF or SMF shall release the resources prepared for the handover.

5.2.2.8.2.5 Handover between 3GPP access and untrusted or trusted non-3GPP access

For Handover between 3GPP access and untrusted or trusted non-3GPP access procedures, without AMF change or with the target AMF in the same PLMN, the requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain the anType set to the target access type, i.e. to 3GPP_ACCESS or NON_3GPP_ACCESS.

The requestIndication IE shall be set to PDU_SES_MOB.

For a handover from non-3GPP access to 3GPP access with a V-SMF change, the requirements specified in step 1 of clause 5.2.2.8.2.10, other than how to set the requestIndication, shall also apply.

2a. Same as step 2a of Figure 5.2.2.8.2-1, with the following modifications.

The payload body of the POST response shall include:

– all QoS information for the QoS Flow(s) applicable to the PDU Session for the target access type, so that when sending the PDU Session Establishment Accept, the V-SMF or I-SMF can include all QoS information (e.g. QoS Rule(s) in N1 SM container, QFI(s) and QoS Profile(s) in N2 SM information) for the QoS Flow(s) (acceptable according to VPLMN policies for a HR PDU session); and

– the epsPdnCnxInfo IE and, for each EPS bearer, an epsBearerInfo IE, if the PDU session may be moved to EPS during its lifetime, for a handover from non-3GPP access to 3GPP access.

The payload body of the POST response may also contain the upSecurity, maxIntegrityProtectedDataRateUl and maxIntegrityProtectedDataRateDl IEs during a handover from non-3GPP access to 3GPP access.

For a handover from non-3GPP access to 3GPP access with a V-SMF change, the requirements specified in step 2 of clause 5.2.2.8.2.10 shall also apply.

Upon receipt of the 200 OK response, the V-SMF or I-SMF shall delete any above information received earlier for the source access type and use the new information received for the target access type (see clause 6.1.6.2.12).

NOTE: As specified in clause 4.11.1.4.3 of 3GPP TS 23.502 [3], the AMF, the SMF and the UE release locally the EBI(s) allocated to a PDU Session handed over from 3GPP access to non-3GPP access.

For a handover from non-3GPP access to 3GPP access, if the PDU session may be moved to EPS during its lifetime, the H-SMF or SMF may send an Update Request towards the V-SMF or I-SMF to request the allocation of EBIs prior to step 2a.

If one or more requested QoS flow(s) fail to be established in the target access type, the V-SMF or I-SMF shall send an Update Request including the qosFlowsRelNotifyList attribute to report the failure to the H-SMF or SMF (see clause 5.2.2.8.2.2), or a Release Request to release the PDU session if no QoS flow can be established (see clause 5.2.2.9).

5.2.2.8.2.6 P-CSCF Restoration Procedure via AMF

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications:

The POST request shall contain:

– the requestIndication IE set to NW_REQ_PDU_SES_REL;

– the cause IE set to REL_DUE_TO_REACTIVATION.

5.2.2.8.2.7 Addition of PSA and BP or UL CL controlled by I-SMF

This clause applies only in case of non-roaming or LBO roaming as control of an UL CL or BP in VPLMN is not supported in HR roaming case (see clause 5.34.4 of 3GPP TS 23.501 [2]).

An I-SMF and I-UPF have already been inserted for the PDU session.

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications:

The POST request shall contain:

– the requestIndication IE set to NW_REQ_PDU_SES_MOD;

– the indication that an UL CL or BP has been inserted into the data path of the PDU session;

– the list of DNAIs supported by the inserted PSA;

– the new UE IPv6 prefix at the PSA, assigned by the I-SMF or by the UPF supporting the PSA, if IPv6 multi-homing applies to the PDU session;

– the icnTunnelInfo with the N9 tunnel information of the UL CL or BP for the downlink traffic, if a UPF different from the earlier I-UPF is selected for the UL CL or BP.

2a. Same as step 2a of Figure 5.2.2.8.2-1.

5.2.2.8.2.8 Removal of PSA and BP or UL CL controlled by I-SMF

This clause applies only in case of non-roaming or LBO roaming as control of an UL CL or BP in VPLMN is not supported in HR roaming case (see clause 5.34.4 of 3GPP TS 23.501 [2]).

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications:

The POST request shall contain:

– the requestIndication IE set to NW_REQ_PDU_SES_MOD;

– the indication that an UL CL or BP has been removed from the data path of the PDU session;

– the removed UE IPv6 prefix at the PSA, if IPv6 multi-homing applies to the PDU session;

– the list of DNAIs supported by the removed PSA;

– the icnTunnelInfo with the N9 tunnel information of the I-UPF for the downlink traffic.

2a. Same as step 2a of Figure 5.2.2.8.2-1.

5.2.2.8.2.9 Change of PSA for IPv6 multi-homing or UL CL controlled by I-SMF

This clause applies only in case of non-roaming or LBO roaming as control of an UL CL or BP in VPLMN is not supported in HR roaming case (see clause 5.34.4 of 3GPP TS 23.501 [2]).

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications:

The POST request shall contain:

– the requestIndication IE set to NW_REQ_PDU_SES_MOD;

– the indication that a PSA is removed and another PSA is inserted;

– the list of DNAIs supported by the inserted PSA;

– the new UE IPv6 prefix at the inserted PSA, assigned by the I-SMF or by the UPF supporting the PSA, if IPv6 multi-homing applies to the PDU session;

– the removed UE IPv6 prefix at the removed PSA, if IPv6 multi-homing applies to the PDU session;

– the list of DNAIs supported by the removed PSA.

2a. Same as step 2a of Figure 5.2.2.8.2-1.

5.2.2.8.2.10 PDU Session modification with I-SMF or V-SMF change

During PDU Session modification with I-SMF or V-SMF change, the NF Service Consumer (i.e. the new V-SMF for a HR PDU session, or the new I-SMF for a PDU session with an I-SMF) shall update the PDU session in the H-SMF or SMF and provide the information of the new I-SMF or V-SMF.

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following additions:

The POST request shall contain:

– the requestIndication set to NW_REQ_PDU_SES_MOD or UE_REQ_PDU_SES_MOD for network requested or UE requested PDU session modification respectively;

– the ismfPduSessionUri or vsmfPduSessionUri IE containing the callback URI ({vsmfPduSessionUri} or {ismfPduSessionUri}) representing the PDU session in the new I-SMF or new V-SMF. The H-SMF or SMF shall construct the callback URIs based on the received {vsmfPduSessionUri} or {ismfPduSessionUri} as defined in clause 6.1, e.g. the callback URI "{vsmfPduSessionUri}/modify" to modify a PDU session in the V-SMF;

– the ismfId or vsmfId IE containing the identifier of the new I-SMF or new V-SMF;

– optionally the iSmfServiceInstanceId or vSmfServiceInstanceId IE containing the serviceInstanceId of the new I-SMF or new V-SMF service instance serving the PDU session;

– the supportedFeatures IE indicating the optional features the NF Service Consumer supports, if at least one optional feature defined in clause 6.1.8 is supported.

2. Same as step 1 of Figure 5.2.2.8.2-1, the SMF shall replace the corresponding information for the old I-SMF or old V-SMF stored locally with the received information. In addition, the SMF shall include the supportedFeatures IE in the response, if the supportedFeatures IE was received in the request and at least one optional feature defined in clause 6.1.8 is supported by the updated PDU session resource.

5.2.2.8.2.11 Sending by I-SMF of N4 notifications related with traffic usage reporting

This clause applies only in case of non-roaming or LBO roaming as control of an UL CL or BP in VPLMN is not supported in HR roaming case (see clause 5.34.4 of 3GPP TS 23.501 [2]).

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications:

The POST request shall contain:

– the requestIndication IE set to NW_REQ_PDU_SES_MOD;

– N4 information related with traffic usage reporting (i.e. PFCP Session Report Request, see Annex D of 3GPP TS 29.244 [29]);

– the DNAI related to the N4 information if the latter relates to a local PSA;

2a. Same as step 2a of Figure 5.2.2.8.2-1, with the following modifications:

The payload body of the POST response shall contain:

– N4 response information (i.e. PFCP Session Report Response);

– the DNAI related to the N4 information if the latter relates to a local PSA.

5.2.2.8.2.12 N2 Handover Execution with I-SMF Insertion

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to NW_REQ_PDU_SES_MOD;

– the hoPreparationIndication IE set to "false", to indicate that there is no handover preparation in progress anymore and that the SMF shall switch the DL user plane of the PDU session;

– the qosFlowsRelNotifyList IE indicating the failed QoS flow(s), if one or more QoS flow(s) cannot be established at the target RAN.

2. Same as step 2 of Figure 5.2.2.8.2-1, with the following modifications.

The SMF shall return a 200 OK response. The SMF shall switch the DL user plane of the PDU session using the N9 tunnel information that has been received in the icnTunnelInfo, if the hoPreparationIndication IE was set to "false" in the request.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to NW_REQ_PDU_SES_MOD;- the cause attribute set to "HO_FAILURE";

– the hoPreparationIndication IE set to "false", to indicate that there is no handover preparation in progress anymore.

2. Same as step 2 of Figure 5.2.2.8.2-1, with the following modifications.

The SMF shall return a 200 OK response. The SMF shall release the resources prepared for the handover.

5.2.2.8.2.13 N2 Handover Cancellation with I-SMF Insertion

For handover cancellation, the requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to NW_REQ_PDU_SES_MOD;

– the cause attribute set to "HO_CANCEL";

– the hoPreparationIndication IE set to "false", to indicate that there is no handover preparation in progress anymore.

2. Same as step 2 of Figure 5.2.2.8.2-1, with the following modifications.

The SMF shall return a 200 OK response. The SMF shall release the resources prepared for the handover.

5.2.2.8.2.14 EPS to 5GS Handover Cancellation

If the handover cancellation, the requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to PDU_SES_MOB;

– the cause attribute set to "HO_CANCEL";

– an empty list of EPS Bearer Ids;

– the hoPreparationIndication IE set to "false", to indicate that there is no handover preparation in progress anymore.

2. Same as step 2 of Figure 5.2.2.8.2-1, with the following modifications.

The H-SMF or SMF shall return a 200 OK response. The H-SMF or SMF shall release the resources prepared for the handover. The combined PGW-C+SMF shall not release the PDN connection that was attempted to be handed over.

5.2.2.8.2.15 5G-AN requested PDU session resource release

This clause applies only in case of 5G-AN requested PDU session resource release by sending the NGAP PDU SESSION RESOURCE NOTIFY to the AMF case (see step 1d in clause 4.3.4.3 of 3GPP TS 23.502 [3]).

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to REL_DUE_TO_5G_AN_REQUEST to indicate that the PDU session resource has been released by the 5G-AN.

After receving the request, the SMF may decide to keep the PDU Session (with user plane connection deactivated) or release the PDU Session.

5.2.2.8.2.16 Xn Handover with or without I-SMF or V-SMF Change

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the upSecurityInfo IE, if received from the NG-RAN;

– the qosFlowsRelNotifyList IE indicating the failed QoS flow(s), if one or more QoS flow(s) cannot be established at the target RAN.

For an Xn handover with an I-SMF or V-SMF change, the requirements specified in step 1 of clause 5.2.2.8.2.10, other than how to set the requestIndication, shall also apply.

2. Same as step 2 of Figure 5.2.2.8.2-1, with the following modifications.

For an Xn handover with an I-SMF or V-SMF change, the requirements specified in step 2 of clause 5.2.2.8.2.10 shall also apply.

5.2.2.8.2.17 EPS to 5GS Handover Failure

If the handover to 5GS failed, e.g. rejected by the target NG-RAN, the requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to PDU_SES_MOB;

– the cause attribute set to "HO_FAILURE";

– an empty list of EPS Bearer Ids;

– the hoPreparationIndication IE set to "false", to indicate that there is no handover preparation in progress anymore.

2. Same as step 2 of Figure 5.2.2.8.2-1, with the following modifications.

5.2.2.8.2.18 EPS Bearer ID revocation

When the AMF decides to revoke some EBI(s) and the I-SMF or V-SMF receives the request from AMF, the requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

The requestIndication shall be set to EBI_ASSIGNMENT_REQ.

The NF Service Consumer shall include the revokeEbiList IE to request the SMF to release some EBI(s). The SMF shall disassociate the EBI(s) with the QFI(s) with which they are associated.

5.2.2.8.2.19 Network requested PDU session release

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the requestIndication set to NW_REQ_PDU_SES_REL.

5.2.2.8.2.20 N2 Handover Execution with or without I-SMF or V-SMF Change

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall contain:

– the qosFlowsRelNotifyList IE indicating the failed QoS flow(s), if one or more QoS flow(s) cannot be established at the target RAN.

For an N2 handover with an I-SMF or V-SMF change, the requirements specified in step 1 of clause 5.2.2.8.2.10, other than how to set the requestIndication, shall also apply.

2. Same as step 2 of Figure 5.2.2.8.2-1, with the following modifications.

For an N2 handover with an I-SMF or V-SMF change, the requirements specified in step 2 of clause 5.2.2.8.2.10 shall also apply.

5.2.2.8.2.21 Void

5.2.2.8.2.22 Void

5.2.2.8.2.23 Service Request without I-SMF/V-SMF Change or with I-SMF/V-SMF Change or with I-SMF Insertion

During a Service Request without I-SMF/V-SMF Change or with I-SMF/V-SMF Change or with I-SMF Insertion, the NF Service Consumer (i.e. the V-SMF for a HR PDU session, or the I-SMF for a PDU session with an I-SMF) shall update the PDU session in the H-SMF or SMF as follows:

Figure 5.2.2.8.2.23-1: PDU session update towards H-SMF or SMF during Service Request

The requirements specified in clause 5.2.2.8.2.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall additionally contain:

– the upCnxState IE set to ACTIVATING if the User Plane resource for the PDU Session is going to be established by the I-SMF/V-SMF.

2a. Same as step 2a of Figure 5.2.2.8.2-1, with the following modifications.

The SMF shall behave as specified in clause as specified in clause 4.23.4.2 (step 7a) and clause 4.23.4.3 (step 8a) of 3GPP TS 23.502 [3].

2b. Same as step 2b of Figure 5.2.2.8.2-1.

3. Same as step 1 of Figure 5.2.2.8.2-1, with the following modifications.

The POST request shall additionally contain:

– the upCnxState IE set to ACTIVATED when User Plane resource has been established, if the upCnxState IE with the value ACTIVATING was previously provided to the SMF in the procedure, via a previous Update operation (step 1) or via Create operation for I-SMF/V-SMF insertion (see clause 5.2.2.7.6).

4a. Same as step 2a of Figure 5.2.2.8.2-1, with the following modifications.

The SMF shall behave as specified in clause as specified in clause 4.23.4.2 (step 16) and clause 4.23.4.3 (step 20a) of 3GPP TS 23.502 [3].

4b. Same as step 2b of Figure 5.2.2.8.2-1.

NOTE: The upCnxState IE set to ACTIVATING or ACTIVATED implements the "Operation Type" parameter set to "UP Activate" or "UP Activated" (respectively) specified in clause 4.23.4.2 (step 7a, 16) and clause 4.23.4.3 (step 8a, 20a) in 3GPP TS 23.502 [3].

5.2.2.8.3 Update service operation towards V-SMF or I-SMF

5.2.2.8.3.1 General

The NF Service Consumer (i.e. the H-SMF for a HR PDU session, or the SMF for a PDU session with an I-SMF) shall update a PDU session in the V-SMF or I-SMF and/or provide information necessary for the V-SMF or I-SMF to send N1 SM signalling to the UE, or request to allocate or revoke EPS Bearer ID(s) for the PDU session, by using the HTTP "modify" custom operation as shown in Figure 5.2.2.8.3.1-1.

Figure 5.2.2.8.3.1-1: PDU session update towards V-SMF or I-SMF

1. The NF Service Consumer shall send a POST request to the resource representing the individual PDU session resource in the V-SMF or I-SMF. The payload body of the POST request shall contain:

– the requestIndication IE indicating the request type, which is set to NW_REQ_PDU_SES_MOD;

– the modification instructions and/or the information necessary for the V-SMF or I-SMF to send N1 SM signalling to the UE;

– the hsmfPduSessionUri IE or smfPduSessionUri IE if the Update Request is sent to the V-SMF or I-SMF before the Create Response, and the H-SMF or SMF PDU session resource URI has not been previously provided to the V-SMF or I-SMF; in this case, the supportedFeatures IE shall also be included if at least one optional feature defined in clause 6.1.8 is supported.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.7.4.2.2-1 shall be returned. For a 4xx/5xx response, the message body shall contain a VsmfUpdateError structure, including:

– a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.7.4.2.2-1;

– the n1SmCause IE with the 5GSM cause returned by the UE, if available;

– n1SmInfoFromUe and/or unknownN1SmInfo binary data, if NAS SM information has been received from the UE that needs to be transferred to the H-SMF or SMF, or that the V-SMF or I-SMF does not comprehend;

– the procedure transaction id received from the UE, if available.

5.2.2.8.3.2 Network (e.g. H-SMF, SMF) requested PDU session modification

The requirements specified in clause 5.2.2.8.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.3.1-1, with the following modifications.

The requestIndication shall be set to NW_REQ_PDU_SES_MOD.

As part of the modification instructions, the NF Service Consumer may request to modify QoS parameters applicable at the PDU session level (e.g. modify the authorized Session AMBR values) or at the QoS flow level (e.g. modify the MFBR of a particular QoS flow).

The NF Service Consumer may request to establish, modify and/or release QoS flows by including the qosFlowsAddModifyRequestList IE and/or the qosFlowsReleaseRequestList IE in the payload body.

The H-SMF or SMF may provide alternative QoS profiles for each GBR QoS flow with Notification control enabled, to allow the NG-RAN to accept the setup of the QoS flow if the requested QoS parameters or at least one of the alternative QoS parameters sets can be fulfilled at the time of setup. If the H-SMF or SMF provides a new list of alternative QoS profile(s) for a given GBR Qos flow, the V-SMF or I-SMF shall replace any previously stored list for this Qos flow with it.

The NF Service Consumer may include epsBearerInfo IE(s), if the PDU session may be moved to EPS during its lifetime and the EPS Bearer(s) information has changed (e.g. a new EBI has been assigned or the mapped EPS bearer QoS for an existing EBI has changed).

The NF Service Consumer may include the modifiedEbiList IE if the PDU session modification procedure resulted in the change of ARP for a QoS flow that has already been allocated an EBI.

The NF Service Consumer may include the revokeEbiList IE to request the V-SMF or I-SMF to release some EBI(s) and delete any corresponding EPS bearer context stored in the V-SMF or I-SMF. The V-SMF or I-SMF shall disassociate the EBI(s) with the QFI(s) with which they are associated.

2. Same as step 2 of Figure 5.2.2.8.3.1-1, with the following modifications.

The V-SMF or I-SMF may accept all or only a subset of the QoS flows requested to be created or modified within the request.

The list of QoS flows which have been successfully setup or modified, and those which failed to be so, if any, shall be included in the qosFlowsAddModList IE and/or the qosFlowsFailedtoAddModList IE respectively.

The V-SMF or I-SMF may report an alternative QoS profile which the NG-RAN currently fulfils in the currentQosProfileIndex IE of the corresponding Qos flow in the qosFlowsAddModList IE, or report that the NG-RAN cannot even fulfil the lowest alternative QoS profile by setting the nullQoSProfileIndex IE to "true" for the corresponding Qos flow in the qosFlowsAddModList IE.

If the NG-RAN rejects the establishment of a voice QoS flow due to EPS Fallback for IMS voice (see clause 4.13 of 3GPP TS 23.502 [3]), the V-SMF or I-SMF shall return the cause indicating that "mobility due to EPS fallback for IMS voice is on-going" for the corresponding flow in the qosFlowsFailedtoAddModifyList IE.

The list of QoS flows which have been successfully released, and those which failed to be so, if any, shall be included in the qosFlowsReleaseList and/or qosFlowsFailedtoReleaseList IE respectively.

For a QoS flow which failed to be modified, the V-SMF or I-SMF shall fall back to the configuration of the QoS flow as it was configured prior to the reception of the PDU session update request from the NF Service Consumer.

The V-SMF or I-SMF shall store any EPS bearer information received from the H-SMF or SMF. If the revokeEbiList IE is present in the request, the V-SMF or I-SMF shall request delete the corresponding EPS bearer contexts and request the AMF to release the EBIs listed in this IE. If the modifiedEbiList IE is present in the request, the V-SMF or I-SMF shall request the AMF to update the mapping of EBI and ARP.

If the request received from the H-SMF or SMF contains the alwaysOnGranted attribute set to true, the V-SMF or I-SMF shall check and determine whether the PDU session can be established as an always-on PDU session based on local policy.

5.2.2.8.3.3 Network (e.g. H-SMF, SMF) or UE requested PDU session release

The requirements specified in clause 5.2.2.8.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.3.1-1, with the following modifications.

The requestIndication shall be set to NW_REQ_PDU_SES_REL or UE_REQ_PDU_SES_REL for a Network requested PDU session release or UE requested PDU session release respectively.

2. Same as step 2 of Figure 5.2.2.8.3.1-1, with the following modifications.

If the requestIndication in the request is set to NW_REQ_PDU_SES_REL or UE_REQ_PDU_SES_REL, the V-SMF or I-SMF shall initiate the release of RAN resources allocated for the PDU session if any and shall send a PDU session release command to the UE.

The V-SMF or I-SMF shall not release the SM context for the PDU session.

NOTE: The SM context will be released when receiving Status notification from the H-SMF or SMF indicating the PDU session is released in the H-SMF or SMF.

5.2.2.8.3.4 Handover between 3GPP and untrusted non-3GPP access, from 5GC-N3IWF to EPS or from 5GS to EPC/ePDG

The requirements specified in clause 5.2.2.8.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.3.1-1, with the following modifications.

The NF Service Consumer shall request the source V-SMF or I-SMF to release the resources in the VPLMN without sending a PDU session release command to the UE, by setting the requestIndication IE to NW_REQ_PDU_SES_REL and the Cause IE indicating "Release due to Handover", in the following scenarios:

– Handover of a PDU session between 3GPP and untrusted non-3GPP access, when the UE is roaming and the selected N3IWF is in the HPLMN (see clause 4.9.2.4.2 of 3GPP TS 23.502 [3]);

– Handover from 5GC-N3IWF to EPS (see clause 4.11.3.2 of 3GPP TS 23.502 [3]);

– Handover from 5GS to EPC/ePDG (see clause 4.11.4.2 of 3GPP TS 23.502 [3]).

2. Same as step 2 of Figure 5.2.2.8.3.1-1, with the following modifications.

If the requestIndication in the request is set to NW_REQ_PDU_SES_REL and if the Cause IE indicates "Release due to Handover", the V-SMF or I-SMF shall initiate the release of RAN resources reserved for the PDU session if any but shall not send a PDU session release command to the UE.

The V-SMF or I-SMF shall not release the SM context for the PDU session.

NOTE: The SM context will be released when receiving Status notification from the H-SMF or SMF indicating the PDU session is released in the H-SMF or SMF.

5.2.2.8.3.5 EPS Bearer ID assignment

The requirements specified in clause 5.2.2.8.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.3.1-1, with the following modifications.

The requestIndication shall be set to EBI_ASSIGNMENT_REQ.

The NF Service Consumer may include the assignEbiList IE to request the allocation of EBI(s). The NF Service Consumer may include the revokeEbiList IE to request the V-SMF or I-SMF to release some EBI(s) and delete any corresponding EPS bearer context stored in the V-SMF or I-SMF. The V-SMF or I-SMF shall disassociate the EBI(s) with the QFI(s) with which they are associated.

NOTE: The SMF does not request EBI allocation when MA PDU Session is established only over non-3GPP access. For MA PDU Session with both 3GPP and non-3GPP accesses, the SMF does not allocate EBI(s) for GBR QoS Flow(s) that are only allowed over non-3GPP access.

Upon receipt of this request, the V-SMF or I-SMF shall request the AMF to assign (and release if required) EBIs (see clause 5.2.2.6 of 3GPP TS 29.518 [20].

2a. Same as step 2a of Figure 5.2.2.8.3.1-1, with the following modifications.

If the AMF has successfully assigned all or part of the requested EBIs, the V-SMF or I-SMF shall respond with the status code 200 OK, and include the list of EBIs successfully allocated, those which failed to be so if any, and the list of EBIs released for this PDU session at AMF if any, in the assignedEbiList IE, the failedtoAssignEbiList IE and/or the releasedEbiList IE respectively.

2b. Same as step 2b of Figure 5.2.2.8.3.1-1, with the following modifications.

For a 4xx/5xx response, the message body shall contain a VsmfUpdateError structure, including the list of EBIs which failed to be allocated in the failedtoAssignEbiList IE.

5.2.2.8.3.6 Addition of PSA and BP or UL CL controlled by I-SMF

The requirements specified in clause 5.2.2.8.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.3.1-1, with the following modifications.

The requestIndication shall be set to NW_REQ_PDU_SES_MOD.

The payload body of the POST response shall contain:

– N4 information for the handling of the local traffic that is offloaded at the PSA (see Annex D of 3GPP TS 29.244 [29]);

– the DNAI related to N4 information targeting the local PSA;

– the indication that the DNAI shall not change, if applicable;

– the indication that the local PSA shall not change, if applicable.

2a. Same as step 2a of Figure 5.2.2.8.3.1-1, with the following modifications.

The payload body of the POST response shall contain:

– N4 response information;

– the DNAI related to the N4 information if the latter relates to a local PSA.

2b. Same as step 2b of Figure 5.2.2.8.3.1-1, with the following modifications.

For a 4xx/5xx response, the message body shall contain a VsmfUpdateError structure, including N4 response information if available (e.g. PFCP Session Establishment Response with a rejection cause).

5.2.2.8.3.7 Removal of PSA and BP or UL CL controlled by I-SMF

The requirements specified in clause 5.2.2.8.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.3.1-1, with the following modifications.

The requestIndication shall be set to NW_REQ_PDU_SES_MOD.

The payload body of the POST response shall contain:

– N4 information for the removal of the local offload rules at the UL CL/BP and PSA (see Annex D of 3GPP TS 29.244 [29]);

– the DNAI related to N4 information targeting the local PSA.

2a. Same as step 2a of Figure 5.2.2.8.3.1-1, with the following modifications.

The payload body of the POST response shall contain:

– N4 response information;

– the DNAI related to the N4 information if the latter relates to a local PSA.

2b. Same as step 2b of Figure 5.2.2.8.3.1-1, with the following modifications.

For a 4xx/5xx response, the message body shall contain a VsmfUpdateError structure, including N4 response information if available (e.g. PFCP Session Deletion Response with a rejection cause).

5.2.2.8.3.8 Change of PSA for IPv6 multi-homing or UL CL controlled by I-SMF

The requirements specified in clause 5.2.2.8.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.3.1-1, with the following modifications.

The requestIndication shall be set to NW_REQ_PDU_SES_MOD.

The payload body of the POST response shall contain:

– N4 information for the removal of the local offload rules at the removed PSA (see Annex D of 3GPP TS 29.244 [29]);

– N4 information for the handling of the local traffic that is offloaded at the inserted PSA (see Annex D of 3GPP TS 29.244 [29]);

– the DNAIs related to N4 information targeting the removed or inserted PSA.

2a. Same as step 2a of Figure 5.2.2.8.3.1-1, with the following modifications.

The payload body of the POST response shall contain:

– N4 response information;

– the DNAI related to the N4 information if the latter relates to a local PSA.

2b. Same as step 2b of Figure 5.2.2.8.3.1-1, with the following modifications.

For a 4xx/5xx response, the message body shall contain a VsmfUpdateError structure, including N4 response information if available (e.g. PFCP Session Establishment Response with a rejection cause).

5.2.2.8.3.9 Policy update procedures with an I-SMF

The requirements specified in clause 5.2.2.8.3.1 shall apply with the following modifications.

1. Same as step 1 of Figure 5.2.2.8.3.1-1, with the following modifications.

The requestIndication shall be set to NW_REQ_PDU_SES_MOD.

The payload body of the POST response may contain:

– N4 information updating local offload rules at the I-SMF (see Annex D of 3GPP TS 29.244 [29]);

– the DNAI related to the N4 information if the latter relates to a local PSA;

– an updated list of DNAI(s) of interest for the PDU Session.

2a. Same as step 2a of Figure 5.2.2.8.3.1-1, with the following modifications.

The payload body of the POST response shall contain:

– N4 response information, if N4 information was received in the request;

– the DNAI related to the N4 information if the latter relates to a local PSA.

2b. Same as step 2b of Figure 5.2.2.8.3.1-1, with the following modifications.

For a 4xx/5xx response, the message body shall contain a VsmfUpdateError structure, including N4 response information if available (e.g. PFCP Session Modification Response with a rejection cause).

5.2.2.9 Release service operation

5.2.2.9.1 General

The Release service operation shall be used to request an immediate and unconditional deletion of an invidual PDU session resource in the SMF (i.e. in the H-SMF for a HR PDU session, or in the SMF for a PDU session with an I-SMF).

It is invoked by the NF Service Consumer (i.e. V-SMF or I-SMF) in the following procedures:

– UE initiated Deregistration (see clause 4.2.2.3.2 of 3GPP TS 23.502 [3]);

– Network initiated Deregistration (see clause 4.2.2.3.2 of 3GPP TS 23.502 [3]), e.g. AMF initiated deregistration;

– visited network requested PDU Session release (see clause 4.3.4.3 of 3GPP TS 23.502 [3]), e.g. AMF initiated release in the following cases:

– when there is a mismatch of the PDU session status between the UE and the AMF; or

– when a network slice is no longer available.

– PDU session release procedure, for a PDU session with an I-SMF (see clause 4.23.5.2 of 3GPP TS 23.502 [3]);

– 5G-SRVCC from NG-RAN to 3GPP UTRAN procedure (see clause 6.5.4 of 3GPP TS 23.216 [35]).

The SMF shall release the PDU session context without triggering any signalling towards the 5G-AN and the UE.

The NF Service Consumer shall release a PDU session in the SMF by using the HTTP "release" custom operation as shown in Figure 5.2.2.9.1-1.

Figure 5.2.2.9.1-1: Pdu session release

1. The NF Service Consumer shall send a POST request to the resource representing the individual PDU session resource in the SMF. The payload body of the POST request shall contain any data that needs to be passed to the SMF.

If an UL CL/BP was inserted in the data path of the PDU session and traffic usage measurements need to be reported to the SMF, the POST request shall contain:

– N4 information related with traffic usage reporting (i.e. PFCP Session Report Request, see Annex D of 3GPP TS 29.244 [29]);

– the DNAI related to the N4 information if the latter relates to a local PSA.

2a. On success, the SMF shall return a "200 OK" with message body containing the representation of the ReleasedData when information needs to be returned to the NF Service Consumer, or a "204 No Content" response with an empty payload body in the POST response.

If N4 information was received in the request, the POST response shall contain:

– N4 response information (i.e. PFCP Session Report Response);

– the DNAI related to the N4 information if the latter relates to a local PSA.

If the request body contains the "cause" attribute with the value "REL_DUE_TO_PS_TO_CS_HO", the (H-) SMF shall indicate to the PCF within SM Policy Association termination that the PDU session is released due to 5G-SRVCC.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.6.4.3.2-2 shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.1.3.6.4.3.2-2.

5.2.2.10 Notify Status service operation

5.2.2.10.1 General

The Notify Status service operation shall be used to notify the NF Service Consumer about status changes of a PDU session (e.g. when the PDU session is released and the release is not triggered by a Release Request, when the PDU session is moved to another system, or when the control of the PDU session is taken over by another anchor SMF), for a HR PDU session or a PDU session involving an I-SMF.

It is used in the following procedures:

– Home network requested PDU Session release (see clause 4.3.4.3 of 3GPP TS 23.502 [3]), e.g. H-SMF initiated release;

– SMF requested PDU session release, for a PDU session involving an I-SMF (see clause 4.23 of 3GPP TS 23.502 [3]);

– Handover of a PDU Session procedure from 3GPP to untrusted non-3GPP access (see clauses 4.9.2.4.2 and 4.23.16.2 of 3GPP TS 23.502 [3]);

– Interworking procedures without N26 interface, e.g. 5GS to EPS Mobility (see clause 4.11.2.2 of 3GPP TS 23.502 [3]);

– Handover from 5GC-N3IWF to EPS (see clause 4.11.3.2 of 3GPP TS 23.502 [3]);

– Handover from 5GS to EPC/ePDG (see clause 4.11.4.2 of 3GPP TS 23.502 [3]);

– The control of PDU session is taken over by a new anchor SMF within the same SMF set (see clause 5.22 of 3GPP TS 29.244 [29]), and the new SMF instance decides to notify the change of SMF.

The SMF (i.e. H-SMF for a HR PDU session, or SMF for a PDU session involving an I-SMF) shall notify the NF Service Consumer (i.e. V-SMF for a HR PDU session, or I-SMF for a PDU session involving an I-SMF) by using the HTTP POST method as shown in Figure 5.2.2.10-1.

Figure 5.2.2.10-1: PDU session status notification

1. The SMF shall send a POST request to the resource representing the individual PDU session resource in the NF Service Consumer. The payload body of the POST request shall contain the notification payload, with the status information.

If the notification is triggered by PDU session handover to release resources of the PDU Session in the source access, the notification payload shall contain the resourceStatus IE with the value "RELEASED" and the Cause IE with value "PDU_SESSION_HANDED_OVER" as specified in clause 4.2.9.4.2 of 3GPP TS 23.501 [2].

If the notification is triggered by PDU session handover to release resources of the PDU Session in the target access due to handover failure between 3GPP access and non-3GPP access, the notification payload shall contain the resourceStatus IE with the value "RELEASED" and the Cause IE with the value "PDU_SESSION_HAND_OVER_FAILURE".

If the NF Service Consumer indicated support of the HOFAIL feature (see clause 6.1.8) and if the notification is triggered by PDU session handover to update access type of the PDU Session due to handover failure between 3GPP access and non-3GPP access, the notification payload shall contain the resourceStatus IE with the value "UPDATED", the anType IE with the value "3GPP" or "NON_3GPP" indicating the access type of the PDU session after the handover failure scenario and the Cause IE with the value "PDU_SESSION_HAND_OVER_FAILURE".

If upon a change of anchor SMF, the new anchor SMF instance decides to notify the change of anchor SMF, then the notification payload shall contain the resourceStatus IE with the value "UPDATED" and the Cause IE with the value "CHANGED_ANCHOR_SMF". In addition, the new anchor SMF instance shall include its SMF Instance ID in the notification payload, and/or carry an updated binding indication in the HTTP headers to indicate the change of anchor SMF (as per step 6 of clause 6.5.3.3 of 3GPP TS 29.500 [4]). If the PDU session may be moved to EPS with N26 and the EPS PDN Connection Context information of the PDU session on the new anchor SMF is different from the one on the old anchor SMF, the payload shall also include the "epsPdnCnxInfo" IE including the updated EPS PDN Connection Context information. The NF Service consumer shall overwrite the locally stored EPS PDN Connection Context information with the new one if received.

2a. On success, "204 No Content" shall be returned and the payload body of the POST response shall be empty.

If the SMF indicated in the request that the PDU session in the SMF is released, the NF Service Consumer shall release the SM context for the PDU session.

If the SMF indicated in the request that the SM context resource is updated with the anType IE, the NF Service Consumer shall change the access type of the PDU session with the value of anType IE.

5.2.2.11 Send MO Data service operation

5.2.2.11.1 General

The Send MO Data service operation shall be used to send mobile originated data received over NAS, for a given PDU session, towards the SMF, or the V-SMF for HR roaming scenarios, or the I-SMF for a PDU session with an I-SMF.

It is used in the following procedures:

– UPF anchored Mobile Originated Data Transport in Control Plane CIoT 5GS Optimisation (see clause 4.24.1 of 3GPP TS 23.502 [3]);

– NEF anchored Mobile Originated Data Transport (see clause 4.25.4 of 3GPP TS 23.502 [3]).

The NF Service Consumer (e.g. AMF) shall send mobile originated data to the SMF by using the HTTP POST method (send-mo-data custom operation) as shown in Figure 5.2.2.11.1-1.

Figure 5.2.2.11.1-1: Send MO Data

The request body may include the "MO Exception Data Counter", which indicates that the UE has accessed the network by using "MO exception data" RRC establishment, if Small Data Rate Control is enabled for the PDU session and the UE is accessing via the NB-IoT RAT.

2a. On success, "204 No Content" shall be returned.

For UPF anchored Mobile Originated Data Transport in Control Plane CIoT 5GS Optimisation, if the "MO Exception Data Counter" is included in the request then:

– for HR PDU session, the V-SMF shall update the H-SMF (see clause 5.2.2.8.2.2;

– for PDU session with I-SMF, the I-SMF shall update the SMF (see clause 5.2.2.8.2.2.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.3.2-3 shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails, with the "cause" attribute indicating the cause of the failure.

5.2.2.12 Transfer MO Data service operation

5.2.2.12.1 General

The Transfer MO Data service operation shall be used to transfer NEF anchored mobile originated data received from AMF, for a given PDU session, towards the H-SMF for HR roaming scenarios, or the SMF for a PDU session with an I-SMF.

It is used in the following procedures:

– NEF anchored Mobile Originated Data Transport (see clause 4.25.4 of 3GPP TS 23.502 [3]).

The NF Service Consumer (e.g. V-SMF or I-SMF) shall transfer NEF anchored mobile originated data to the SMF by using the HTTP POST method (transfer-mo-data custom operation) as shown in Figure 5.2.2.12.1-1.

Figure 5.2.2.12.1-1: Transfer MO Data

1. The NF Service Consumer shall send a POST request to the URI of Transfer MO Data custom operation on an individual PDU Session resource in the SMF. The payload body of the POST request shall contain the mobile originated data to be transferred.

The payload body shall also contain the MO Exception Data Counter, if received from AMF.

2a. On success, "204 No Content" shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.6.4.4.2-2 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails, with the "cause" attribute indicating the cause of the failure.

5.2.2.13 Transfer MT Data service operation

5.2.2.13.1 General

The Transfer MT Data service operation shall be used to transfer NEF anchored mobile terminated data received from NEF, for a given PDU session, towards the V-SMF for HR roaming scenarios, or the I-SMF for a PDU session with an I-SMF.

It is used in the following procedures:

– NEF anchored Mobile Terminated Data Transport (see clause 4.25.5 of 3GPP TS 23.502 [3]).

The NF Service Consumer (e.g. H-SMF or SMF) shall transfer NEF anchored mobile terminated data to the SMF by using the HTTP POST method (transfer-mt-data custom operation) as shown in Figure 5.2.2.13.1-1.

Figure 5.2.2.13.1-1: Transfer MT Data

1. The NF Service Consumer shall send a POST request to the URI of Transfer MT Data custom operation on an individual PDU Session resource in the SMF. The payload body of the POST request shall contain the mobile terminated data to be transferred.

The SMF shall forward the mobile terminated data to AMF. If SMF determines Extended Buffering is allowed by local policy and the NEF supports Extended Buffering, the SMF indicate the Extending Buffering support to AMF.

If AMF responds that it is attempting to reach the UE, the SMF shall wait for potential failure notification from AMF before responding to the NF consumer.

2a. On success, "204 No Content" shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.7.4.3.2-2 shall be returned. For a 4xx/5xx response, the message body may contain a TransferMtDataError or ProblemDetails object, with the "cause" attribute indicating the cause of the failure. If Estimated Maximum Waiting Time is received from AMF, the SMF shall include it in the message body.

5.2.2.14 Retrieve service operation

5.2.2.14.1 General

The Retrieve service operation shall be used to retrieve information from a PDU session context from the H-SMF for a HR PDU session, or from the SMF for a PDU session with an I-SMF.

It is used in the following procedures:

– 5GS to EPS handover using N26 interface and 5GS to EPS Idle mode mobility using N26 interface (see clauses 4.11.1.2.1 and 4.11.1.2.3 of 3GPP TS 23.502 [3]), for PDU sessions associated with 3GPP access and for which small data rate control is applicable.

The NF Service Consumer (e.g. V-SMF or I-SMF) shall retrieve information from a PDU session context by using the HTTP POST method (retrieve custom operation) as shown in Figure 5.2.2.14.1-1.

Figure 5.2.2.14.1-1: Retrieval of information from a PDU session context

1. The NF Service Consumer shall send a POST request to the resource representing the individual PDU session context for which information needs to be retrieved. The POST request may contain a payload body with the following parameters:

– smallDataRateStatusReq set to "true" to indicate a request to retrieve the small data rate control status of the PDU session, if small data rate control is applicable on the PDU session.

2a. On success, "200 OK" shall be returned and the payload body of the POST response shall contain the small data rate control status if this is a request for retrieving the small data rate control status.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.6.4.5.2-2 shall be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.6.4.5.2-2.