Content for  TS 29.122  Word version:  18.4.0

For a NIDD configuration creation, the SCS/AS shall send an HTTP POST message to the SCEF for the "NIDD configurations" resource. The body of the HTTP POST message shall include External Identifier or MSISDN, SCS/AS Identifier, notification destination URI identifying the recipient of notification within the "notificationDestination" attribute and may include NIDD Duration, PDN Connection Establishment Option and Reliable Data Service Configuration. In addition, the SCS/AS may send non-IP data and its associated parameters (e.g. Priority) as described in subsclause 4.4.5.3.1 in the NIDD configuration creation request. The Reliable Data Service Configuration includes port numbers on UE and SCEF that are used to identify specific applications for data transfer between UE and SCS/AS and an indication if reliable data service acknowledgement is enabled or not. Upon receipt of the HTTP POST request from the SCS/AS to create a NIDD configuration, the SCEF shall check whether the SCS/AS is authenticated and authorized to create NIDD configuration, and also authorize the NIDD configuration. If authorization is successful, the SCEF shall interact with the HSS via S6t as specified in TS 29.336. Upon receipt of the successful response from the HSS, the SCEF shall store the UE identity (IMSI and External Identifier or MSISDN) which is associated with the External Identifier or MSISDN and create a resource "Individual NIDD configuration", which represents the NIDD configuration, addressed by a URI that contains the SCS/AS identity and an SCEF-created NIDD configuration identifier, and shall respond to the SCS/AS with a 201 Created message, including a Location header field containing the URI for the created resource. The body of the response message shall include Maximum Packet Size and may include Reliable Data Service Indication. When the SCS/AS receives the URI in the Location header, it shall use this URI in subsequent requests to the SCEF to refer to this NIDD configuration. If the SCS/AS includes a downlink non-IP data together with the NIDD configuration creation, the SCEF shall also create the corresponding "Individual NIDD downlink data delivery" sub-resource(s) and send each of the sub- resource(s) within the "self" attribute in the "niddDownlinkDataTransfers" attribute together with the created resource "Individual NIDD configuration" which included in the Location header field in the HTTP POST response. When the SCS/AS receives the URI the "self" attribute in the "niddDownlinkDataTransfers" attribute, it shall use this URI in subsequent requests to the SCEF to refer to this downlink data delivery transfer. After sending the HTTP response to NIDD configuration request, the SCEF shall perform the procedure for individual MT NIDD as described in clause 4.4.5.3.1. For a NIDD configuration modification, the SCS/AS shall send an HTTP PATCH message to the SCEF for the "Individual NIDD configuration" resource, using the URI received in the response to the request that has created the NIDD configuration resource. Upon receipt of the HTTP PATCH request from the SCS/AS to update the parameters of the NIDD configuration, the SCEF shall check whether the SCS/AS is authenticated and authorized to update NIDD configuration. If the authorization is successful, the SCEF shall verify that the resource to be modified already exists as identified by the URI. If the NIDD configuration resource is found, the SCEF shall update the NIDD configuration as requested. Upon successful update of the requested NIDD configuration including the interaction with the HSS via S6t as specified in TS 29.336, the SCEF shall respond to the SCS/AS with a 200 OK success message indicating that the NIDD configuration resource was successfully updated, or with a 204 No Content success message if the NIDD configuration modification is successful updated with no content in the PATCH response message body. For a NIDD configuration cancellation, the SCS/AS shall send an HTTP DELETE message to the SCEF for the "Individual NIDD configuration" resource, using the URI received in the response to the request that has created the NIDD configuration resource. Upon receipt of the HTTP DELETE message from the SCS/AS, the SCEF shall check whether the SCS/AS is authenticated and authorized to delete NIDD configuration. If the authorization is successful, the SCEF shall verify that the NIDD configuration resource identified by the URI already exists. If the configuration resource exists, the SCEF shall delete the requested configuration, and perform related NIDD procedure to EPC network elements if applicable. Upon successful deletion of requested NIDD configuration, the SCEF shall respond to the SCS/AS with a 200 OK success message indicating that the NIDD configuration was successfully cancelled. As an alternative to the 200 OK success message, the SCEF may send a 204 No Content success message without any message content to the SCS/AS. When the NIDD Duration expires, the SCEF may remove the associated NIDD configuration resource and all individual downlink data delivery resources under such NIDD configuration.

The NIDD configuration procedure for a single UE as described in clause 4.4.5.2.1 shall be applicable for a group of UEs with the following differences:

• The External Group Identifier shall be included in the POST request instead of MSISDN or External Identifier.
• After receiving the response message from the HSS, the SCEF shall store the list of UE identifiers (IMSI and External Identifier or MSISDN) which are associated with the External Group Identifier.
• The downlink non-IP data is not supported to be handled together with the NIDD configuration.

If the SCS/AS needs to perform a downlink non-IP data delivery for a single UE, the SCS/AS shall send an HTTP POST message to the SCEF for the "NIDD downlink data deliveries" resource, identifying an existing NIDD configuration resource as parent resource. The body of the HTTP POST message shall include External Identifier or MSISDN and non-IP data and may include PDN Connection Establishment Option, Reliable Data Service Configuration, Maximum Latency and Priority. The Reliable Data Service Configuration includes port numbers on UE and SCEF that are used to identify a specific application for data transfer between UE and SCS/AS and an indication if reliable data service acknowledgement is enabled or not. Upon receipt of a HTTP POST request from the SCS/AS for a downlink data delivery for a single UE, the SCEF shall:

• verify the NIDD configuration resource already exists based on the URI passed, if the configuration resource does not exist, the SCEF shall respond with a 404 Not Found response to reject the downlink data delivery, and
• check whether the SCS/AS is authorised to send NIDD requests, if not authorized, the SCEF shall respond with a 401 Unauthorized response to reject the downlink data delivery, and
• check whether the non-IP packet size is larger than the Maximum Packet Size that was provided to the SCS/AS during NIDD Configuration. If the packet is oversized, the SCEF shall respond with a 403 Forbidden response with a cause value "DATA_TOO_LARGE" in the "cause" attribute of the "ProblemDetails" data structure indicating received non-IP packet size is larger than "maximumPacketSize" of the NIDD configuration.
• if the Rds_port_verification feature is supported, check whether the RDS port numbers are within the configured RDS port list. If the RDS port numbers are unknown in the SCEF, the SCEF shall respond with a 403 Forbidden response with a cause value "RDS_PORT_UNKNOWN" in the "cause" attribute of the "ProblemDetails" data structure.

If all above checks are successful, the SCEF shall determine the EPS Bearer Context based on the APN associated with the NIDD configuration and the User Identity. If the SCEF EPS bearer context is not found in the SCEF, depending on PDN Connection Establishment Option received in the POST request or from NIDD configuration, the SCEF may:

• reject the request with an error message to the SCS/AS;
• send a Device Trigger to the UE as described in clause 4.4.6 without buffering the non-IP data and respond the SCS/AS with a 500 Internal Server Error response and a cause value "TRIGGERED" in the "cause" attribute of the "ProblemDetails" data structure; or
• buffer the non-IP data and create the "Individual NIDD downlink data delivery" sub-resource, then send a 201 Created response to the SCS/AS. The response message also includes an indication of whether the Device Trigger procedure (as described in clause 4.4.6) was performed by the SCEF. A Location header shall be included in the response message that provides the URI of the resource identifying this individual downlink data delivery. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this individual downlink data delivery for possible replacement or cancellation. The non-IP data shall be delivered when the non-IP PDN connection is established.

If the SCEF EPS bearer context is found in the SCEF, the SCEF shall check if the SCS/AS has exceeded the quota or rate of data submission considering the number of existing buffered non-IP data and restriction in APN and serving PLMN rate control. If quota is reached, the SCEF shall respond the SCS/AS with a 403 Forbidden response and a cause value "QUOTA_EXCEEDED" in the "cause" attribute of the "ProblemDetails" data structure indicating the reason for the failure condition. If rate limit is reached, the SCEF shall respond the SCS/AS with a 429 Too Many Requests response. If the check is passed, the SCEF shall continue the downlink non-IP data delivery procedure as the defined TS 29.128. If the non-IP data delivery was successful, the SCEF shall send a 200 OK response to the HTTP POST request indicating the downlink non-IP data delivery is successful along with the acknowledge information; otherwise the SCEF may:

• send a 500 Internal Server Error response and a cause value indicating the reason for the delivery failure within the "cause" attribute of the "ProblemDetails" data structure, i.e.:
  1. if delivery was unsuccessful due to timeout, the cause value "TIMEOUT"; or
  2. if delivery to the next hop was unsuccessful with the cause value "NEXT_HOP"; or
