full Contents for &nbsp; TS 23.502 &nbsp; Word version: &nbsp; 16.4.0

Steps 1-7 and step 9 of clause 4.3.2.2.1 for UE-requested PDU Session Establishment Procedure for non-roaming scenarios or steps 1-9 of clause 4.3.2.2.2 for UE-requested PDU Session Establishment Procedure for home-routed roaming scenarios. The (H-)SMF receives the Session Management Subscription data for the corresponding SUPI, DNN and S-NSSAI that is associated with NEF Identity for NIDD and NIDD information such GPSI and AF ID.

If the subscription information corresponding to DNN and S-NSSAI includes the "NEF Identity for NIDD" (NEF ID), the SMF shall create a PDU session towards the NEF. The SMF invokes Nnef_SMContext_Create Request (User Identity, PDU session ID, SMF ID, NIDD information, S-NSSAI, DNN) message towards the NEF. The UE capability to support Reliable Data Service (RDS) is included in the PCO in the PDU Session Establishment Request message.

If no AF has previously performed the NIDD Configuration procedure with the NEF for the User Identity received in step 2, then the NEF initiates the NIDD Configuration procedure (see clause 4.25.3) before step 3.

Figure 4.25.3-1: NIDD Configuration procedure

The NEF creates an NEF PDU session Context and associates it with User Identity and PDU session ID. The NEF invokes Nnef_SMContext_Create Response (User Identity, PDU session ID, S-NSSAI, DNN) towards the SMF confirming establishment of the PDU session to the NEF for the UE. If NEF supports and allows use of RDS, it indicate that to SMF and the SMF includes it in the PCO. If NEF supports Extended Buffering, NEF includes Extended Buffering Support indication in the response and subscribes for mobility-related events with the AMF to receive an indication when the UE becomes reachable.

4.25.3 NIDD Configuration Word-p. 425

Figure 4.25.3-1 illustrates the procedure for configuring necessary information for data delivery via the NIDD API.

The NIDD Configuration procedure can be NEF initiated or AF triggered: in the former case the procedure starts at step 1, in the latter case it starts at step 2.

[Optional] If the NEF requires a NIDD configuration with a given AF, then the NEF sends a Nnef_NIDDConfiguration_TriggerNotify (GPSI, AF ID, NEF ID) message to the AF for asking the Nnef_NIDDConfiguration_Create Request for the UE identified by the GPSI.

The AF sends a Nnef_NIDDConfiguration_Create Request message (GPSI or External Group Identifier, AF ID, NIDD Duration, T8 Destination Address, Requested Action, TLTRI, Reliable Data Service Configuration, MTC Provider Information) to the NEF.

Reliable Data Service Configuration is an optional parameter that is used to configure the Reliable Data Service (as defined in the TS 23.501, clause 5.31.6) including port numbers for originator application(s) and receiver application(s). TLTRI is included in the request if the Requested Action is set to "Update" or "Cancel", otherwise TLTRI is not included in the request and the NEF assigns a TLTRI to the NIDD Configuration. If Reliable Data Service Configuration is present, the Reliable Data Service Configuration may include the mobile terminated and mobile originated serialization format(s) that are supported by the AF for each port number.

NOTE 1:

It is up to the AF to determine whether and if NIDD Duration can be set to never expire.

NOTE 2:

The AF is expected to be configured to use the same NEF as the one selected by the SMF during the UE's establishment of the PDU Session used for NEF based NIDD.

NOTE 3:

When more than one AF is associated with a PDU Session, the parameters that are provided in step 2 can be provisioned in the NEF based on operator policy or configuration. In which case, any parameters that are provided in step 2 that conflict with the provisioned values are ignored.

NOTE 4:

If the AF does not indicate a serialization format, it is assumed that the UE application is provisioned to know what serialization format will be used for MT traffic or that the AF will use the same format that is used by the associated MO traffic.

If the Requested Action is set to "Cancel" it indicates that the purpose of the request is to cancel the transaction identified by TLTRI and the flow proceeds to step 7. If the Requested Action is set to "Update", the purpose of the transaction is to update the parameters associated with the configuration (i.e. Reliable Data Service). Otherwise, the request is for a new NIDD configuration and the NEF stores the received GPSI or External Group Identifier, AF ID, T8 Destination Address, and NIDD Duration. If either the AF is not authorised to perform this request (e.g. based on policies, if the SLA does not allow for it) or the Nnef_NIDDConfiguration_Create Request is malformed, the NEF performs step 7 and provides a Cause value appropriately indicating the error. Depending on the configuration, the NEF may change the NIDD Duration.

