Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 29.122  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4.4…   4.4.3…   4.4.5…   4.4.7   4.4.8…   4.4.12…   5…   5.6…   5.8…   5.10…   5.12…   6…

 

4.4.5  Procedures for Non-IP Data DeliveryWord‑p. 30

4.4.5.1  General

This procedure is used by an SCS/AS to support the Non-IP Data Delivery (NIDD) via SCEF. It performs the NIDD configuration via the T8 interface. It also includes the mobile terminated (MT) and mobile originated (MO) communication with UEs via the T8 interface. It also includes the group message delivery via MT NIDD via the T8 interface and management of port numbers on UE and SCEF and their dynamic association with different applications.
Error handling for the procedures in this subclause shall be handled based on subclause 5.2.6.
Up

4.4.5.2  NIDD ConfigurationWord‑p. 31
4.4.5.2.1  NIDD Configuration for a single UE
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 an downlink non-IP data together with the NIDD configuration creation, the SCEF shall also create an "Individual NIDD downlink data delivery" sub-resource and send each of the sub-resouce 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 subclause 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.
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.
Up
4.4.5.2.2  NIDD Configuration for a group of UEsWord‑p. 32
The NIDD configuration procedure for a single UE as described in subclause 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.
Up

4.4.5.3  Mobile Terminated NIDD procedure

4.4.5.3.1  Mobile Terminated NIDD for a single UE
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 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 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 a 403 Forbidden response with a cause value "DATA_TOO_LARGE" in the "cause" attribute of the "ProblemDetails" 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 a 403 Forbidden response with a cause value "RDS_PORT_UNKNOWN" in the "cause" attribute of the "ProblemDetails" 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 subclause 4.4.6 without buffering the non-IP data and respond the SCS/AS with a 500 Internal Server Error response; 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 subclause 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" structure indicating the reason for the failure condition. If rate limit is reached, the SCEF shall respond the SCS/AS with 429 Too Many Requests.
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 and a cause value indicating the reason for the delivery failure; or
  • if the MME/SGSN indicates UE is temporary not reachable, either:
    1. buffer the non-IP data and 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" structure indicating the downlink non-IP data delivery is perfomed but 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 409 Conflict with a cause value "SENDING" in the "cause" attribute of the "ProblemDetails" structure indicating replacement failure. If the buffered data is already delivered, the SCEF shall respond with 404 Not Found and include a cause value a cause value "ALREADY_DELIVERED" in the "cause" attribute of the "ProblemDetails" structure indicating replacement failure.
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 404 Not Found (i.e. data already delivered) with a cause value "ALREADY_DELIVERED" in the "cause" attribute of the "ProblemDetails" structure or 409 Conflict (i.e. data delivery ongoing) response with a cause value "SENDING" in the "cause" attribute of the "ProblemDetails" 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.
Up
4.4.5.3.2  Mobile Terminated NIDD for a group of UEsWord‑p. 33
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 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 subclause 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 subclause 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 403 Forbidden response with a cause value "OPERATION_PROHIBITED" in the "cause" attribute of the "ProblemDetails" 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.
Up

4.4.5.4  Mobile Originated NIDD procedureWord‑p. 34
When the SCEF receives the non-IP data from MME/SGSN (or IWK-SCEF) as defined in TS 29.128, and finds an SCEF EPS bearer context and the associated NIDD configuration, the SCEF shall determine the SCS/AS by the corresponding NIDD configuration, and send an HTTP POST request to the SCS/AS identified by the Notification Destination Address received in the NIDD configuration to notify the uplink non-IP data. The body of the HTTP POST message shall include External Identifier or MSISDN, non-IP data, NIDD configuration identifier, Reliable Data Service Configuration (if available). 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 the request, if the SCS/AS knows the NIDD configuration identified by the NIDD configuration identifier, the SCS/AS shall acknowledge a 200 OK or 204 No Content message to the SCEF.
Up

4.4.5.5  NIDD Authorisation Update procedure

When the SCEF receives a NIDD Authorisation Update Request message from HSS to update a user's NIDD authorisation as defined in TS 29.336, the SCEF shall determine the SCS/AS with the corresponding NIDD Configuration, and send an HTTP POST message to the SCS/AS to notify it of the NIDD Authorisation Update. The body of the HTTP POST message shall include External Identifier or MSISDN, NIDD configuration identifier and the NIDD configuration status.
Upon receipt of the request, if the SCS/AS knows the corresponding NIDD configuration, then the SCS/AS shall acknowledge the request with an HTTP 200 OK or 204 No Content response.
If the NIDD configuration is revoked by the HSS within the received NIDD Authorisation Update Request, the SCEF shall release the corresponding T6a/b PDN connection as specified in TS 29.128. In this case, the SCEF shall reject any subsequent MT NIDD deliveries with a 403 Forbidden response. Or 404 Not Found is returned, if the SCEF locally removed the associated NIDD configuration resource when the configuration was revoked.
If the RDS capability is changed, e.g. when the T6a/b PDN connection is etablished, the UE indicates no support for RDS but the SCEF previously indicated RDS is supported to the SCS/AS in the NIDD configuration procedure, the SCEF shall send an HTTP POST message to notify the SCS/AS that the NIDD status is active and RDS capability indication. The SCS/AS shall acknowledge the request with an HTTP 200 OK or 204 No Content response.
If the Rds_port_verification feature is supported, before sending the MO NIDD to the SCS/AS as specified in subclause 4.4.5.4, the SCEF shall check RDS port numbers (decoded from the uplink non-IP data according to TS 24.250). If the RDS port numbers are not within the configured RDS port list, the SCEF shall notify the SCS/AS with NIDD status set to "RDS_PORT_UNKNOWN" and the unknown RDS port numbers. The SCS/AS shall acknowledge the request with an HTTP 200 OK or 204 No Content response.
Up