• if the MME/SGSN indicates UE is temporary not reachable, either:
  1. buffer the non-IP data and create the "Individual NIDD downlink data delivery" sub-resource, then send a 201 Created response to the SCS/AS. The response may include a Requested Re-Transmission time to indicate the SCS/AS when the UE is expected to be reachable so that the SCEF re-transmits the buffered non-IP data; or
  2. send a 500 Internal Server Error response without buffering the non-IP data, and include a cause value "TEMPORARILY_NOT_REACHABLE" in the "cause" attribute of the "ProblemDetails" data structure indicating the downlink non-IP data delivery is performedbut stopped since UE is temporarily unreachable. The response may include a Requested Re-Transmission time to indicate the SCS/AS when the UE is expected to be reachable so that the SCS/AS may prepare any re-transmission.

If the MT_NIDD_modification_cancellation feature is supported and the SCS/AS decides to replace the pending downlink data delivery in the SCEF, the SCS/AS shall send an HTTP PUT message to the SCEF, using the URI received in the response to the request that has created the individual downlink data delivery resource. The External Identifier or MSISDN shall remain unchanged from previous values. Upon receipt of the HTTP PUT request from the SCS/AS, the SCEF shall check whether a pending non-IP data exists with the same URI (i.e. resource exists). If it is found, the SCEF shall replace it with the new non-IP data and continue waiting for any message from the MME/SGSN for the UE indicating either the non-IP PDN connection is being established or the UE is reachable (such message may be an MO NIDD); otherwise the SCEF shall respond with a 409 Conflict response with a cause value "SENDING" in the "cause" attribute of the "ProblemDetails" data structure indicating replacement failure. If the buffered data is already delivered, the SCEF shall respond with a 404 Not Found response and include a cause value "ALREADY_DELIVERED" in the "cause" attribute of the "ProblemDetails" data structure indicating replacement failure. If delivery was unsuccessful due to timeout, the SCEF shall respond with a 500 Internal Server Error response with a cause value "TIMEOUT" in the "cause" attribute of the "ProblemDetails" data structure. If delivery to the next hop was unsuccessful, the SCEF shall respond with a 500 Internal Server Error response with a cause value "NEXT_HOP" in the "cause" attribute of the "ProblemDetails" data structure. If the "PatchUpdate" feature defined in clause 5.6.4 is supported and the SCS/AS decides to partially modify the pending downlink data delivery in the SCEF, the SCS/AS shall send an HTTP PATCH message to the SCEF to the URI received in the response to the request that has created the concerned individual downlink data delivery resource. The request body shall contain the NiddDownlinkDataTransferPatch data structure including only the attributes that shall be updated. Upon reception of this HTTP PATCH request from the SCS/AS, the SCEF shall check whether a pending non-IP data with the received URI exists (i.e. the resource exists). If it is found, the SCEF shall apply the requested modifications and continue waiting for any message from the MME/SGSN for the UE indicating either the non-IP PDN connection is being established or the UE is reachable (such message may be an MO NIDD); otherwise the SCEF shall respond with a "409 Conflict" status code including a cause value "SENDING" within the "cause" attribute of the "ProblemDetails" data structure to indicate modification failure. If the buffered data is already delivered, the SCEF shall respond with a "404 Not Found" status code including a cause value "ALREADY_DELIVERED" within the "cause" attribute of the "ProblemDetails" data structure to indicate modification failure. If delivery was unsuccessful due to timeout, the SCEF shall respond with a 500 Internal Server Error status code with a cause value "TIMEOUT" in the "cause" attribute of the "ProblemDetails" data structure. If delivery to the next hop was unsuccessful, the SCEF shall respond with a 500 Internal Server Error status code with a cause value "NEXT_HOP" in the "cause" attribute of the "ProblemDetails" data structure. If the MT_NIDD_modification_cancellation feature is supported and the SCS/AS decides to cancel the pending downlink data delivery in the SCEF, the SCS/AS shall send an HTTP DELETE message to the SCEF, using the URI received in the response to the request that has created the individual downlink data delivery resource. Upon receipt of the HTTP DELETE request from the SCS/AS, the SCEF shall check whether a pending request exists with the same URI. If such non-IP data has not been delivered, the SCEF shall remove the individual downlink data delivery resource and respond with an HTTP 204 No Content response; otherwise the SCEF shall respond with a 404 Not Found response (i.e. data already delivered) with a cause value "ALREADY_DELIVERED" in the "cause" attribute of the "ProblemDetails" data structure or 409 Conflict (i.e. data delivery ongoing) response with a cause value "SENDING" in the "cause" attribute of the "ProblemDetails" data structure, and include a cause value indicating cancellation failure. If a pending non-IP data is delivered by the SCEF (e.g. due to non-IP PDN connection establishment), and the SCEF gets the delivery result from the MME/SGSN, the SCEF shall remove the "Individual NIDD downlink data delivery" sub-resource and send an HTTP POST message to the SCS/AS, identified by the notification destination URI received during the NIDD configuration, to notify the delivery result for the pending non-IP data. Upon receipt of the request, the SCS/AS shall acknowledge the notification with an HTTP 200 OK or 204 No Content response. During MT NIDD delivery, if the UE indicates no support for RDS and the SCEF previously indicated RDS is enabled to the SCS/AS, the SCEF shall stop sending the non-IP data and send MT NIDD delivery notification with "FAILURE_RDS_DISABLED" delivery status.