The NEF sends an Nudm_NIDDAuthorisation_Get Request (GPSI or External Group Identifier, S-NSSAI, DNN, AF ID, MTC Provider Information) message to the UDM to authorise the NIDD configuration request for the received External Group Identifier or GPSI.

NOTE 5:

The NEF uses the AF ID, External Group Identifier or GPSI that was obtained in step 2 to determine what DNN will be used to enable transfer of unstructured data between the UE and the AF. This determination is based on local policies.

NOTE 6:

The MTC Provider Information in step 2 is an optional parameter. The NEF should validate the provided MTC Provider Information and may override it to a NEF selected MTC Provider Information based on configuration. How the NEF determines the MTC Provider Information, if not present in step 2, is left to implementation (e.g., based on the requesting AF).

Figure 4.25.4-1: NEF Anchored Mobile Originated Data Transport procedure

The UDM examines the Nudm_NIDDAuthorisation_Get Request message.

If the authorisation is successful and if an External Group Identifier was included in step 4, the UDM maps the External Group Identifier to an Internal-Group Identifier and a list of GPSIs and maps GPSIs to SUPIs and updates the NEF ID fields of the subscription data for the provided DNN and S-NSSAI with the requesting NEF's ID.

NOTE 7:

How the UDM selects a GPSI when multiple GPSIs are associated with the same SUPI is left to implementation, e.g., based on the MTC Provider Information (if received) or the default GPSI (if not received).

Step 6.

The UDM sends an Nudm_NIDDAuthorisation_Get Response (single value or list of (SUPI and GPSI), Result) message to the NEF to acknowledge acceptance of the Nudm_NIDDAuthorisation_Get Request. If the UDM determines that the list size exceeds the message capacity, the UDM shall segment the list and send it in multiple messages (for details on segmentation, see TS 29.503). The SUPI(s) and, if available, the GPSI(s) (when Nnef_NIDDConfiguration_Create Request contains an GPSI) are returned by the UDM in this response. This allows the NEF to correlate the AF request received in step 2 of this procedure with the SMF-NEF Connection to be established for each UE or each group member UE.

Step 7.

The NEF sends a Nnef_NIDDConfiguration_Create Response (TLTRI, Maximum Packet Size, Reliable Data Service Indication, and Cause) message to the AF to acknowledge acceptance of the Nnef_NIDDConfiguration_Create Request. If the NIDD Configuration was accepted, the NEF assigns a TLTRI to the NIDD Configuration and sends it to the AF. The NEF creates an association between the TLTRI, GPSI or External Group Identifier, SUPI, and PDU session ID which is received from the SMF in step 2 of the SMF-NEF Connection procedure in clause 4.25.1. In the MT NIDD procedure, the NEF will use TLTRI and either GPSI or External Group Identifier to determine the SUPI(s) and PDU session ID(s) of PDU Session(s) for delivering unstructured data. In the MO NIDD procedure, the NEF will use the SUPI(s) and PDU session ID(s) to obtain the TLTRI, GPSI. The Reliable Data Service Indication indicates if the Reliable Data Service is enabled in the NIDD configuration. The Maximum Packet Size is the maximum NIDD packet size.

4.25.4 NEF Anchored Mobile Originated Data Transport Word-p. 426

Figure 4.25.4-1 illustrates the NEF Anchored Mobile Originated Data Transport procedure.

The UE sends a NAS message with unstructured data according to steps 1-4 of the procedure for UPF anchored Mobile Originated Data Transport in Control Plane CIoT 5GS Optimisation (see clause 4.24.1). The Reliable Data Service header is included if the Reliable Data Service is enabled.

[Conditional] In the case of home-routed roaming the V-SMF forwards the data to the H-SMF.

The (H-)SMF sends the Nnef_SMContext_Delivery Request (User Identity, PDU session ID, unstructured data) message to the NEF.

The (H-)SMF may update all UPFs and NEFs which have PDU Session(s) using Small Data Rate Control with whether the RRC Connection was established for "MO exception data" or not for Small Data Rate Control purposes as described in TS 23.501, clause 5.31.14.3. If "MO exception data" is indicated in NIDD_Delivery_Request, the NEF shall consider all subsequent MO and MT data as "Exception Data".

