Content for  TS 29.502  Word version:  18.5.0

The NF Service Consumer shall send a POST request to the resource representing the individual SM context to be deleted. The content 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".

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

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.

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 content of the POST request shall contain the notification content. If the notification is triggered by PDU session handover to release resources of the PDU session in the source access, the notification content 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 TS 23.502. 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 content 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 TS 23.502. 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 content 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 content 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 content 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 content 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 content 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 content shall contain the resourceStatus IE with the value "ALT_ANCHOR_SMF". The notification content 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 content 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 content, 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 TS 29.500). 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 content 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 content, 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 TS 29.500). 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 content 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. If the notification is triggered by SMF for I-SMF selection or removal or V-SMF selection for the current PDU session, or SMF selection during PDU Session re-establishment for SSC mode 2/3, the notification content shall contain the resourceStatus IE with the value "UNCHANGED", the Cause IE with the value "TARGET_DNAI_NOTIFICATION" and the targetDnaiInfo IE. The targetDnai IE in the targetDnaiInfo IE shall be absent if the I-SMF removal is triggered due to the DNAI currently served by the I-SMF being no longer used for the PDU Session. If the notification is triggered for SMF selection during PDU Session re-establishment for SSC mode 3, the notification content may also contain the oldPduSessionRef IE received from the SMF or the oldSmContextRef IE as specified in clause 4.3.5.2 of TS 23.502. If the notification is triggered by a PDU session release due to slice inactivity as specified in clause 5.15.15.3 of TS 23.501 and clause 5.11.2 of TS 29.244, the notification content shall contain the resourceStatus IE with the value "RELEASED" and the Cause IE with the value "REL_DUE_TO_SLICE_INACTIVITY".

On success, "204 No Content" shall be returned and the content 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.

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 TS 29.500), 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 TS 29.510 using the service name and GUAMI or backupAMFInfo obtained during the creation of the SM context, see clause 6.5.2.2 of TS 29.500), 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.

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 content 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 requiring UP integrity protection 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; or
  • indicating that this is a request to retrieve the AF Coordination Information as defined in clause 6.1.6.2.69, during the change of SSC mode 3 PDU Session Anchor with multiple PDU Sessions, if the runtime coordination between old SMF and AF is enabled.
• 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 or insertion. Or the serving core network operator PLMN ID of the new I-SMF during the procedure with an I-SMF insertion;
• 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, I-SMF selection/removal per DNAI or V-SMF selection per DNAI, when the UE is in CM-CONNECTED state as specified in clauses 5.2.2.2.7 and 5.2.2.2.12;
• hrsboSupportInd IE, if the procedure is triggered by a target V-SMF supporting the HR-SBO feature;
• storedOffloadIds IE, if the target V-SMF has a list of stored offload identifiers from the previous procedures for the HPLMN of the PDU session.

On success, "200 OK" shall be returned; the content 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, or the AF Coordination Information if this is a request for retrieving the AF Coordination Information. 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. During a procedure with an I-SMF or V-SMF insertion, the anchor SMF should use the servingNetwork IE received in the Retrieve SM Context Request to determine whether the inserted entity is an I-SMF or V-SMF, and if so, encode in the SM Context returned in the response the applicable set of attributes (e.g. hsmfUri, hSmfInstanceId, hSmfServiceInstanceId to a V-SMF, or smfUri, smfInstanceId, smfServiceInstanceId to an I-SMF) and the applicable URI in the pduSessionRef if different URIs are used for intra-PLMN and inter-PLMN signaling requests targeting the PDU session context. If the UE, target MME and AMF support User Plane integrity protection with EPS, the SMF shall include the UP Security Policy IE in the UE EPS PDN connection context if User Plane integrity protection has been enabled by the SMF as specified in clauses 4.11.1.2.1 and 4.11.1.3.2 of TS 23.502. 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. If the target V-SMF supports the HR-SBO feature, for a HR-SBO session, the content of the POST response message may also contain the HR-SBO related information, e.g., hrsboAuthResult, hDnsAddr, hPlmnAddr, vplmnOffloadingInfoList. The source V-SMF shall determine if the target V-SMF has already received the corresponding VPLMN Offloading Information for an offload identifier based on the storedOffloadIds for the HPLMN of the PDU session provided by the target V-SMF in the Retrieve SM context request message for an intra PLMN V-SMF change, the source V-SMF shall include:

