Skip to content

7.1 Cellular IoT non-IP data delivery(NIDD)

7.1.1 SCEF-based NIDD

7.1.1.1 SCEF Configuration for NIDD

The 3GPP SCEF Non-IP Data Delivery (NIDD) functionality supports an API to allow the exchange of Non-IP data between an IN-CSE and an MN-CSE, ADN-AE, or ASN-CSE hosted on a UE. Via this SCEF NIDD API, an IN-CSE may exchange oneM2M request and response primitives with an MN-CSE, ADN-AE, or ASN-CSE hosted on a UE.

Note

The exchange of oneM2M primitives over the Mcn reference point via NIDD is an extension upon the capability defined within oneM2M TS-0001[1] and oneM2M TS-0004 [3] to exchange oneM2M primitives over the Mca and Mcc reference points. The same procedures defined by oneM2M TS-0001[1] and oneM2M TS-0004 [3] for exchanging oneM2M primitives over the Mca and Mcc are also applicable to Mcn via NIDD unless otherwise stated in this document.

The SCEF NIDD API supports an NIDD Configuration procedure that may be used by the IN-CSE to inform the SCEF that it expects Non-IP Data from a UE hosting an MN-CSE, ADN-AE, or ASN-CSE. Figure 7.1.1.1-1 illustrates this procedure. If the NIDD Configuration procedure is performed, the IN-CSE should perform the procedure before a UE attaches and attempts to establish a Non-IP PDN connection to the SCEF.

Figure 7.1.1.1-1: NIDD Configuration Request

Figure 7.1.1.1-1: NIDD Configuration Request

Pre-conditions:

The IN-CSE is configured with the M2M-Ext-ID of a UE and an indication that the ASN/MN-CSE or ADN-AE hosted on this UE uses NIDD to exchange oneM2M primitives with the IN-CSE. This information is configured in the nodeID and niddRequired attributes, respectively of the <serviceSubscribedNode> resource corresponding to the UE.

There is a relationship in place between the Service Provider and MNO allowing the IN-CSE to perform NIDD Configuration Requests to the underlying 3GPP network. The method for establishing this relationship is outside the scope of the present document.

Step 1: IN-CSE determines to issue NIDD Configuration Request

If the niddRequired attribute of a <serviceSubscribedNode> resource associated with a UE hosting an ASN/MN-CSE or ADN-AE is set to TRUE, then the IN-CSE shall issue a NIDD Configuration Request to the proper SCEF.

Step 2 (Optional) : DNS Query/Response

To determine which SCEF to contact, an IN-CSE may determine the IP address(es)/port(s) of the proper SCEF by performing a DNS query using the M2M-Ext-ID of the UE hosting the ASN/MN-CSE or ADN-AE. This M2M-Ext-ID shall be configured in the nodeID attribute of the <serviceSubscribedNode> resource associated with the UE. Alternatively, an IN-CSE may use a pre-configured SCEF identifier. The method for pre-configuring a SCEF identifier into the IN-CSE is outside the scope of the present document.

Step 3 : NIDD Configuration Request

The IN-CSE issues a NIDD Configuration Request for a particular ASN/MN-CSE or ADN-AE hosted on a UE. The request is configured as follows.

  • An HTTP POST method shall be used
  • URI shall be set to {apiRoot}/3gpp-nidd/v1/{scsAsId}/configurations/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
  • The request payload shall include a NiddConfiguration data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • externalId shall be set to the M2M-Ext-ID of the UE hosting the targeted ASN/MN-CSE or ADN-AE.
    • notificationDestination shall be set to a URI of the IN-CSE that the SCEF will deliver MO NIDD data to.
    • duration specifies the lifetime of the NIDD Configuration and shall be set per SLA between the Service Provider and MNO. The SCEF may change the NIDD duration value.
    • pdnEstablishmentOption may be used to indicate the IN-CSE's default preference for how the SCEF should process a MT NIDD Request from the IN-CSE if the UE has not yet established a Non-IP PDN connection to the SCEF. This value shall be set based on SLA with the MNO.
    • reliableDataService shall be set to TRUE or FALSE to indicate that the Reliable Data Service is enabled or disabled based on IN-CSE preferences.
    • rdsPorts shall be set to the source and destination ports used for MO and MT NIDD between the IN-CSE and the ASN/MN-CSE or ADN-AE hosted on the UE. This field shall be set if reliableDataService is set to TRUE.
    • supportedFeatures shall be set to a string value of "0" indicating no support for group message delivery over NIDD, NIDD notifications over Websocket, testing of NIDD notifications or MT_NIDD_modification_cancellation.
    • msisdn, requestTestNotification, websockNotifConfig and niddDownlinkDataTransfers are not supported by the present document and shall not be included.