When the NEF receives the unstructured data and finds an NEF PDU Session context and the related T8 Destination Address, then it sends the unstructured data to the AF that is identified by the T8 Destination address in a Nnef_NIDD_DeliveryNotify Request (GPSI, unstructured data, Reliable Data Service Configuration). If no T8 Destination address is associated with the UE's PDN connection, the data is discarded, the Nnef_NIDD_DeliveryNotify Request is not sent, and the flow continues at step 6. The Reliable Data Service Configuration is used to provide the AF with additional information such as indicate if an acknowledgement was requested and port numbers for originator application and receiver application, when the Reliable Data Service is enabled.

Editor's note: It is left to Stage 3 whether or not the NEF aggregates Nnef_NIDD_DeliveryNotify Request messages to the AF.

Figure 4.25.5-1: NEF Anchored Mobile Terminated Data Transport

The AF responds to the NEF with a Nnef_NIDD_DeliveryNotify Response (Cause).

Step 6.

The NEF sends Nnef_SMContext_Delivery Response to the SMF. If the NEF cannot deliver the data, e.g. due to missing AF configuration, the NEF sends an appropriate error code to the SMF.

4.25.5 NEF Anchored Mobile Terminated Data Transport Word-p. 427

Figure 4.25.5-1 illustrates the procedure using which the AF sends unstructured data to a given user as identified via External Identifier or MSISDN.

Step 1a.

If AF has already activated the NIDD service for a given UE and has downlink unstructured data to send to the UE, the AF sends a Nnef_NIDD_Delivery Request (GPSI, TLTRI, unstructured data, Reliable Data Service Configuration) message to the NEF. Reliable Data Service Configuration is an optional parameter that is used to configure the Reliable Data Service, it may be used to indicate if a Reliable Data Service acknowledgement is requested and port numbers for originator application and receiver application.

If NEF enforces Small Data Rate Control, it considers all MT data received after "MO exception data" indication as "Exception Data" until it receives non "MO exception data" indication.

Step 1b.

AMF indicates to NEF that the UE has become reachable. Based on this the NEF re-starts delivering buffered unstructured data to the UE.

The NEF determines the 5GS QoS Flow Context based on the DNN associated with the NIDD configuration and the User Identity. If an NEF 5GS QoS Flow Context corresponding to the GPSI included in step 1 is found, then the NEF checks if the AF is authorised to send data and if it does not exceed its quota or rate. If these checks fail, then steps 3-15 are skipped and an appropriate error code is returned in step 17.

The NEF forwards the unstructured data to the (H-)SMF using Nsmf_NIDD_Delivery Request. If NEF has indicated support of Extended Buffering in Nnef_SMContext_Create Response during SMF-NEF connection establishment, then NEF keeps a copy of the data.

In the roaming case, the H-SMF forwards the data to the V-SMF.

Figure 4.25.6-1: NIDD Authorization Update procedure

The (V-)SMF determines whether Extended Buffering applies based on local policy and based on whether NEF has indicated support of Extended Buffering in Nnef_SMContext_Create Response during SMF-NEF connection establishment. (V-)SMF compresses the header if header compression applies and forwards the data and the PDU session ID to the AMF using the Namf_Communication_N1N2MessageTransfer service operation. If Extended Buffering applies, then (V-SMF) includes "Extended Buffering support" indication in Namf_Communication_N1N2Message Transfer.

Step 6.

If AMF determines the UE is unreachable for the SMF (e.g., if the UE is in MICO mode or the UE is configured for extended idle mode DRX), then the AMF rejects the request from the SMF. The AMF may include in the reject message an indication that the SMF need not trigger the Namf_Communication_N1N2MessageTransfer Request to the AMF, if the SMF has not subscribed to the event of UE reachability.

If the SMF included Extended Buffering support indication, the AMF indicates the Estimated Maximum Wait time, in the reject message, for the SMF to determine the Extended Buffering time. If the UE is in MICO mode, the AMF determines the Estimated Maximum Wait time based on the next expected periodic registration timer update expiration or by implementation. If the UE is configured for extended idle mode DRX, the AMF determines the Estimated Maximum Wait time based on the start of next PagingTime Window. The AMF stores an indication that the SMF has been informed that the UE is unreachable.