• the Offload Identifier(s) only, if the Offload Identifier(s) are known by the target V-SMF, i.e., the Offload Identifier(s) are part of the storedOffloadIds; otherwise
• a list of vplmnOffloadingInfo attributes where each vplmnOffloadingInfo contains an offload identifier and the corresponding VPLMN Offloading Information.

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". If a request for the UE EPS PDN connection is rejected due to the target MME not being capable to support the PDU session, e.g. if the PDU session requires UP integrity protection but the target MME does not support User Plane Integrity Protection with EPS, the SMF shall return a 403 Forbidden response with the "cause" attribute in the ProblemDetails structure set to "TARGET_MME_CAPABILITY".

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

• a representation of the individual PDU session resource to be created;
• the requestType IE, if the Request type IE 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 requestType IE shall not be included for a MA-PDU session establishment request; it may be included otherwise;
• 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 the UE indicated so;
• 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 DL N9 tunnel CN 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 DL N9 tunnel CN 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 alternative S-NSSAI, if the NF service consumer and UE support the network slice replacement and it is requested to replace the S-NSSAI with the alternative S-NSSAI (see clause 5.15.19 of TS 23.501);
• 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;
• the upipSupported IE set to "true", if the UE supports User Plane Integrity Protection with EPS and if the AMF supports the related functionality.

The content of the POST request may further contain:

• the satelliteBackhaulCat IE indicating the category of the satellite backhaul used towards the 5G AN serving the UE, if the V-SMF/I-SMF received this information from the AMF;
• the disasterRoamingInd IE set to true during the PDU session establishment or a V-SMF insertion procedure when the V-SMF is indicated by the AMF that the UE is registered for Disaster Roaming service;
• the hrsboInfo IE including the HR-SBO information sent from the VPLMN when the V-SMF requests HR SBO authorization;
• the ecsAddrConfigInfos IE including the ECS Address Configuration information Parameters received from the NEF.

As specified in clause 4.3.2.2.2 of TS 23.502, 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 TS 23.502) or Secondary authorization/authentication (see clause 4.3.2.3 of TS 23.502).

On success, "201 Created" shall be returned, the content 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 hcnTunnelInfo IE or cnTunnelInfo IE with the UL N9 Tunnel CN information of the UPF controlled by the H-SMF or SMF respectively, expect for when Control Plane CIoT 5GS Optimisation is enabled and data delivery via NEF is selected for this PDU session.
• the additionalCnTunnelInfo IE with additional UL N9 tunnel CN information of the UPF controlled by the H-SMF or SMF if a MA-PDU session is established for a UE registered over both 3GPP access and Non-3GPP access.

The content of the POST response may further contain:

• the pending update information list, indicating the information elements whose change(s) are not required to be updated in real-time to the (H-)SMF, i.e. the change(s) of the indicated information elements may be piggybacked in a subsequent update to the (H-)SMF together with other information elements.

The content of the POST response may also contain the upSecurity, maxIntegrityProtectedDataRate 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 (carrying the PDU session resource URI of a HR PDU session or a PDU session with an I-SMF) of the SMF initiated Update Request shall be the same. If the requestType IE 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:

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

and either of the following conditions is met:

• this is a request to establish a non-emergency PDU session and the request includes the same SUPI and the same PDU Session ID as for an existing PDU session context; or
• this is a request to establish an emergency PDU session and the request includes the same SUPI, or PEI for an emergency registered UE without a UICC or without an authenticated SUPI, as for an existing PDU session context for an emergency PDU session.

A POST request that collides with an existing PDU session context shall be treated as a request for a new PDU session context. The SMF shall assign a new PDU session reference, i.e. {pduSessionRef} (see clause 6.1.3.6.2), which is different from the existing 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, PCF, CHF and UDM. 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. The SMF should include a cause IE with value "REL_DUE_TO_DUPLICATE_SESSION_ID" in such a status notification. Upon receipt of such a status notification, the V-SMF or I-SMF shall not send SM context status notification to the AMF. If the requestType IE 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 TS 23.502. For a HR-SBO session, the content of the POST response may also contain the hrsboInfo IE including the HR-SBO information sent from the HPLMN, e.g., hrsboAuthResult.

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

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

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.

If the epsBearerCtxStatus 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 TS 23.502.

Same as step 2b of Figure 5.2.2.7.1-1, with the following additions. 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".

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.

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;
• optional udmGroupId, containing the identity of the UDM group serving the UE, to facilitate the UDM selection at the target AMF. The V/I-SMF shall forward this IE in the SmContextCreatedData to the target AMF.
• optional pcfGroupId, containing the identity of the PCF group for Session Management Policy for the PDU session, to facilitate the PCF selection at the target AMF. The V/I-SMF shall forward this IE in the SmContextCreatedData to the target AMF.

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

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

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.

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.

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.

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 TS 33.501.

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.

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 of TS 23.502 (step 8a). 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.