If the SCS/AS needs to perform a downlink non-IP data delivery to a group of UEs and if both the SCS/AS and the SCEF support GroupMesageDelivery feature as defined in sublcause 5.6.4, the SCS/AS shall send an HTTP POST request message to the SCEF for the "NIDD downlink data deliveries" resource, identifying an existing NIDD configuration resource as parent resource. The body of the HTTP POST request message shall include the External Group Identifier and the non-IP data, and may include Reliable Data Service Configuration, PDN Connection Establishment Option and Maximum Latency. Upon receipt of such an HTTP POST request from the SCS/AS requesting the group message delivery, the SCEF checks whether the SCS/AS is authorised to send NIDD requests, whether the non-IP packet size is larger than the Maximum Packet Size that was provided to the SCS/AS during NIDD Configuration and if the Rds_port_verification feature is supported whether the RDS port numbers are recognized. If any of those checks fails, the SCEF shall respond with a HTTP response with a cause value indicating the reason for the failure condition. If all checks are successful, the SCEF shall create an "Individual NIDD downlink data delivery" resource and sends a 201 Created response to the SCS/AS to acknowledge acceptance of the HTTP POST request. Then for each authorized External Identifier associated to the External Group Identifier which is retrieved from the HSS during preceding NIDD configuration procedure (as specified in clause 4.4.5.2.2), the SCEF shall determine the EPS Bearer Context based on the APN associated with the NIDD configuration and the User Identity and continue the procedure as described for MT NIDD for a single UE in clause 4.4.5.3.1 without sending downlink data delivery status notification for any individual UE to the SCS/AS. At the end of buffering (duration determined by the Maximum Latency or local policy) or after processing data delivery for all UEs in the group, the SCEF shall send an HTTP POST message to SCS/AS to indicate the aggregated result of data delivery of each UE. The body of the HTTP POST request message shall include MSISDN or External Identifier, Retransmission Time (optional) and delivery result for each UE. Upon receipt of the request, the SCS/AS shall acknowledge the request with an HTTP 200 OK or 204 No Content response. The MT_NIDD_modification_cancellation feature is not supported for the group message delivery via NIDD. If a PUT or DELETE request is received for the "Individual NIDD downlink data delivery" resource which was created for a group of UEs, the SCEF shall reject the message with a 403 Forbidden response with a cause value "OPERATION_PROHIBITED" in the "cause" attribute of the "ProblemDetails" data structure. During MT NIDD delivery, if the UE indicates no support for RDS and the SCEF previously indicated RDS is enabled to the SCS/AS, the SCEF shall stop sending the non-IP data for the indicated UE. In the aggregated MT NIDD delivery notification, the SCEF shall send "FAILURE_RDS_DISABLED" delivery status for each failed UE.

As part of the Port Management configuration, operations to reserve a combination of port numbers, release a combination of port numbers, query the list of port numbers that are reserved and notification of reservation of a port number may be performed, if the Rds_dynamic_port feature is supported. Indication of the supported serialization formats by the SCS/AS, query of the supported and configured serialization formats by the SCS/AS, and notification of the supported and configured serialization formats by the SCS/AS may be performed if the Rds_serialization_format feature is supported. If the SCS/AS needs to reserve port numbers and associate them with an application, the SCS/AS shall send an HTTP PUT message to the SCEF, using the URI received in the response to the request that has created the NIDD configuration resource and the specific part of "/rds-ports/{portId}" as described in clause 5.6.3.9.2. The SCS/AS may use this operation to reserve port numbers on the UE and SCEF and associate them with an application. The SCS/AS may also use this operation to indicate the serialization formats that are supported by the SCS/AS on the port. Upon receipt of the HTTP PUT request from the SCS/AS,