Step 4: Process NIDD Configuration Request

The SCEF processes the request.

Step 5: NIDD Configuration Response

If the NIDD Configuration Request is successfully processed, the SCEF responds indicating the request was accepted. The message includes the following information.

  • A response code of 201 CREATED
  • The URI of the NIDD Configuration resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-nidd/v1/{scsAsId}/configurations/{configurationId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {configurationId} segment is configured by the SCEF.
  • The response payload will include a NiddConfiguration data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
    • maximumPacketSize is set to the maximum supported NIDD packet size that can be transferred to the UE by the SCEF. This value is configured by the SCEF per SLA with the MNO.
    • status is set to a value that indicates the NIDD configuration status (e.g. ACTIVE)
    • self is configured with a URI to the resource created by the SCEF for the request

If the response indicates that the request was accepted, the IN-CSE shall use the maximumPacketSize as a limit on the maximum size MT NIDD Request it shall initiate towards the corresponding UE specified in the NIDD Configuration Request.

If the NIDD Configuration Request results in an error, the IN-CSE shall not use NIDD for the corresponding UE until the error is resolved. See clause 8.3 for a list of possible error scenarios.

Step 6 (Optional) : NIDD Configuration Delete Request

If the IN-CSE detects that <serviceSubscribedNode> is deleted or the <serviceSubscribedNode> niddRequired attribute is updated to FALSE, then the IN-CSE shall issue a NIDD Configuration Delete Request for the UE. The request is configured as follows.

  • An HTTP DELETE method shall be used
  • URI shall be set to {apiRoot}/3gpp-nidd/v1/{scsAsId}/configurations/{configurationId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {configurationId} corresponds to the one configured by the SCEF and returned to the IN-CSE when the NIDD Configuration was created.
  • The request shall not contain a payload

Step 7 (Optional) : Process NIDD Configuration Delete Request

The SCEF processes the request.

Step 8 (Optional) : NIDD Configuration Delete Response

The SCEF responds with a 204 NO CONTENT that indicates the NIDD Configuration was cancelled.

7.1.1.2 SCEF-based Mobile Terminated NIDD

The SCEF API supports a Mobile Terminated (MT) NIDD procedure that may be used by the IN-CSE to send downlink non-IP data to a UE hosting an MN-CSE, ADN-AE, or ASN-CSE. Figure 7.1.1.2-1 illustrates this procedure.

Figure 7.1.1.2-1: SCEF-based Mobile Terminated NIDD

Figure 7.1.1.2-1: SCEF-based Mobile Terminated NIDD

Pre-conditions:

The NIDD Configuration procedure defined in clause 7.1.1.1 completes successfully.

Step 1 (Optional) : Application issues oneM2M Request Primitive

An AE (e.g. IN-AE) may issue a oneM2M request targeting a ASN/MN-CSE or ADN-AE.

Step 2: IN-CSE determines to issue a SCEF-based Mobile Terminated NIDD Downlink Data Transfer Request

The IN-CSE shall only issue a SCEF-based Mobile Terminated (MT) NIDD Downlink Data Transfer Request if the NIDD Configuration Request for the targeted ASN/MN-CSE or ADN-AE hosted on a UE was successful and the size of the oneM2M request primitive to be sent in the MT NIDD Request is less than or equal to the maximumPacketSize defined in the NIDD Configuration response.

Step 3 : MT NIDD Downlink Data Transfer Request

The IN-CSE issues a MT NIDD Downlink Data Transfer Request for a particular ASN/MN-CSE or ADN-AE hosted on a UE. The request is configured as follows.

  • An HTTP POST method shall be used
  • URI shall be set to {apiRoot}/3gpp-nidd/v1/{scsAsId}/configurations/{configurationId}/downlink-data-deliveries. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {configurationId} segment shall be configured with the {configurationId} returned by the SCEF when the NIDD Configuration was performed by the IN-CSE for this ASN/MN-CSE or ADN-AE.
  • The request payload shall include a NiddDownlinkDataTransfer data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • externalId shall be set to the M2M-Ext-ID of the UE hosting the targeted ASN/MN-CSE or ADN-AE.
    • maximumLatency may be set to indicate the maximum delay acceptable for MT data and used to configure the buffer duration in the underlying 3GPP network; a maximum latency of 0 indicates that buffering is not allowed. If maximum latency is not provided, the SCEF determines the acceptable delay based on local policies.
    • priority may be set to indicate the priority of the non-IP data packet relative to other non-IP data packets. If a priority is not provided, the SCEF determines the acceptable delay based on local policies.
    • pdnEstablishmentOption may be used to indicate the IN-CSE's default preference for how the SCEF should process a MT NIDD request from the IN-CSE if the UE has not yet established a Non-IP PDN connection to the SCEF. If a PDN Connection Establishment Option is not provided with the non-IP packet, the SCEF uses the PDN Connection Establishment Option that was provided during NIDD Configuration to decide how to handle the absence of a PDN connection.
    • reliableDataService (optional) shall be set to TRUE or FALSE to indicate that Reliable Data Service acknowledgement is required or not.
    • rdsPort shall be set to the source and destination ports used for MO and MT NIDD between the IN-CSE and the ASN/MN-CSE or ADN-AE hosted on the UE.
    • data shall be configured with a oneM2M primitive to send to the UE hosting the targeted ASN/MN-CSE or ADN-AE.

Note

The use of a PUT request to replace an existing MT NIDD Downlink Data Transfer request and a GET request to read the parameters associated with an existing MT NIDD Downlink Data Transfer request by the IN-CSE are not used by the present document.

Step 4: MT NIDD Downlink Data Transfer Response

If the targeted UE does not have an active NIDD PDN connection to the SCEF, the SCEF may buffer the request until the UE establishes the connection. The SCEF may also trigger the UE to establish a NIDD PDN connection to the SCEF. Alternatively, the SCEF may generate an error.

The SCEF may return a MT NIDD Downlink Data Transfer Response to the IN-CSE to indicate if the request is buffered, a trigger has been generated, or an error has occurred. The fields of the response are populated as follows.

  • A response code of 200 OK or 201 CREATED
    • 200 OK is returned if the delivery of the NIDD Downlink Data Transfer Request was successful
    • 201 CREATED is returned if the SCEF accepted and buffered the NIDD Downlink Data Transfer Request to be performed later
  • The URI of the NIDD Downlink Data Transfer resource created by the SCEF, for the case when response code is 201 CREATED. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-nidd/v1/{scsAsId}/configurations/{configurationId}/downlink-data-deliveries/{downlinkDataDeliveryId}. The {apiRoot},{scsAsId} and {configurationId} segments match those in the request. The {downlinkDataDeliveryId} segment is configured by the SCEF.
  • The response payload will include a NiddDownlinkDataTransfer data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
    • deliveryStatus is used to indicate a success or an appropriate error cause value as defined in 3GPP TS 29.122 [4].
    • self is configured with a URI to the resource created by the SCEF for the request.
    • requestedRetransmissionTime is configured with the absolute time at which the SCEF expects the IN-CSE to retransmit the MT NIDD Downlink Data Transfer Request.

If an error occurs while processing the NIDD Downlink Data Transfer Request, the SCEF will respond with an error code as defined in 3GPP TS 29.122 [4]. See clause 8.3 for further details on the actions an IN-CSE shall take when receiving an error from the SCEF.

If the MT NIDD Downlink Data Transfer Request results in an error, the IN-CSE shall forward a corresponding oneM2M error to the Originator of the request. See clause 8.3 for a list of possible error scenarios.

Step 5: Process MT NIDD Downlink Data Transfer Request

If the UE targeted by the MT NIDD Downlink Data Transfer Request has an active NIDD PDN connection to the SCEF, the SCEF interacts with the 3GPP Core Network to process the request and deliver it to the targeted UE.

Note

If a MT NIDD Downlink Data Transfer Request is received with non-IP data for a request that is already buffered, then the buffered data is replaced by the SCEF. If a MT NIDD Downlink Data Transfer Request is received with no non-IP data for a request that is already buffered, then the buffered data is purged by the SCEF.

Step 6 (Optional) : MT NIDD Downlink Data Delivery Status Notification

If the SCEF returned a 202 ACCEPTED response in Step 4 indicating that it buffered the NIDD Downlink Data Request to be performed later, then after completing the processing of the MT NIDD Downlink Data Transfer Request, the SCEF returns a MT NIDD Downlink Data Delivery Status Notification configured as follows.

  • An HTTP POST method is used
  • URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the NIDD Configuration Request.
  • The request payload includes a NiddDownlinkDataDeliveryStatusNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • niddDownlinkDataTransfer is configured with the URI of the corresponding MT NIDD Downlink Data Transfer resource.
    • deliveryStatus is set by the SCEF to indicate the delivery status NIDD Downlink Data Transfer request.
    • requestedRetransmissionTime is configured with the absolute time at which the SCEF expects the IN-CSE to retransmit the MT NIDD Downlink Data Transfer Request.

Step 7 : MT NIDD Downlink Data Delivery Status Acknowledgement

After receiving a MT NIDD Downlink Data Delivery Status Notification, the IN-CSE responds with a 204 NO CONTENT acknowledging the notification.

Step 8 : Process oneM2M Request Primitive

The ASN/MN-CSE or ADN-AE hosted on the UE targeted by the MT NIDD Downlink Data Transfer Request processes the oneM2M request primitive delivered within the MT NIDD Downlink Data Transfer Request. If the oneM2M request primitive requires a response, the ASN/MN-CSE or ADN-AE hosted on the UE prepares the oneM2M response primitive. Otherwise a response is not returned.

Step 9 (Optional): MO NIDD Uplink Data Notification

The UE acknowledges the RDS packet and the ASN/MN-CSE or ADN-AE generates a oneM2M response primitive and issues a MO NIDD Uplink Data Notification to deliver the response primitive back to the Originator. The MO NIDD Uplink Data Notification to deliver the oneM2M response primitive shall be addressed to the same port numbers that were received in step 5 and the request shall indicate that an RDS acknowledgement is desired.

Step 10 (Optional): MO NIDD Uplink Data Notification

When the SCEF receives the MO NIDD Uplink Data Notification, it finds the corresponding T8 Destination Address (URI) of the IN-CSE based on the NIDD Configuration that has been successfully performed. The SCEF then forwards the oneM2M primitive carried in the MO NIDD Uplink Data Notification to the IN-CSE configured as follows.

  • An HTTP POST method is used
  • URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the NIDD Configuration Request.
  • The request payload includes a NiddUplinkDataNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • niddConfiguration is configured with the URI of the NIDD Configuration resource to which this notification is related to.
    • externalId is set to the M2M-Ext-ID of the UE hosting the targeted ASN/MN-CSE or ADN-AE that originated the MO NIDD Uplink Data Notification.
    • reliableDataService shall be set to TRUE or FALSE to indicate whether the Reliable Data Service acknowledgement is enabled or not
    • rdsPort indicates the source and destination ports that were provided in the MO NIDD Uplink Data Notification
    • data is configured with a oneM2M response primitive sent by the UE hosting the Originator ASN/MN-CSE or ADN-AE.

Step 11 (Optional): MO NIDD Uplink Data Acknowledgement

After receiving a MT NIDD Uplink Data Delivery Notification, the IN-CSE responds with a 204 NO CONTENT acknowledging the notification.

Step 12 (Optional): MO NIDD Uplink Data Response

The SCEF sends an NIDD Uplink Data Response to the UE and processes the MO NIDD Uplink Data Acknowledgement from the IN-CSE.

Step 13 (Optional): Return oneM2M Response Primitive to Application

If an AE (e.g. IN-AE) was the Originator of the corresponding oneM2M request primitive, the IN-CSE shall return the oneM2M response primitive to the AE.

If an NIDD request results in an error, the IN-CSE shall forward a corresponding oneM2M error to the Originator of the oneM2M request primitive. See clause 8.3 for a list of possible error scenarios.

7.1.1.3 SCEF-based Mobile Originated NIDD

The SCEF API supports a Mobile Originated (MO) NIDD procedure that may be used by a UE hosting an ASN/MN-CSE or ADN-AE to send uplink non-IP data to an IN-CSE. Figure 7.1.1.3-1 illustrates this procedure.

Figure 7.1.1.3-1: SCEF-based Mobile Originated NIDD

Figure 7.1.1.3-1: SCEF-based Mobile Originated NIDD

Pre-conditions:

The NIDD Configuration procedure defined in clause 7.1.1.1 completes successfully.

Step 1: oneM2M Request Primitive Generation

The ASN/MN-CSE or ADN-AE hosted on a UE generates a oneM2M request primitive targeting the IN-CSE.

Step 2: MO NIDD Uplink Data Notification

The ASN/MN-CSE or ADN-AE issues a MO NIDD Uplink Data Notification to deliver the primitive to the IN-CSE. When the request is sent, the UE shall indicate that an RDS acknowledgment is requested. The RDS source and destination port numbers shall be set to the same values that were provided to the SCEF by the IN-CSE during NIDD Configuration. The port numbers are pre-provisioned in the ASN/MN-CSE or ADN-AE.

Step 3: MO NIDD Uplink Data Notification

When the SCEF receives the MO NIDD Uplink Data Notification, it finds the corresponding T8 Destination Address of the IN-CSE based on the NIDD Configuration that has been successfully performed. The SCEF then forwards the oneM2M request primitive carried in the MO NIDD Uplink Data Notification to the IN-CSE configured as follows.

  • An HTTP POST method is used
  • URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the NIDD Configuration Request.
  • The request payload includes a NiddUplinkDataNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • niddConfiguration is configured with the URI of the NIDD Configuration resource to which this notification is related to.
    • externalId is set to the M2M-Ext-ID of the UE hosting the targeted ASN/MN-CSE or ADN-AE that originated the MO NIDD Uplink Data Notification.
    • reliableDataService is set to TRUE or FALSE by the SCEF to indicate that Reliable Data Service is enabled or not
    • rdsPort indicates the source and destination ports that were provided in the MO NIDD Uplink Data Notification
    • data is configured with a oneM2M request primitive sent by the UE hosting the Originator ASN/MN-CSE or ADN-AE.

Step 4: MO NIDD Uplink Data Acknowledgement

After receiving a MT NIDD Uplink Data Delivery Notification, the IN-CSE responds with a 204 NO CONTENT acknowledging the notification.

Step 5: MO NIDD Uplink Data Response

The SCEF sends an RDS acknowledgment to the UE and the SCEF processes the MO NIDD Uplink Data Acknowledgement from the IN-CSE.

Step 6: Process oneM2M Request Primitive

The IN-CSE processes the oneM2M request primitive that was delivered in the MO NIDD Uplink Data Notification. If the oneM2M request primitive requires a response, the IN-CSE shall prepare the oneM2M response primitive.

Step 7 (Optional) : Return oneM2M Response Primitive

The IN-CSE may generate a oneM2M response primitive if a response is required. If a response is required, the IN-CSE shall issue a MT NIDD Downlink Data Transfer Request to deliver it to the ASN/MN-CSE or ADN-AE hosted on the UE that originated the corresponding oneM2M request primitive. The IN-CSE shall only issue a SCEF-based Mobile Terminated (MT) NIDD Downlink Data Transfer Request if the size of the oneM2M response primitive to be sent in the request is less than or equal to the NIDD Max Packet Size established during the corresponding the NIDD Configuration procedure for the UE.

The message is configured as follows.

  • An HTTP POST method shall be used
  • URI shall be set to {apiRoot}/3gpp-nidd/v1/{scsAsId}/configurations/{configurationId}/downlink-data-deliveries. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {configurationId} segment shall be configured with the {configurationId} returned by the SCEF when the NIDD Configuration was performed by the IN-CSE for this ASN/MN-CSE or ADN-AE.
  • The request payload shall include a NiddDownlinkDataTransfer data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • externalId shall be set to the M2M-Ext-ID of the UE hosting the targeted ASN/MN-CSE or ADN-AE.
    • maximumLatency may be set to indicate the maximum delay acceptable for MT data and used to configure the buffer duration in the underlying 3GPP network; a maximum latency of 0 indicates that buffering is not allowed. If maximum latency is not provided, the SCEF determines the acceptable delay based on local policies.
    • priority may be set to indicate the priority of the non-IP data packet relative to other non-IP data packets. If a priority is not provided, the SCEF determines the acceptable delay based on local policies.
    • pdnEstablishmentOption may be used to indicate the IN-CSE's default preference for how the SCEF should process a MT NIDD request from the IN-CSE if the UE has not yet established a Non-IP PDN connection to the SCEF. If a PDN Connection Establishment Option is not provided with the non-IP packet, the SCEF uses the PDN Connection Establishment Option that was provided during NIDD Configuration to decide how to handle the absence of a PDN connection.
    • reliableDataService (optional) shall be set to TRUE or FALSE to indicate that Reliable Data Service acknowledgement is required or not.
    • rdsPort shall be set to the source and destination ports used for MO and MT NIDD between the IN-CSE and the ASN/MN-CSE or ADN-AE hosted on the UE.
    • data shall be configured with a oneM2M response primitive to send to the UE hosting the targeted ASN/MN-CSE or ADN-AE.

Step 8 (Optional): MT NIDD Downlink Data Transfer Response

If the targeted UE does not have an active NIDD PDN connection to the SCEF, the SCEF may buffer the request until the UE establishes the connection. The SCEF may also trigger the UE to establish a NIDD PDN connection to the SCEF. Alternatively, the SCEF may generate an error.

The SCEF may return a MT NIDD Downlink Data Transfer Response to the IN-CSE to indicate if the request is buffered, a trigger has been generated, or an error has occurred. The fields of the response are populated as follows.

  • A response code of 200 OK or 201 CREATED
    • 200 OK is returned if the delivery of the NIDD Downlink Data Transfer was successful
    • 201 CREATED is returned if the SCEF accepted and buffered the NIDD Downlink Data Request to be performed later
  • The URI of the NIDD Downlink Data Transfer resource created by the SCEF for the case when response code is 201 CREATED. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-nidd/v1/{scsAsId}/configurations/{configurationId}/downlink-data-deliveries/{downlinkDataDeliveryId}. The {apiRoot}, {scsAsId} and {configurationId} segments match those in the request. The {downlinkDataDeliveryId} segment is configured by the SCEF.
  • The response payload will include a NiddDownlinkDataTransfer data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
    • deliveryStatus is used to indicate a success or an appropriate error cause value as defined in 3GPP TS 29.122 [4].
    • self is configured with a URI to the resource created by the SCEF for the request.
    • requestedRetransmissionTime is configured with the absolute time at which the SCEF expects the IN-CSE to retransmit the MT NIDD Downlink Data Transfer Request.

If the MT NIDD Downlink Data Transfer Request results in an error such that the IN-CSE is not able to return a oneM2M response primitive to the Originator of the request, the IN-CSE shall drop the response. See clause 8.3 for a list of possible error scenarios.

Step 9 (Optional): Process MT NIDD Downlink Data Transfer Request

If the UE targeted by the MT NIDD Downlink Data Transfer Request has an active NIDD PDN connection to the SCEF, the SCEF interacts with the 3GPP Core Network to process the request and deliver it to the targeted UE. The UE responds with an RDS acknowledgment.

Note

If an MT NIDD Downlink Data Transfer Request is received with non-IP data that is equal to a request that is already buffered, then the buffered data is replaced by the SCEF. If an MT NIDD Downlink Data Transfer Request is received with no non-IP data that is equal to a request that is already buffered, then the buffered data is purged by the SCEF.

Step 10 (Optional) : MT NIDD Downlink Data Delivery Status Notification

After completing the processing of the MT NIDD Downlink Data Transfer Request, the SCEF returns a MT NIDD Downlink Data Delivery Status Notification configured as follows:

  • An HTTP POST method is used
  • URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the NIDD Configuration Request.
  • The request payload includes a NiddDownlinkDataDeliveryStatusNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • niddDownlinkDataTransfer is configured with the URI of the corresponding MT NIDD Downlink Data Transfer resource.
    • deliveryStatus is set by the SCEF to one of the status codes defined in 3GPP TS 29.122 [4] to indicate if the request was delivered successfully or not.
    • requestedRetransmissionTime is configured with the absolute time at which the UE will be reachable in the event that the UE is not reachable.

Step 11 (Optional) : MT NIDD Downlink Data Delivery Status Acknowledgement

After receiving a MT NIDD Downlink Data Delivery Status Notification, the IN-CSE responds with a 204 NO CONTENT acknowledging the notification.

Step 12 (Optional): Process oneM2M Request Primitive

The ASN/MN-CSE or ADN-AE hosted on the UE targeted by the MT NIDD Request processes the oneM2M response primitive delivered within the MT NIDD Request.