Skip to content

7.5 3GPP Based Device triggering

7.5.1 General Procedure for 3GPP Based Device Triggering

An IN-CSE may initiate a device trigger to an ASN/MN-CSE or ADN-AE hosted on a 3GPP UE to cause it to establish a connection to the IN-CSE, enrol to a MEF, register to the IN-CSE, update its PoA, or perform a CRUD operation on a specified resource. The IN-CSE may initiate the device trigger itself (implicit) or it may be initiated by a request that the IN-CSE receives from an AE (explicit).

Whenever the IN-CSE sends a device trigger to an ASN/MN-CSE or ADN-AE hosted on a 3GPP UE, the device triggering procedure as described in 3GPP TS 29.122 [4] shall be used as the basis for the procedures defined below.

This procedure supports an ASN/MN-CSE or ADN-AE that is hosted on a 3GPP UE that is directly connected to an underlying 3GPP network.

Figure 7.5.1-1: General Procedure for Device Triggering

Figure 7.5.1-1: General Procedure for Device Triggering

Pre-conditions

The UE that hosts the ASN/MN-CSE or ADN-AE is available to receive the Device Trigger Request using one of the connectivity establishment methods described in clause 6.

Step 1 (Optional): Request targeted to ASN/MN-CSE or ADN-AE

An AE may initiate a device trigger to an ASN/MN-CSE or ADN-AE explicitly by creating or updating a <triggerRequest> resource as specified in clause 9.6.49 of oneM2M TS-0001[1]. Alternatively, an AE may initiate a device trigger to an ASN/MN-CSE or ADN-AE implicitly by issuing a request to an IN-CSE that requires device triggering. For example, if an IN-CSE receives a request to perform a CRUD operation targeting an ASN/MN-CSE or ADN-AE hosted on a 3GPP UE that is not reachable by the IN-CSE, the IN-CSE may generate a trigger request.

Step-2: Determine if Device Triggering is required

The IN-CSE determines whether to send a device trigger to the targeted ASN/MN-CSE or ADN-AE. Further details are provided in clause 8.3.3.2.1 of oneM2M TS0001 [1].

If device trigger was initiated by an AE, initiating AE determines device trigger.

Step 3a: Request for Device Triggering

The IN-CSE or AE sends the Device Triggering request that contains information as specified in 3GPP TS 29.122 [4]. Such information includes:

  • An HTTP POST method shall be used
  • URI shall be set to {apiRoot}/3gpp-device-triggering/v1/{scsAsId}/transactions. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
  • The request payload shall include a DeviceTriggering data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • supportedFeatures shall be set to a string value of "0" indicating that trigger notifications over Websockets or trigger notification test events are not supported.
    • validityPeriod shall be set to either the triggerValidityTime attribute of the <triggerRequest> resource if the trigger request is initiated by an AE.
    • triggerPayload shall be configured as described in clause 8.3.3.2.1 of oneM2M TS 0001 [1] and clause 9.2.1 of oneM2M TS-0004 [3]. An empty payload indicates that the targeted ASN/MN-CSE or ADN-AE shall re-establish connectivity with the IN-CSE.
    • externalId shall be set to the M2M-Ext-ID of the targeted UE hosting an ASN/MN-CSE or ADN-AE.
    • applicationPortID shall be set to Trigger-Recipient-ID attribute of the <triggerRequest> resource, if specified.
    • notificationDestination shall be configured with a URI that the SCEF can target Device Trigger notifications towards. The value of this URI shall be based on internal IN-CSE policies or IN-CSE identifier.
    • priority may be set to either PRIORITY or NO_PRIORITY per internal IN-CSE policies and/or agreements between the Service Provider and MNO or the triggerPriority attribute of the <triggerRequest> resource.
    • msisdn,requestTestNotification and websockNotifConfig are not supported by the present document and shall not be included.

General Exceptions:

  • The SCEF is not reachable when IN-CSE tries to send DeviceTriggering message. In this case the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to ERROR_NSE_NOT_FOUND after a prior timeout period (IN-CSE local policy)

Step 3b (Optional): Response to Device Triggering request

