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 PDU session resource in the H-SMF or SMF. The content 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.

The NF service consumer shall not include the hoPreparationIndication IE with the value "false" in procedures other than handover execution, cancel and failure procedures. If the pending update information list was previously received from the (H-)SMF, the NF service consumer should not send a request to the (H-)SMF including only the information elements indicated by the pending update information list. The change(s) of the indicated information elements may be piggybacked in a subsequent update to the (H-)SMF together with other information elements. For a HR-SBO session, the content of the POST request may further contain:

• the hrsboInfo IE including the HR-SRO information sent from the VPLMN when the V-SMF requests HR SBO authorization.
• the ecsAddrConfigInfos IE including the ECS Address Configuration information if the information is modified by the NEF.

On success, "204 No Content" or "200 OK" shall be returned; in the latter case, the content of the POST response shall contain the representation describing the status of the request and/or information necessary for the NF Service Consumer to send N1 SM signalling to 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 content 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. 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, one of the HTTP status codes listed in Table 6.1.3.6.4.2.2-2 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 errors listed in Table 6.1.3.6.4.2.2-2;
• 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.

If the H-SMF or SMF receives the hoPreparationIndciation IE set to "false" value in step 1, while it did not receive the hoPreparationIndication IE set to "true" value in previous steps (see clauses 5.2.2.7.3 and 5.2.2.7.4), the H-SMF or SMF shall ignore the hoPreparationIndication IE with "false" value and proceed with the processing of the request.

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 TS 24.501, 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;
  • report the QoS flow(s) that are rejected by the RAN or rejected by the V-SMF, during PDU session establishment procedure; in the latter case, the V-SMF may also include the qosFlowsVsmfRejectedAddModList IE with the QoS flow(s) that are rejected by the V-SMF.

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.

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;
• one or more SecondaryRatUsageDataReportContainer(s) if it received the same in the SmContextUpdateData from the AMF.

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.

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.

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.

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.

Same as step 2a of Figure 5.2.2.8.2-1, with the following modifications. The content 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 content 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). 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).

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.