Step 7.

In the roaming case V-SMF sends a failure indication to H-SMF. If the V-SMF receives an "Estimated Maximum Wait time" from the AMF and Extended Buffering applies, the V-SMF also passes the "Estimated Maximum Wait time" to the H-SMF.

Step 8.

If the (H-)SMF receives a failure indication, (H-)SMF also sends a failure indication to NEF. If (H-)SMF has received the "Estimated Maximum Wait time" and Extended Buffering applies, the (H-)SMF includes Extended Buffering time in the failure indication. The Extended Buffering time is determined by the (H-)SMF and should be larger or equal to the Estimated Maximum Wait time. The NEF stores the DL data for the Extended Buffering time. The NEF does not send any additional Nsmf_NIDD_Delivery Request message if subsequent downlink data packets are received. The procedures stop at this step.

Step 9.

If the AMF determines the UE to be reachable in Step 5, then Steps 3 to 6 of the UPF anchored Mobile Terminated Data Transport in Control Plane CIoT 5GS Optimisation procedure (clause 4.24.2) apply.

If the Reliable Data Service header indicates that the acknowledgement is requested, then the UE shall respond with an acknowledgement to the DL data that was received.

Step 10.

If the UE has not responded to paging, the AMF sends a failure notification to the (V-)SMF. Otherwise the procedure continues at step 13.

Step 11.

In the roaming case, if V-SMF has received a failure notification from AMF, then V-SMF passes the failure notification to H-SMF.

Step 12.

If (H-)SMF receives a failure notification, then SMF indicates to the NEF that the requested Nsmf_NIDD_Delivery has failed. If Extended Buffering applies, then NEF purges the copy of the data. The procedure continues at step 17.

Step 13.

Steps 9 to 11 of the UPF anchored Mobile Terminated Data Transport in Control Plane CIoT 5GS Optimisation procedure (clause 4.24.2) apply.

Step 14.

AMF informs (V-)SMF that data has been forwarded.

Step 15.

In the roaming case, V-SMF indicates to H-SMF that the data has been forwarded.

Step 16.

(H-)SMF indicates to NEF that the data has been forwarded. If Extended Buffering applies then NEF purges the copy of the data.

Step 17.

The NEF sends a Nnef_NIDD_Delivery Response (cause) to the AF.

The Reliable Data Service Acknowledgement Indication is used to indicate if an acknowledgement was received from the UE for the MT NIDD. If the Reliable Data Service was requested in step 1, then the Nnef_NIDD_Delivery Response is sent to the AF after the acknowledgement is received from the UE or, if no acknowledgment is received, then the Nnef_NIDD_Delivery Response is sent to the AF with a cause value indicating that no acknowledgement was received.

4.25.6 NIDD Authorization Update Word-p. 430

Figure 4.25.6-1 illustrates the procedure for updating or revoking an existing NIDD Authorization.

The UDM may initiate the NIDD Authorization Update procedure with the NEF to send updated Authorization information to the NEF.

The UDM may send an NIDD Authorization Update information using Nudm_NIDDAuthorisation_UpdateNotify Request (SUPI, GPSI, S-NSSAI, DNN, Result) message to the NEF to update an user's NIDD authorization.

The NEF sends Nudm_NIDDAuthorisation_UpdateNotify Response (cause) message to the UDM to acknowledge the authorization update.

If the authorization is removed, the NEF should initiate the SMF-NEF Connection release procedure as specified in the clause 4.25.8.

The NEF informs the AF that the user's authorisation status has changed by sending Nnef_NIDDConfiguration_UpdateNotify Request (GPSI, TLTRI, Result) message to the AF.

4.25.7 SMF Initiated SMF-NEF Connection Release procedure

The AF responds to the NEF with Nnef_NIDDConfiguration_UpdateNotify Response message.

When the PDU Session Release is initiated and if a NEF has been selected as anchor of the Control Plane CIoT 5GS Optimisation enabled PDU session which is Unstructured PDU Session Type as described in the clause 4.3.4.2, then the SMF initiates a SMF-NEF Connection Release procedure towards the NEF corresponding to the "NEF ID" for that DNN / S-NSSAI Combination.

Figure 4.25.7-1: SMF Initiated SMF-NEF Connection Release procedure