The SCEF may send a Device Triggering response to the IN-CSE to acknowledge the successful reception of the Device Trigger request before the request is delivered to the targeted UE as specified in 3GPP TS 29.122 [4]. Otherwise an HTTP error status code as defined in clause 8.3 may be returned. The response includes the following information.

  • A response code of 201 CREATED
  • The URI of the device triggering resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-device-triggering/v1/{scsAsId}/transactions{transactionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {transactionId} segment is configured by the SCEF.
  • The response payload will include a DeviceTriggering data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
    • self is configured with a URI to the resource created by the SCEF for the request
    • deliveryResult configured with one of the following status for confirmation:
      • TRIGGERED: that the request for device triggering has been received and is accepted by the SCEF but has not yet been delivered. In this case the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_TRIGGERED

General Exceptions:

If the SCEF responds with one of the error response codes defined in clause 8.3, the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_FAILED.

Step 4: Device Trigger Delivery procedure

The device trigger message shall be delivered to the UE hosting the ASN/MN-CSE or ADN-AE.

Step 5: Response to DeviceTriggering

The SCEF may send a Device Trigger response to the IN-CSE to acknowledge the successful delivery of the Device Trigger request to the targeted UE as specified in 3GPP TS 29.122 [4]. Otherwise an HTTP error status code defined in clause 8.3 may be returned. The response includes the following parameters:

  • A response code of 201 CREATED
  • The URI of the device triggering resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-device-triggering/v1/{scsAsId}/transactions{transactionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {transactionId} segment is configured by the SCEF.
  • The response payload will include a DeviceTriggering data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
    • self parameter configured with a URI to the resource created by the SCEF for the Device Trigger request.
    • deliveryResult is included in the HTTP response to indicate one of the following status for delivery of the device trigger:
      • SUCCESS: that the device triggering delivery is successfully completed. In this case the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_DELIVERED.
      • UNKNOWN: that indicates any unspecified errors. In this case the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_FAILED.
      • FAILURE: that this trigger encountered an error during delivery or processing and is deemed permanently undeliverable. In this case the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_FAILED
      • EXPIRED: that the validity period expired when processing the device triggering request. In this case the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_EXPIRED.
      • TERMINATE: that the delivery of the device triggering request is terminated by the IN-CSE. In this case the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_TERMINATED.

General Exceptions:

If the SCEF responds with one of the error response codes defined in clause 8.3, and the device trigger was initiated by an AE via a <triggerRequest> resource, the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_FAILED.

Step 6: Device Triggering Delivery Report Notification request

The SCEF sends a Device Triggering Delivery Report Notification message to the {notification_uri} of the IN-CSE with the results of the trigger delivery outcome. This message is defined in 3GPP TS 29.122 [4] and shall include the following:

  • An HTTP POST method is used
  • URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Device Triggering Request.
  • transaction is configured with a link to the related device triggering transaction resource to which this notification is related to.
  • The request payload will include a deliveryResult data structure as specified in 3GPP TS 29.122 [4]. The IN-CSE shall process the deliveryResult and update the the triggerStatus attribute of the <triggerRequest> as defined in Step 5.

Step 7: Device Triggering Delivery Report Notification response

After receiving a Device Triggering Delivery Report Notification request, the IN-CSE or AE returns a HTTP response having a response code of 204 NO CONTENT and no payload.

Steps 8 (optional) and 9: IN-CSE Updates <triggerRequest> and Response to 1a or 1b

If the device trigger was initiated by an AE via a <triggerRequest> resource, then the IN-CSE shall update triggerStatus attribute of <triggerRequest> resource.

Step 10: ASN/MN-CSE or ADN-AE performs trigger actions

If the trigger has no payload, the ASN/MN-CSE or ADN-AE shall re-establish connectivity with the IN-CSE. Otherwise, based on the type of trigger request received, the ASN/MN-CSE or ADN-AE performs the corresponding trigger actions such as establish connectivity with the IN-CSE, enrol with the MEF, register to the IN-CSE, update its PoA, or execute a CRUD request on a specified resource.

Further details are described in clause 8.3.3.2.1 of oneM2M TS0001 [1] and clause 9.2.1 of oneM2M TS-0004 [3]

7.5.2 3GPP Based Device Trigger Recall/Replace Procedure

Figure 7.5.2-1 shows a procedure for a 3GPP based Device Trigger Recall (i.e. cancel a trigger request) and Replace (i.e. update a trigger request) between oneM2M and an underlying 3GPP network.

Figure 7.5.2-1: 3GPP Based Device Triggering Recall/Replace Procedure

Figure 7.5.2-1: 3GPP Based Device Triggering Recall/Replace Procedure

Pre-condition

The IN-CSE has already sent a device trigger request to the underlying 3GPP network. The IN-CSE has stored the previous device trigger information, e.g. trigger reference number, etc.

Step 1 (Optional) IN-AE Trigger Recall/Replace Request

An AE issues a request to the IN-CSE to recall/replace a trigger (via a DELETE or UPDATE of a <triggerRequest> resource) that results in the IN-CSE generating a trigger recall/replace request to the underlying 3GPP network.

Step 2: Determine if Device Triggering is required

The IN-CSE determines whether to send a Device Trigger Recall/Replace Request to the targeted ASN/MN-CSE or ADN-AE. Further details are provided in clause 8.3.3.2.1 of oneM2M TS0001 [1].

Step 3: Device Trigger Recall or Replace Request

After identifying the proper SCEF, the IN-CSE sends a Trigger UPDATE (Replace) or DELETE (Recall) Request to the SCEF targeting the transactionID of the Device Trigger.

For an UPDATE (Replace) request, the request shall contain one or more of the following fields:

  • An HTTP PUT method shall be used
  • URI shall be set to {apiRoot}/3gpp-device-triggering/v1/{scsAsId}/transactions/{transactionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {transactionId} segment is the resource indentifier of the trigger being replaced.
  • The request payload shall include a DeviceTriggering data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • supportedFeatures shall be set to a string value of "0" indicating that trigger notifications over Websockets or trigger notification test events are not supported.
    • validityPeriod shall be set to either the triggerValidityTime attribute of the <triggerRequest> resource if the trigger request is initiated by an AE.
    • triggerPayload shall be configured as described in clause 8.3.3.2.1 of oneM2M TS 0001 [1] and clause 9.2.1 of oneM2M TS-0004 [3]. An empty payload indicates that the targeted ASN/MN-CSE or ADN-AE shall re-establish connectivity with the IN-CSE.
    • externalId shall be set to the M2M-Ext-ID of the targeted UE hosting an ASN/MN-CSE or ADN-AE.
    • applicationPortID shall be set to Trigger-Recipient-ID attribute of the <triggerRequest> resource, if specified.
    • notificationDestination shall be configured with a URI that the SCEF can target Device Trigger notifications towards. The value of this URI shall be based on internal IN-CSE policies or IN-CSE identifier.
    • priority may be set to either PRIORITY or NO_PRIORITY per internal IN-CSE policies and/or agreements between the Service Provider and MNO or the triggerPriority attribute of the <triggerRequest> resource.
    • msisdn, requestTestNotification and websockNotifConfig are not supported by the present document and shall not be included.

For an DELETE (Recall) request, the request shall contain one or more of the following fields:

  • An HTTP DELETE method shall be used
  • URI shall be set to {apiRoot}/3gpp-device-triggering/v1/{scsAsId}/transactions/{transactionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {transactionId} segment is the resource indentifier of the trigger being recalled.
  • The request shall not contain a payload

General Exceptions:

If the SCEF is not reachable when IN-CSE tries to send Device Triggering request, then the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to ERROR_NSE_NOT_FOUND after a prior timeout period (defined by IN-CSE local policy)

Step 4: Device Trigger Recall/Replace Handling

The SCEF recalls or replaces the trigger as described in 3GPP TS 23.682 [2].

Step 5: Device Trigger Recall/Replace Response

The SCEF sends a Device Trigger Response to the IN-CSE.

If the request was to replace the Device Trigger, then the response is returned by the SCEF with a 200 OK response code and a payload that includes an updated DeviceTriggering data structure as specified in 3GPP TS 29.122 [4]. The DeviceTriggering data structure also includes the deliveryResult configured with REPLACED to indicate that the request to replace the device triggering request has been accepted by the SCEF.

If the request was to recall the Device Trigger, then the response is returned by the SCEF with a 204 NO CONTENT response code and no payload is included.

See clause 8.3 for a list of possible error scenarios and error handling options for the IN-CSE.

Steps 6 and 7 (Optional): Process Device Trigger Recall/Replace Response

The IN-CSE processes the Device Trigger Recall/Replace Response. If the recall/replace request was initiated by an AE, the IN-CSE updates the corresponding <triggerRequest> resource as described in clause 8.3.3.2.1 of oneM2M TS-0001[1].

For a device trigger replace, the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_REPLACED if the device trigger was initiated by an AE via a <triggerRequest> resource.

For a device trigger recall, the IN-CSE shall delete the <triggerRequest> resource if the device trigger recall was initiated by an AE via a delete request targeting the <triggerRequest> resource.

If the SCEF responds with one of the error response codes defined in clause 8.3, and the device trigger was initiated by an AE via a <triggerRequest> resource, the IN-CSE shall update the triggerStatus attribute of the <triggerRequest> to TRIGGER_FAILED.