Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 29.502  Word version:  18.6.0

Top   Top   Up   Prev   Next

 

5.2.2.9  Release service operationp. 88

5.2.2.9.1  Generalp. 88
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:
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.
Reproduction of 3GPP TS 29.502, Fig. 5.2.2.9.1-1: Pdu session release
Up
Step 1.
The NF Service Consumer shall send a POST request to the resource representing the individual PDU session resource in the SMF. The content 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 TS 29.244);
  • the DNAI related to the N4 information if the latter relates to a local PSA.
If VPLMN QoS constraints are required for the PDU session and the H-SMF provides QoS parameters not complying with VPLMN QoS required by the V-SMF, the V-SMF may release the PDU session with the "cause" attribute set to "REL_DUE_TO_VPLMN_QOS_FAILURE".
Step 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 content 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.
  • Step 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.
    Up

    5.2.2.10  Notify Status service operationp. 89

    5.2.2.10.1  Generalp. 89
    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, or 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:
    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.
    Reproduction of 3GPP TS 29.502, Fig. 5.2.2.10-1: PDU session status notification
    Up
    Step 1.
    The SMF shall send a POST request to the resource representing the individual PDU session resource in the NF Service Consumer. The content of the POST request shall contain the notification content, 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 content 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 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 SMF for I-SMF selection or removal 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 as specified in clause 4.3.5.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 access type of the PDU Session due to 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 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 instance 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). 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 content 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.
    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".
    Step 2a.
    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 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.
    Step 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 errors listed in Table 6.1.3.7.3.1-2.
    Up

    5.2.2.11  Send MO Data service operation |R16|p. 91

    5.2.2.11.1  Generalp. 91
    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:
    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.
    Reproduction of 3GPP TS 29.502, Fig. 5.2.2.11.1-1: Send MO Data
    Up
    Step 1.
    The NF Service Consumer shall send a POST request to the resource representing the individual SM context resource in the SMF. The content of the POST request shall contain the mobile originated data to send.
    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.
    Step 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:
    Step 2b.
    On failure or redirection, one of the HTTP status codes listed in Table 6.1.3.3.4.5.2-2 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.
    Up

    5.2.2.12  Transfer MO Data service operation |R16|p. 92

    5.2.2.12.1  Generalp. 92
    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:
    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.
    Reproduction of 3GPP TS 29.502, Fig. 5.2.2.12.1-1: Transfer MO Data
    Up
    Step 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 content of the POST request shall contain the mobile originated data to be transferred.
    The content shall also contain the MO Exception Data Counter, if received from AMF.
    Step 2a.
    On success, "204 No Content" shall be returned.
    Step 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.
    Up

    5.2.2.13  Transfer MT Data service operation |R16|p. 92

    5.2.2.13.1  Generalp. 92
    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:
    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.
    Reproduction of 3GPP TS 29.502, Fig. 5.2.2.13.1-1: Transfer MT Data
    Up
    Step 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 content 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.
    Step 2a.
    On success, "204 No Content" shall be returned.
    Step 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.
    Up

    5.2.2.14  Retrieve service operation |R16|p. 93

    5.2.2.14.1  Generalp. 93
    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 TS 23.502), for PDU sessions associated with 3GPP access and for which small data rate control is applicable.
    • Change of SSC mode 3 PDU Session Anchor with multiple PDU Sessions (see clause 4.3.5.2 of TS 23.502).
    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.
    Reproduction of 3GPP TS 29.502, Fig. 5.2.2.14.1-1: Retrieval of information from a PDU session context
    Up
    Step 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 content 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.
    • pduSessionContextType indicates 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.
    Step 2a.
    On success, "200 OK" shall be returned and the content 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.
    Step 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.
    Up

    Up   Top   ToC