The SMF performs PDU Session Relese Procedure as described in clause 4.3.4.2.

If a NEF has been selected as anchor of the Control Plane CIoT 5GS Optimisation enabled PDU session which is Unstructured PDU Session Type as descrbied in clause 4.3.2.2, the SMF initiates the SMF-NEF Connection release for this PDU Session by sending Nnef_SMContext_Delete Request (User Identity, PDU session ID, S-NSSAI, DNN) message to the NEF.

Figure 4.25.8-1: NEF Initiated SMF-NEF Connection Release procedure on the AF request

The NEF deletes the NEF PDU session Context associated with the User Identity and the PDU session ID. The NEF sends Nnef_SMContext_Delete Response (User Identity, PDU session ID, S-NSSAI, DNN) to the SMF confirming release of the SMF-NEF session for the UE.

4.25.8 NEF Initiated SMF-NEF Connection Release procedure Word-p. 431

NEF initiates a SMF-NEF connection release procedure in the following cases:

when a NIDD Authorization Update Request from the UDM indicates that the User is no longer authorized for NIDD, or
failure of AF or failure of AF connection, or
based on a request from the AF.

Figure 4.25.8-1 illustrates the NEF Initiated SMF-NEF Connection Release procedure based on a request from AF.

AF may indicate that a User's NIDD SMF-NEF connection is no longer needed by invoking Nnef_NIDDConfiguration_Delete Request (TLTRI) toward NEF.

The NEF deletes the NEF PDU session Context associated with the TLTRI and acknowledges the deletion of the NIDD configuration by invoking Nnef_NIDDConfiguration_Delete Response to the AF.

The NEF notifies the deletion of the SM context information by invoking Nnef_SMContext_DeleteNotify Request toward the SMF.

The SMF acknowledges the notification by invoking Nnef_SMContext_DeleteNotify Response to the NEF.

Figure 4.25.8-2: NEF Initiated SMF-NEF Connection Release procedure on the NIDD Authorization Update

If the PDU session is not longer needed, the SMF performs steps 2-11 of PDU Session Relese Procedure (see clause 4.3.4.2).

Figure 4.25.8-2 illustrates the NEF Initiated SMF-NEF Connection Release procedure based on the NIDD Authorization Update.

On NIDD Authorization Update by UDM, NEF may determine that it needs to release the corresponding SMF-NEF Connection.

The NEF deletes the corresponding NEF PDU session Context and notifies the deletion of the SM context information by invoking Nnef_SMContext_DeleteNotify Request toward the SMF.

The SMF acknowledges the notification by invoking Nnef_SMContext_DeleteNotify Response to the NEF.

Figure 4.25.9-1: NEF Anchored Group NIDD via NEF anchored unicast data

If the PDU session is not longer needed, the SMF performs steps 2-11 of PDU Session Relese Procedure (see clause 4.3.4.2).

4.25.9 NEF Anchored Group NIDD via NEF anchored unicast MT data Word-p. 432

Figure 4.25.9-1 illustrates the procedure by which the AF can send a Group NIDD addressed to External Group Identifier. It is a pre-requisite assumption that the NEF has already resolved the mapping of External Group Identifier to individual SUPIs with the help of UDM during NIDD Configuration procedure as specified in clause 4.25.3. Standalone MT NIDD procedure specified in clause 4.25.5 is re-used by NEF to unicast the MT data to each UE.

If AF has already used the NIDD Configuration procedure of clause 4.25.3 to activate the NIDD service for a group of UEs and has unstructured data to send to the group identified by an External Group Identifier, the AF sends a Nnef_NIDD_Delivery Request (External Group Identifier, TLTRI, unstructured data, Reliable Data Service Configuration) message to the NEF. Reliable Data Service Configuration is an optional parameter that is used to configure the Reliable Data Service. When unstructured data is sent to an External Group Identifier, the AF shall not request acknowledgement in the Reliable Data Service Configuration.

Based on the existing NIDD configuration of the UE Group (see clause 4.25.3), the NEF sends a single Nnef_NIDD_Delivery Response to AF to acknowledge the acceptance of the Group NIDD delivery request in step 1.

The NEF uses the NEF anchored Mobile Terminated Data Transport procedure that is specified in steps 2-16 in clause 4.25.5 to send the same MT NIDD to each UE in the group.