4.4.5.6  Port Management Configuration |R16|Word‑p. 35
4.4.5.6.1  Port Reservation and Release
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 serializtion formats by the SCS/AS, query of the supported and configured serializtion formats by the SCS/AS, and notification of the supported and configured serializtion 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 subclause 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 403 Forbidden response with a cause value "PORT_NOT_FREE" in the "cause" attribute of the "ProblemDetails" 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 202 Accept 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 subclause 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 subclause 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 403 Forbidden response with a cause value "PORT_NOT_FREE" in the "cause" attribute of the "ProblemDetails" 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 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 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 404 Not Found with a cause value "PORT_NOT_ASSOC_WITH_APP" in the "cause" attribute of the "ProblemDetails" structure; otherwise if the 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 subclause 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 403 Forbidden response with a cause value "OPERATION_PROHIBITED" in the "cause" attribute of the "ProblemDetails" 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 asocigted 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 subclause 5.6.3.9.2.
Up
4.4.5.6.2  Port NotificationWord‑p. 36
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.
Up

4.4.6  Procedures for Device Triggering

The procedures are used by the SCS/AS to deliver the device trigger via T8 interface.
In order to create a new device trigger, the SCS/AS shall send an HTTP POST message to the SCEF for the "Device Triggering Transactions" resource. The body of the HTTP POST message shall include the External Identifier or MSISDN, validity period, priority, Application Port ID and trigger payload.
Upon receipt of the corresponding HTTP POST message, the SCEF shall check if the SCS/AS is authorised to send a trigger request and if the SCS/AS has exceeded its quota or rate of trigger submission. The SCEF shall also resolve the External Identifier or MSISDN to IMSI and retrieve the "Routing Information" from HSS for the triggering delivery. If the authorisation check fails, or if the quota or rate of trigger submission was exceeded, or if there is no valid subscription information or if the "Routing Information" cannot be found, then the SCEF shall reject the request with an error message to the SCS/AS. Otherwise, the SCEF shall perform the device trigger procedure over Tsp as defined in TS 29.368 and T4 as defined in TS 29.337. Upon completion of this procedure, the SCEF shall create a resource "Individual Device Triggering Transaction" which represents the triggering transaction, addressed by a URI that contains the SCS/AS identity and an SCEF-created transaction identifier, and shall respond to the SCS/AS with a 201 Created message, including the trigger and a Location header field containing the URI for the created resource. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this device triggering transaction.
In order to replace an existing device trigger, the SCS/AS shall send an HTTP PUT message to the SCEF for the "Individual Device Triggering Transaction" resource, using the URI received in the response to the request that has created the device triggering transaction resource. The body of the HTTP PUT message shall include External Identifier or MSISDN, validity period, priority, Application Port ID and trigger payload.
After receiving the corresponding HTTP PUT message from the SCS/AS, the SCEF shall check if the SCS/AS is authorised to replace an existing device trigger and if the SCS/AS has not exceeded its quota or rate of trigger submission. If any of these checks fail, then the SCEF shall reject the message with an error. Otherwise, the SCEF shall replace the device triggering with the SMS-SC by performing the device trigger replace procedure over Tsp as defined in TS 29.368 and T4 as defined in TS 29.337. Upon completion of this procedure, the SCEF shall send an HTTP response to the SCS/AS to indicate trigger replace success or failure.
In order to recall an existing device trigger, the SCS/AS shall send an HTTP DELETE message to the SCEF for the "Individual Device Triggering Transaction" resource, using the URI received in the response to the request that has created the device triggering transaction resource.
After receiving the corresponding HTTP DELETE message from the SCS/AS, the SCEF shall check if the SCS/AS is authorised to send a recall trigger request and if the SCS/AS has not exceeded its quota or rate of trigger submission. The SCEF shall also check if the device triggering transaction resource referenced by the URI exists. If any of these checks fail, then the SCEF shall reject the message with an error. Otherwise, the SCEF shall recall the device triggering with the SMS-SC by performing the device trigger recall procedure over Tsp as defined in TS 29.368 and T4 as defined in TS 29.337. Upon completion of this procedure, the SCEF shall send an HTTP response to the SCS/AS to indicate trigger recall success or failure.
When it receives the Message Delivery Report from the SMS/SC, the SCEF shall send an HTTP POST message to the SCS/AS to report the trigger delivery result. The body of the HTTP POST message shall include the identifier if the transaction and cause. The SCS/AS shall respond with an HTTP 200 OK or 204 No Content response.
Up

Up   Top   ToC