• if the "skipUeInquiry" is set to "false" and if the "individual ManagePort Configuration" resource already exists in the same NIDD configuration, the SCEF shall respond with a 403 Forbidden response with a cause value "PORT_NOT_FREE" in the "cause" attribute of the "ProblemDetails" data structure; otherwise, the SCEF shall interact with the UE via the SGSN/MME to reserve the port and optionally configure the serialization format by using RDS protocol as specified in TS 24.250 and return a 202 Accept response to the SCS/AS if successful response is received from the SGSN/MME. Then if the SCEF receives successful UE response, the SCEF shall create the "individual ManagePort Configuration" resource and notify the SCS/AS with the reserved port and configured serialization format as specified in clause 4.4.5.6.2, the SCEF shall also mark the resource is created by the SCS/AS; otherwise, the SCEF shall notify the SCS/AS about the currently reserved ports as specified in clause 4.4.5.6.2.
• if the "skipUeInquiry" is set to "true" and if the requested SCEF port already exists in an NIDD configuration within the same APN, the SCEF shall respond with a 403 Forbidden response with a cause value "PORT_NOT_FREE" in the "cause" attribute of the "ProblemDetails" data structure; otherwise, the SCEF shall create the "individual ManagePort Configuration" resource and send an HTTP 201 Created response to the SCS/AS, the SCEF shall also mark the resource is created by the SCS/AS and notify the UE by using RDS protocol as specified in TS 24.250.

If the SCEF is not able to configure a serialization format for the port and if the Rds_serialization_format feature is supported, the SCEF shall respond with a 500 Internal Server Error response with a cause value "SERIALIZATION_FORMAT_NOT_SUPPORTED" in the "cause" attribute of the "ProblemDetails" data structure. If the SCS/AS needs to release port numbers associated with an application, the SCS/AS shall send an HTTP DELETE message to the SCEF, using the URI received in the response to the request that has created the "individual ManagePort Configuration" resource. Upon receipt of the HTTP DELETE request from the SCS/AS, if the "individual ManagePort Configuration" resource does not exist in the same NIDD configuration, the SCEF shall respond with a 404 Not Found response with a cause value "PORT_NOT_ASSOC_WITH_APP" in the "cause" attribute of the "ProblemDetails" data structure; otherwise if the "individual ManagePort Configuration" resource was created by the SCS/AS and

• if the "skipUeInquiry" is set to "false", the SCEF shall interact with the UE via the SGSN/MME to release the port by using RDS protocol as specified in TS 24.250 and return 202 Accept to the SCS/AS if successful response is received from the SGSN/MME. Then upon receipt of the UE response, the SCEF shall notify the SCS/AS with the currently reserved ports as specified in clause 4.4.5.6.2.
• if the "skipUeInquiry" is set to "true", the SCEF shall delete the individual ManagePort Configuration resource and respond with an HTTP 204 No Content response to the SCS/AS. The SCEF shall also notify the UE by using RDS protocol as specified in TS 24.250.

If the HTTP DELETE request is received for the "Individual ManagePort Configuration" resource which was created by the UE, the SCEF shall reject the message with a 403 Forbidden response with a cause value "OPERATION_PROHIBITED" in the "cause" attribute of the "ProblemDetails" data structure. If the "skipUeInquiry" is set to "false" and the SCEF is not able to interact with the UE because:

• PDN connection is not established, the SCEF shall reject the HTTP PUT/DELETE request with a 500 Internal Server Error response with a cause value "NO_PDN_CONNECTION";
• UE is not reachable, the SCEF shall reject the HTTP PUT/DELETE request with a 500 Internal Server Error response with a cause value "TEMPORARILY_NOT_REACHABLE". The response may include a Requested Re-Transmission time to indicate the SCS/AS when the UE is expected to be reachable so that the SCS/AS may prepare any re-configuration for the RDS port; or
• the interaction with the SGSN/MME is not successful, the SCEF shall reject the HTTP PUT/DELETE request with a 500 Internal Server Error and a proper cause value indicating the reason for the delivery failure.

If the SCS/AS needs to read the port numbers and serialization formats that are associated with an application, the SCS/AS shall send an HTTP GET message to the SCEF, using the URI received in the response to the request that has created the NIDD configuration resource and the specific part of "/rds-ports/{portId}" as described in clause 5.6.3.9.2.

If the SCEF needs to send the information about reserved ports and their configuration to the SCS/AS (e.g. due to 3GPP network created or released "individual ManagePort Configuration" resource upon UE triggered RDS port management procedures as specified in TS 24.250), the SCEF shall send an HTTP POST message to the SCS/AS, using the URI received within the "notificationDestination" attribute in the NiddConfiguration resource. The body of the message is encoded in JSON format with the data structure defined in table 5.6.2.1.9-1. The SCS/AS shall acknowledge the HTTP POST request with an HTTP 200 OK or 204 No Content response.