7.4 Monitoring events

7.4.1 UE Reachability monitoring

The 3GPP SCEF functionality described in 3GPP TS 29.122 [4] supports APIs for monitoring specific events such as UE Reachability status. This allows an SCS to request to receive reports when a device becomes reachable for receiving either SMS or downlink data. In the 3GPP interworking architecture of oneM2M, the UE hosts an ADN with one or more AEs or an ASN/MN-CSE. The UE Monitoring flow in Figure 7.4.1-1 takes place after the UE has attached to the underlying 3GPP Network and the ADN-AE(s) or ASN/MN-CSE register with the IN-CSE.

Figure 7.4.1-1: UE Reachability monitoring

Step 1 : UE attaches to the underlying 3GPP network and register s to IN-CSE

The UE attaches to the underlying 3GPP network and the ADN-AE(s) or ASN/MN-CSE hosted on the UE perform the oneM2M registration procedure, as detailed in clause 6.3. The IN-CSE hosts the corresponding <AE> or <remoteCSE> resources for the registree and an associated <node> resource.

Step 2 (Optional) : Subscribe to <schedule>

As described in clause 6.3, if at the time of ADN-AE(s) or ASN/MN-CSE registration to the IN-CSE a child <schedule> resource of the <node> resource representing the UE does not exist, the IN-CSE shall create it. If an IN-AE, ADN-AE(s) or ASN/MN-CSE is interested in receiving notifications when this <schedule> resource is updated by the IN-CSE, based on UE reachability notifications from the underlying 3GPP network, it may subscribe to this <schedule> resource.

Step 3 : Request for Monitoring Event Subscription to monitor the UE reachability

The IN-CSE sends a Monitoring Event Subscription request to the SCEF to monitor the reachability of a UE. The creation of one or more subscriptions to the node <schedule> in step 2 may be used to trigger the monitoring request if the networkCoordinated attribute of the <schedule> resource is set to TRUE.

The Monitoring Event Subscription request from the IN-CSE to the SCEF shall comply with 3GPP TS 29.122 [4]. The Monitoring Event Subscription request is configured as follows:

• An HTTP POST method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription (API for Monitoring Event Subscription) 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.
  • notificationDestination shall be set to a URI that the SCEF can target UE Reachability notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • monitoringType shall be set to UE_REACHABILITY
  • reachabilityType shall be set to DATA
  • idleStatusIndication shall be set to TRUE or FALSE. A setting of TRUE will result in the SCEF sending notifications to the IN-CSE when the UE transitions into PSM idle mode. These notifications will be in addition to any notifications sent to the IN-CSE when the UE transitions into connected mode or receives an eDRX paging occasion. A setting of FALSE (default) will result in the SCEF not sending notifications when the UE transitions into PSM idle mode. A setting of TRUE is only applicable for UEs supporting PSM. How the IN-CSE determines whether a UE supports PSM, eDRX or both is out of scope of the present document and may be configured based on Service Provider and MNO policies.
  • supportedFeatures shall be set to a string value of "2" indicating support for UE-Reachability notifications.
  • maximumNumberOfReports is optional and may be set to a maximum number of event reports to be generated by the 3GPP network entities e.g. HSS or MME/SSGN. If used, the IN-CSE shall configure this value based on Service Provider and MNO policies.
  • monitorExpireTime is optional and may be set to an absolute time at which the UE reachability monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency,maximumResponseTime and suggestedNumberOfDlPackets are not supported by the present document and shall not be included.

Step 4 : Handling in the 3GPP Network Entities

The SCEF processes the Monitoring Event Subscription request together with the 3GPP network entities, as described in 3GPP TS 29.122 [4].

Step 5 : Response to Monitoring Event Subscription

If the Monitoring Event Subscription 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 Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload will include a MonitoringEventSubscription 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
  • monitoringEventReport may be included if a monitoring event report is available.

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

Step 6 : Detection of UE changing reachability mode and reporting to SCEF

Later, when the UE transitions to connected mode (for a UE using Power Saving Mode or extended idle mode DRX) or the UE becomes reachable for paging (for a UE using extended idle mode DRX) or the UE transitions to idle mode (for a UE using Power Saving Mode), the 3GPP network entities (e.g. HSS) detect the condition and send a Monitoring Event Report for UE reachability with Idle Status Information including Idle Status Timestamp, Periodic RAU/TAU timer, Active Time, eDRX Cycle Length) to the SCEF.

Step 7 : SCEF sends Monitoring Notification to IN-CSE

When the SCEF receives information of status change in step 6, the SCEF creates and sends a Monitoring Notification message for UE reachability to the IN-CSE as specified in 3GPP TS 29.122 [4].

Otherwise, the Monitoring Notification message is sent with appropriate information in accordance with the monitoringType.

The Monitoring Notification report for UE_REACHABILITY is 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 Monitoring Event Subscription Request.
• The request payload will include a MonitoringNotification (API for Monitoring Notification) data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to
  • configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelInd shall be ignored by the IN-CSE if present since it is not supported by the present document.
  • monitoringEventReports configured with one or more UE Reachability monitoring reports wherein each report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalIDs configured with the one or more externalId that shall be included the same value of M2M-Ext-ID of the UE at step 3.
    • monitoringType configured with UE_REACHABILITY
    • idleStatusInfo configured with information such as activeTime, edrxCycleLength, suggestedNumberOfDlPackets, idleStatusTimestamp, periodicAUTimer as defined in 3GPP TS 29.122 [4]
    • reachabilityType configured with a type of reachability as defined in 3GPP TS 29.122 [4]

Step 8: UE Reachability Monitoring Notification Response

After receiving a UE Reachability Monitoring Notification, the IN-CSE responds with a 204 NO CONTENT acknowledging the notification.

Step 9 : UE Reachability Monitoring Notification Handling at the IN-CSE

The IN-CSE uses the information provided in the UE Reachability Monitoring Event Report as follows:

• If idleStatusInfo information is provided in the report, the IN-CSE shall change the scheduleElement of the UE's node <schedule> resource such that the duration of the scheduleElement is set to the value of the activeTime parameter configured in the idleStatusInfo.

Step 10a and 10b : (Optional) Notifications are sent to the entities which subscribed to changes in the <schedule> resources. This may include notifications sent to the ADN-AE(s) or ASN/MN-CSE hosted on the UE, if they have subscriptions to their respective <schedule> resources.

Step 11 : Notification of schedule update

Upon receiving notification of <schedule> resource updates, the ADN-AE(s) or ASN/MN-CSE hosted on the UE process the notification and should update their local <schedule> resources (if applicable) with the same values.

Step 12 (Optional) : request to delete Monitoring Event Subscription

The IN-CSE sends a DELETE request targeting the URI of the subscription resource corresponding to this Monitoring Event Subscription. This step may be triggered by the IN-CSE when the <node> or <schedule> resources associated with a UE are deleted or when the networkCoordinated attribute of the <schedule> resource affiliated with a UE is set to FALSE.

The request is configured as follows.

• An HTTP DELETE method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId} which is identical to step 3. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} corresponds to the one configured by the SCEF and returned to the IN-CSE when the MonitoringEventSubscription was created.
• The request shall not contain a payload

Step 13 and 14 (Optional) : Handling in 3GPP Network Entities and response to delete Monitoring Event Subscription

The SCEF processes the request to delete the Monitoring Event Subscription together with the 3GPP Network Entities.

The SCEF responds to the IN-CSE with a response either a code of 200 OK or 204 NO CONTENT indicating that it has successfully deleted the Monitoring Event Subscription.

7.4.2 UE Availability after DDN Failure

The 3GPP SCEF functionality described in 3GPP TS29.122 [4] supports APIs for monitoring of events such as UE Availability after a Downlink Data Notification (DDN) Failure. When communicating with UEs which sleep for a long time, if downlink packets are not delivered, the underlying 3GPP network recognizes that the UE is not available by a lack of a response within a reasonable time.

Per this feature, the IN-CSE can subscribe and be notified every time the UE becomes reachable after the network fails to deliver a downlink packet. For example, when this option is set and the IN-CSE receives no response to downlink traffic towards a UE, the IN-CSE can assume that the network failed to deliver the packet because the UE was sleeping and not because of Network Issues. The network later sends a notification to the IN-CSE when the UE becomes reachable.

In the underlying 3GPP network, this feature involves an entry in the UE subscription, so it is an ongoing event that needs explicit deletion to cancel further reports and it is different than the UE Reachability Monitoring Request. The feature is particularly suitable when there is just one IN-CSE.

The IN-CSE may also request Idle Status Indication. If Idle Status Indication is supported by the underlying 3GPP network, when the UE transitions into Idle mode, the report includes the time at which the UE transitioned into Idle mode, the active time and the periodic TAU/RAU time granted to the UE.

Figure 7.4.2-1: Availability after DDN Failure monitoring

Step 0 : UE Attach and oneM2M Registration Procedures

The UE attaches to the underlying 3GPP network and the ADN-AE(s) or ASN/MN-CSE hosted on the UE perform the oneM2M registration procedure, as detailed in clause 6.3. The IN-CSE hosts the corresponding <AE> or <remoteCSE> resources and an associated <node> resource for the registrees. During this procedure, a <schedule> resource is created as a child of the <node> resource. The UE hosted ADN-AE(s) or ASN/MN may subscribe to the node <schedule> resource.

If an IN-AE is interested in the reachability status of the UE, it may subscribe to the <schedule> resource if the networkCoordinated attribute of <schedule> resource is set to TRUE (step 0b, optional).

Step 1: IN-CSE sends a Monitoring Event Subscription Request to SCEF to monitor the UE Availability after a DDN Failure

This step may be triggered by the IN-CSE based on implementation options, for example after a certain number of downlink data delivery failures have occurred. The creation of a <schedule> child resource of a <node> resource may also be used to trigger the monitoring request if the networkCoordinated attribute of the <schedule> resource is set to TRUE.

The Monitoring Event Subscription request from the IN-CSE to SCEF 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-monitoring-event/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription 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.
  • notificationDestination shall be set to a URI that the SCEF can target DDN Failure notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • monitoringType shall be set to AVAILABILITY_AFTER_DDN_FAILURE
  • idleStatusIndication shall be set to TRUE or FALSE. A setting of TRUE will result in the SCEF sending notifications to the IN-CSE when the UE transitions into PSM idle mode. These notifications will be in addition to any notifications sent to the IN-CSE when the UE transitions into connected mode or receives an eDRX paging occasion. A setting of FALSE (default) will result in the SCEF not sending notifications when the UE transitions into PSM idle mode. A setting of TRUE is only applicable for Ues supporting PSM. How the IN-CSE determines whether a UE supports PSM, eDRX or both is out of scope for the present document and may be configured based on Service Provider and MNO policies.
  • supportedFeatures shall be set to a string value of "7" indicating support for availability after DDN Failure notifications.
  • maximumNumberOfReports is optional and may be set to a maximum number of event reports to be generated by 3GPP network entities e.g. HSS or MME/SSGN. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • monitorExpireTime is optional and may be set to an absolute time at which the monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency and maximumResponseTime are not supported by the present document and shall not be included.

Note

It is recommended that Idle Status monitoring is enabled in conjunction with the Availability after DDN Failure monitoring. This enables the IN-CSE to update the <schedule> resource with updated timing information, once the UE transitions to idle again.

Step 2 and 3 : Monitoring Event Subscription Request Handling in the u nderlying 3GPP n etwork

The SCEF handles the Monitoring Event Subscription Request together with the Mobile Core Network, as described in 3GPP TS23.682[2]. The SCEF sends a Monitoring Event Subscription Response message to the IN-CSE to acknowledge acceptance of the Monitoring Event Subscription Request.

The message includes the following information.

• A response code of 201 CREATED
• The URI of the Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload will include a MonitoringEventSubscription 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
  • monitoringEventReport may be included if a monitoring event report is available.

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

Step 4 : DL Data is sent to the UE

Downlink data is sent to the UE which, in the underlying 3GPP network, involves sending a Downlink Data Notification (DDN) message to the MME, and MME initiates paging of UE.

Step 5a : DDN Failure

The underlying 3GPP network diagnoses a DDN Failure when, after DDN, no response to the UE paging is received and if the UE is in PSM mode (not every DDN failure triggers this event), the UE subscription is updated to reflect that a notification of availability should be sent after this DDN failure.

Step 5b : Request failure handling

The IN-CSE may also diagnose the failure when no response to the DL data has been received. It is up to implementation if the IN-CSE changes the node <schedule> resource at this point to indicate that communications are not available (e.g. by using a keyword such as "NULL"), or just records it as a one-time response failure. Other alternatives for implementation are, for example, for the IN-CSE to change the node <schedule> resource to indicate that communications are not available only after a pre-provisioned number of requests fail. The IN-CSE may also buffer future requests or enlarge its buffer size.

Step 6 : Available after DDN Failure

At a later time, the UE contacts the network, e.g., to perform a TAU, or as it executes a service request. The underlying 3GPP network notes that the UE is available and that an availability notification is requested in the subscription. A Monitoring Indication that the UE is available is sent to the SCEF.

Step 7 : SCEF sends a DDN Failure Monitoring Notification Request to IN-CSE

When the SCEF receives information of status change to available communication, the SCEF creates and sends a Monitoring Notification message for AVAILABILITY_AFTER_DDN_FAILURE to the IN-CSE as specified in 3GPP TS 29.122 [4].

Otherwise, the Monitoring Notification message is sent with appropriate information in accordance with the monitoringType.

The SCEF sends a DDN Failure Monitoring Notification Report to the IN-CSE as specified in 3GPP TS 29.122 [4], indicating that the UE is available, including:

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Monitoring Event Subscription Request.
• The request payload will include a MonitoringNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to
  • configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelind shall be ignored by the IN-CSE if present since it is not supported by the present document.
  • monitoringEventReports configured with one or more DDN Failure monitoring reports wherein each report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalIDs configured with one or more externalID that will be configured with the same values of M2M-Ext-ID of the UE in step 1.
    • monitoringType configured with AVAILABILITY_AFTER_DDN_FAILURE
    • idleStatusInfo configured with information such as activeTime, edrxCycleLength, suggestedNumberOfDlPackets, idleStatusTimestamp, periodicAUTimer as defined in 3GPP TS 29.122 [4]

Step 8 : DDN Failure Monitoring Notification Response

After receiving a DDN Failure Monitoring Notification, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Step 9a and 9b: Availability after DDN Failure Handling at the IN-CSE

The IN-CSE uses the information provided in the Monitoring Notification Report to update the node <schedule> to indicate that the UE is available.

A new scheduleElement shall be created that indicates that the node is available for communication starting immediately and will remain available for at least the duration specified by the Maximum Response Time parameter.

Later (step 9b, optional) IN-AE(s) or the IN-CSE may decide to resend data queued for the UE.

Step 10 : UE transitions to Idle

UE transitions to idle mode. If Idle Status Indication was requested during Monitoring Event configuration, and the MCN supports Idle Status Indication, then the SCEF is provided with an indication which includes the time at which the UE transitioned into idle mode, the active time and the periodic TAU/RAU timer values.

Step 11 : SCEF sends a UE Reachability Monitoring Event Notification Request to IN-CSE

The SCEF provides a Monitoring Event Notification Request to the IN-CSE as specified in 3GPP TS 29.122 [4], including:

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Monitoring Event Subscription Request.
• The request payload will include a MonitoringNotification (API for Monitoring Notification) data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelind shall be ignored by the IN-CSE if present since it is not supported by the present document.
  • monitoringEventReports configured with one or more UE Reachability monitoring reports wherein each report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalIDs configured with one or more externalIDs that will be configured with the same values of M2M-Ext-ID of the UE as step 1.
    • monitoringType configured with UE_REACHABILITY
    • idleStatusInfo configured with information such as activeTime, edrxCycleLength, suggestedNumberOfDlPackets, idleStatusTimestamp, periodicAUTimer as defined in 3GPP TS 29.122 [4]

Step 12: Monitoring Event Notification Response

After receiving a Monitoring Event Notification, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Step 13 : UE Idle mode indication Handling at the IN-CSE

The IN-CSE uses the UE Idle status information to update the <schedule> child resource of the <node> resource.

The IN-CSE changes the <schedule> resource such that:

• the start of the scheduleElement is based on the Idle Timestamp, with a periodicity equal to the TAU/RAU Timer.
• the duration of the scheduleElement indicates the Active Time value.

When any traffic is received from the node or an Availability Notification is received for the node, any scheduleElement (s) that were created based on prior Idle Status Indications shall be deleted for the node. A new scheduleElement shall be created that indicates that the node is available for downlink communication starting immediately and will remain available for at least the duration specified by the Maximum Response Time parameter.

Step 14 (Optional) : IN-CSE sends request to SCEF to delete Monitoring Event Subscription

The IN-CSE sends a DELETE request targeting the URI of the subscription resource corresponding to this Monitoring Event Subscription. This step may be triggered by IN-CSE when the <node> or <schedule> resources associated with a UE are deleted or when the networkCoordinated attribute of the <schedule> resource affiliated with a UE is set to FALSE .

The request is configured as follows.

• An HTTP DELETE method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId} which is identical to step 1. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} corresponds to the one configured by the SCEF and returned to the IN-CSE when the MonitoringEventSubscription was created.
• The request shall not contain a payload

Step 15 and 16 (Optional) : Monitoring Event Subscription Delete Request Handling in the underlying 3GPP network

The SCEF handles the request to delete Monitoring Event Subscription together with the 3GPP network entities. The SCEF returns a response to the IN-CSE with a response code of 204 NO CONTENT to acknowledge the Monitoring Event Subscription has been deleted.

7.4.3 UE Communication Failure

The 3GPP SCEF Event Monitoring functionality described in 3GPP TS 29.122 [4] supports an API to allow an IN-CSE to be informed when the UE communication failure occurs. Informing the IN-CSE that UEs have suffered communication failures in the underlying 3GPP network helps optimize communications. For example, the IN-CSE may stop attempting to communicate with the UE if it is aware of repeated communication failures.

The UE Communication Failure Monitoring flow is assumed to take place after the UE has attached to the underlying 3GPP Network and registered with the IN-CSE.

Figure 7.4.3-1: Communication Failure monitoring

Step 0: UE Attach and oneM2M Registration Procedures

The UE attaches to the underlying 3GPP network and the ADN-AE(s) or ASN/MN-CSE hosted on the UE perform the oneM2M registration procedure, as detailed in clause 6.3. The IN-CSE hosts the corresponding <AE> or <remoteCSE> resources and an associated <node> resource for the registree. During this procedure, a <schedule> resource is created as a child of the <node> resource. The UE hosted ADN-AE(s) or ASN/MN may subscribe to the node <schedule> resource.

If an IN-AE is interested in the communication failure status of the UE, it may subscribe to the node <schedule> resource (step 0b, optional).

Step 1: IN- CSE sends a Monitoring Event Subscription Request to SCEF to monitor the UE Communication Failure

This step may be triggered by an IN-CSE based on implementation options, for example when a type of communication requiring high reliability is scheduled to occur. The creation of a <schedule> child resource of a <node> resource may also be used to trigger the monitoring request if the networkCoordinated attribute of <schedule> resource is set to TRUE.

The Monitoring Event Subscription request from the IN-CSE to SCEF 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-monitoring-event/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription (API for Monitoring Event Subscription) 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.
  • notificationDestination shall be set to a URI that the SCEF can target Communication Failure notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • monitoringType shall be set to COMMUNICATION_FAILURE
  • supportedFeatures shall be set to a string value of "6" indicating support for Communication Failure notifications.
  • maximumNumberOfReports is optional and may be set to a maximum number of event reports to be generated by 3GPP network entities e.g. HSS or MME/SSGN. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • monitorExpireTime is optional and may be set to an absolute time at which the monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
• msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency and maximumResponseTime are not supported by the present document and shall not be included.

Note

It is recommended that Idle Status monitoring is enabled in conjunction with the Availability after DDN Failure monitoring. This enables the IN-CSE to update the <schedule> resource with updated timing information, once the UE transitions to idle again.

Step 2 : -Step 3 : Monitoring Event Subscription Request Handling in the underlying 3GPP Network

Editor note: the heading for step 2 and 3 should be separated. Is there a step 2?

The SCEF handles the Monitoring Event Subscription Request together with the 3GPP network entities, as described in 3GPP TS29.122 [4]. The SCEF sends a Monitoring Event Subscription Response message to the IN-CSE to acknowledge acceptance of the Monitoring Event Subscription Request.

The message includes the following information.

• A response code of 201 CREATED
• The URI of the Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload will include a MonitoringEventSubscription 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
  • monitoringEventReport may be included if a monitoring event report is available.

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

Step 4 : Detection of Communication Failure and reporting to SCEF

Later, when the UE communication failure occurs the condition is detected in the underlying 3GPP network and the SCEF receives a Monitoring Event Report.

Step 5 : SCEF sends U E Communication Failure Monitoring Event Notification Request to IN-CSE

When the SCEF receives information of status change of the UE, the SCEF sends a Monitoring Notification Report to the IN-CSE for UE communication failure information as specified in 3GPP TS 29.122 [4].

Otherwise, the Monitoring Notification message is sent with appropriate information in accordance with the monitoringType.

The Monitoring Notification report for COMMUNICATION_FAILURE includes:

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Monitoring Event Subscription Request.
• The request payload will include a MonitoringNotification (API for Monitoring Notification) data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to.
  • configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelind shall be ignored by the IN-CSE if present since it is not supported by the present document.
  • monitoringEventReports configured with one or more Communication Failure monitoring reports wherein each report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalID configured with one or more externalID that will be configured with the same value of M2M-Ext-ID of the UE as step 1.
    • monitoringType configured with COMMUNICATION_FAILURE
    • failureCause configured with a reason of communication failure such as bssgpCause, causeType, gmmCause, ranapCause, ranNasCause, s1ApCause and smCause.

Step 6: UE Communication Failure Monitoring Event Notification Response

After receiving a UE Communication Failure Monitoring Notification for communication failure, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Step 7 : Communication Failure Handling at the IN-CSE

The IN-CSE uses the information provided in the Monitoring Notification Report to update the scheduleElement of the <schedule> resource to indicate that no communications are currently available (e.g. by using a keyword such as "NULL"). Local IN-CSE policies may specify events/ thresholds further defining when the IN-CSE may provide the <schedule> resource update. For example, the update may be provided only after repeated communication failures are received within a timespan, or only if high reliability communications are expected. It is recommended that UE Reachability monitoring is also enabled in conjunction with the Communication Failure monitoring. This enables the IN-CSE to provide updated timing information in the <schedule> resource, once the UE becomes reachable again.

Step 8 : (Optional) Notifying subscribers

Optionally, notifications may sent to the subscribers of the <schedule> resource.

Step 9 (Optional) : IN-CSE sends request to SCEF to delete Monitoring Event Subscription

The IN-CSE sends a DELETE request targeting the URI of the subscription resource corresponding to this Monitoring Event Subscription. This step may be triggered by IN-CSE when a ADN-AE(s) or ASN/MN-CSE hosted on the UE de-registers from the IN-CSE or when the networkCoordinated attribute of the <schedule> resource affiliated with an ADN-AE or ASN/MN-CSE hosted on a UE is set to FALSE.

The request is configured as follows.

• An HTTP DELETE method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId} which is identical to step 1. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} corresponds to the one configured by the SCEF and returned to the IN-CSE when the MonitoringEventSubscription was created.
• The request shall not contain a payload

Step 10 and 11 (Optional) : Monitoring Event Subscription Delete Request Handling in the u nderlying 3GPP n etwork

The SCEF handles request to delete the Monitoring Event Subscription together with the 3GPP network entities. The SCEF responds to the IN-CSE with a response code of 204 NO CONTENT to acknowledge the Monitoring Event Subscription has been deleted.

7.4.4 UE Loss of Connectivity

An IN-CSE can communicate with large numbers of devices, many of which are reachable for short periods of time. An IN-CSE may want to be informed when devices are not reachable to the underlying 3GPP network, to better manage its communications. For example, IN-AEs which normally communicate with the device might not attempt communications if neither signalling or user plane communication are available.

The 3GPP SCEF functionality described in 3GPP TS 29.122 [4] supports APIs for monitoring specific events such as UE Loss of Connectivity Monitoring. The Loss of Connectivity Monitoring Event subscription allows the IN-CSE to provide to the network a Maximum Detection Time, which indicates the maximum period of time without any communication between the UE and Network after which the IN-CSE is to be informed that the device is considered to be unreachable.

The Maximum Detection Time of loss of connectivity is on the order of 1 minute to multiple hours. A timer with the order of magnitude of a few minutes can only apply to a limited number of devices due to the network signalling cost.

Note

In the underlying 3GPP Network, the Maximum Detection Time of loss of connectivity can be used to determine the order of magnitude of the Periodic Update timer.

The UE Loss of Connectivity Monitoring flow is assumed to take place after the UE has attached to the underlying 3GPP Network and registered with the IN-CSE.

Figure 7.4.4-1: Loss of Connectivity monitoring

Step 0: UE Attach and oneM2M Registration Procedures

The UE attaches to the underlying 3GPP network and the ADN-AE(s) or ASN/MN-CSE hosted on the UE perform the oneM2M registration procedures, as detailed in clause 6.3. The IN-CSE hosts the corresponding <AE> or <remoteCSE> resources for the registree, and an associated <node> resource. During this procedure, a <schedule> resource is created as a child of the <node> resource and the networkCoordinated attribute of the <schedule> resource is set to TRUE.

If an IN-AE is interested in the reachability status of the UE, it may subscribe to the <schedule> resource (step 0b, optional).

Step 1: IN- CSE sends a Monitoring Request to SCEF to monitor the UE Loss of Connectivity

This step may be triggered by the IN-CSE on creation of a <schedule> child resource of a <node> resource if the networkCoordinated attribute of the <schedule> resource is set to TRUE.

The Monitoring Event Subscription request from the IN-CSE to SCEF 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-monitoring-event/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription 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.
  • notificationDestination shall be set to a URI that the SCEF can target Loss of Connectivity notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • monitoringType shall be set to LOSS_OF_CONNECTIVITY
  • supportedFeatures shall be set to a string value of "1" indicating support for Loss of Connectivity notifications.
  • maximumNumberOfReports is optional and may be set to a maximum number of event reports to be generated by 3GPP network entities e.g. HSS or MME/SSGN. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • monitorExpireTime is optional and may be set to an absolute time at which the monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency, maximumResponseTime and suggestedNumberOfDlPackets are not supported by the present document and shall not be included.
  • maximumDetectionTime shall be set per IN-CSE pre-provisioning. This value should be set to a value that is longer than the length of time of inactive communications as configured in the <schedule> resource
  • msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency and maximumResponseTime are not supported by the present document and shall not be included.

Step 2 and Step 3 : Monitoring Request Handling in the u nderlying 3GPP n etwork

The SCEF handles the Monitoring Event Subscription Request together with the 3GPP network entities, as described in 3GPP TS29.122 [4]. The SCEF sends a Monitoring Event Subscription Response message to the IN-CSE to acknowledge acceptance of the Monitoring Event Subscription Request.

The message includes the following information.

• A response code of 201 CREATED
• The URI of the Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload will include a MonitoringEventSubscription 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
  • monitoringEventReport may be included if a monitoring event report is available.

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

Step 4 : Detection of Loss of Connectivity and reporting to SCEF

Later, when the UE loses connectivity, the 3GPP network entities (e.g. MME) detect the condition and sends a Monitoring Event Report to SCEF

Step 5 : SCEF sends UE Loss of Connectivity Monitoring Notification Request to IN-CSE

The SCEF sends a Monitoring Event Notification Request to the IN-CSE when receiving the Monitoring Report that contains information as specified in 3GPP TS 29.122 [4]. Such information includes:

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Monitoring Event Subscription Request.
• The request payload will include a MonitoringNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to
  • configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelind shall be ignored by the IN-CSE if present since it is not supported by the present document
  • monitoringEventReports configured with one or more Loss of Connectivity monitoring reports wherein each report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalIDs configured with one or more externalID that will be configured with the same value of M2M-Ext-ID of the UE as step 1.
    • monitoringType configured with LOSS_OF_CONNECTIVITY
    • lossOfConnectReason configured with the reason for loss of connectivity as defined in 3GPP TS 29.122 [4]

Step 6: UE Loss of Connectivity Monitoring Event Notification Response

After receiving a UE Loss of Connectivity Monitoring Notification, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Step 7 : Loss of Connectivity Handling at the IN-CSE

The IN-CSE uses the information provided in the Monitoring Notification Report to update the <schedule> child resource of the <node> resource to indicate that no communications are currently available (e.g. by using a keyword such as "NULL"). Updates to the <schedule> resource will be performed only if its networkCoordinated attribute is set to TRUE.

Note

It is recommended that UE Reachability monitoring is also enabled in conjunction with the Loss of Connectivity monitoring. This enables the IN-CSE to provide updated timing information in the <schedule> resource, once the UE becomes reachable again.

Step 8 : (Optional) Notifying subscribers

Optionally, if IN-AEs have subscribed to changes in the <schedule> resources a notification will be sent to the subscribers.

Step 9 (Optional) : IN-CSE sends request to SCEF to delete Monitoring Event Subscription

The IN-CSE sends a DELETE request targeting the URI of the subscription resource corresponding to this Monitoring Event Subscription. This step may be triggered by IN-CSE when a ADN-AE(s) or ASN/MN-CSE hosted on the UE de-registers from the IN-CSE or when the networkCoordinated attribute of the <schedule> resource affiliated with an ADN-AE or ASN/MN-CSE hosted on a UE is set to FALSE.

The request is configured as follows.

• An HTTP DELETE method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId} which is identical to step 1. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} corresponds to the one configured by the SCEF and returned to the IN-CSE when the MonitoringEventSubscription was created.
• The request shall not contain a payload

Step 10 and 11 (Optional) : Monitoring Event Subscription Delete Request Handling in the underlying 3GPP network

The SCEF handles the request to delete Monitoring Event Subscription together with the 3GPP network entities. The SCEF responds to the IN-CSE with a response code of 204 NO CONTENT to acknowledge the Monitoring Event Subscription has been deleted.

7.4.5 Detecting Change of IMSI-IMEI(SV) Association

The 3GPP SCEF Event Monitoring functionality described in 3GPP TS 29.122 [4] supports an API that allows the IN-CSE to be informed when the SIM card of one physical device is placed in another physical device. This condition is detected by the underlying 3GPP network when the association between the International Mobile Subscriber Identity (IMSI) and International Mobile Equipment Identity (IMEI/IMEISV) changes.

An IN-CSE may request to receive notifications from an underlying 3GPP network when the association between the IMSI and IMEI(SV) changes for a given UE that hosts one or more ASN/MN-CSEs or ADN-AEs registered to the IN-CSE. Based on this notification, the IN-CSE may then ignore incoming requests from these ASN/MN-CSEs or ADN-AEs.

Figure 7.4.5-1: Change of IMSI-IMEI(SV) Association Monitoring Request and Notification

Pre-conditions:

There is a relationship in place between the IN-CSE and MNO allowing the IN-CSE to request notifications for IMSI-IMEI(SV) association changes.

An ASN/MN-CSE or ADN-AE registers with the IN-CSE and configures the M2M-Ext-ID attribute of its <remoteCSE> or <AE> resource. The IN-CSE examines the M2M-Ext-ID and recognizes that it is associated with an MNO that it has a relationship with. The relationship allows the IN-CSE to request notifications when the device's IMSI-IMEI(SV) association changes.

Step 1: IN-CSE requests notification for changes in IMSI-IMEI(SV) association

The IN-CSE determines whether it wants a notification if the IMSI-IMEI(SV) association of a particular UE hosting one or more ASN/MN-CSEs or ADN-AEs changes. This determination may be based on whether the IN-CSE has an established relationship with the MNO that supports this capability and provisioned policies.

Step 2 : Monitoring Event Subscription Request

The IN-CSE sends a request to be notified when the device's IMSI-IMEI(SV) association changes. The Monitoring Event Subscription Request contains information as specified in 3GPP TS 29.122 [4] which includes the following:

• An HTTP POST method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription 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.
  • notificationDestination shall be set to a URI that the SCEF can target Change of IMSI/IMEI Association notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • monitoringType shall be set to CHANGE_OF_IMSI_IMEI_ASSOCIATION
  • supportedFeatures shall be set to a string value of "4" indicating support for Change of IMSI/IMEI Association notifications.
  • maximumNumberOfReports is optional and may be set to a maximum number of event reports to be generated by 3GPP network entities e.g. HSS or MME/SSGN. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • monitorExpireTime is optional and may be set to an absolute time at which the monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • associationType shall be set to IMEI or IMEISV. The type that is used is based on IN-CSE policies which may be based on the relationship between the Service Provider and MNO
  • msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency, maximumDetectionTime and maximumResponseTime are not supported by the present document and shall not be included.

Step 3 : Process Monitoring Event Subscription Request

The SCEF processes the Monitoring Event Subscription request together with 3GPP network entities.

Step 4 : Monitoring Event Subscription Response

The SCEF sends a Monitoring Event Subscription Response message to the IN-CSE to acknowledge acceptance of the Monitoring Event Subscription Request.

The message includes the following information.

• A response code of 201 CREATED
• The URI of the Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload will include a MonitoringEventSubscription 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
  • monitoringEventReport may be included if a monitoring event report is available.

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

Step 5 : Detect change in IMSI-IMEI(SV) association

The 3GPP network entities monitor and detect a IMSI-IMEI(SV) association change and reports Monitoring Event Report to SCEF .

Step 6 : Monitoring Notification report

When the SCEF receives information of status change on IMSI-IMEI(SV) association, the SCEF sends a Monitoring Notification to the corresponding notificationDestination of the IN-CSE that was configured in the Monitoring Event Subcription Request and that contains information as specified in 3GPP TS 29.122 [4].

Otherwise, the MonitoringNotification message is sent with appropriate information in accordance with the monitoringType.

The Monitoring Notification report for CHANGE_OF_IMSI_IMEI_ASSOCIATION includes:

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Monitoring Event Subscription Request at step 2.
• The request payload will include a MonitoringNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to
  • configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelind shall be ignored by the IN-CSE if present since it is not supported by the present document
  • monitoringEventReports configured with one or more Loss of Connectivity monitoring reports wherein each report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalIDs configured with one or more externalID that will be configured with the same value of M2M-Ext-ID of the UE as step 2.
    • monitoringType configured with CHANGE_OF_IMSI_IMEI_ASSOCIATION
    • associationType configured with IMSI-IMEI or IMSI-IMEISV

Step 7 : Monitoring Notofication Response

After receiving a Change of IMSI-IMEI Association Monitoring Event Notification, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Step 8 : Process Notification

The IN-CSE shall stop servicing requests from any ASN/MN-CSEs or ADN-AEs having an M2M-Ext-ID matching the one indicated in the report. To block these requests, the IN-CSE may tear down any active security associations (e.g. D/TLS sessions) between the IN-CSE and these ADN-AEs or ASN/MN-CSEs. In addition, the IN-CSE may also deny new security association establishment requests from any ADN-AEs or ASN/MN-CSEs that have an M2M-Ext-ID matching the one indicated in the report until the restriction is removed via administrative means which are outside the scope of the present document.

Step 9 (Optional) : IN-CSE sends request to SCEF to delete Monitoring Event Subscription

The IN-CSE sends a DELETE request targeting the URI of the subscription resource corresponding to this Monitoring Event Subscription. This step may be triggered by IN-CSE when a ADN-AE(s) or ASN/MN-CSE hosted on the UE de-registers from the IN-CSE.

The request is configured as follows.

• An HTTP DELETE method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId} which is identical to step 2. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} corresponds to the one configured by the SCEF and returned to the IN-CSE when the MonitoringEventSubscription was created.
• The request shall not contain a payload

Step 10 and 11 (Optional) : Monitoring Event Subscription Delete Request Handling in the u nderlying 3GPP n etwork.

The SCEF handles the request to delete Monitoring Event Subscription together with the 3GPP network entities. The SCEF responds to the IN-CSE with a response code of 204 NO CONTENT to acknowledge the Monitoring Event Subscription has been deleted.

7.4.6 Roaming Status

The 3GPP SCEF Monitoring functionality described in 3GPP TS 29.122 [4] supports an API to allow an IN-CSE to be informed when the roaming status of a UE in the underlying 3GPP network changes.

An IN-CSE may request to receive indications from an underlying 3GPP network when the roaming status of a 3GPP UE hosting an ASN/MN-CSE or ADN-AE changes. Based on these indications, the IN-CSE may buffer requests for ASN/MN-CSEs or ADN-AEs that are hosted on roaming UEs and send these requests when they are no longer roaming. The determination of whether to buffer requests may be based on system policies that are outside the scope of the current document. An IN-CSE may also make the roaming status of ASN/MN-CSEs or ADN-AEs available to IN-AEs such that they can use this status to determine whether to avoid and or delay communications until they are no longer roaming.

Figure 7.4.6-1: Request for Roaming Status Indications

Pre-conditions:

There is a relationship in place between the IN-CSE and MNO allowing the IN-CSE to request Roaming Status Reports from the underlying 3GPP network. The method for establishing this relationship is outside the scope of the present document.

An ASN/MN-CSE or ADN-AE registers with the IN-CSE and configures the M2M-Ext-ID attribute of its <remoteCSE> or <AE> resource. The IN-CSE examines the M2M-Ext-ID and recognizes that it is associated with an MNO that it has a relationship with.

The ASN/MN-CSE or ADN-AE or IN-CSE creates a <node> resource. This <node> resource has roamingStatus and networkID attributes.

An IN-AE may subscribe to the IN-CSE to receive notifications when the roaming status of a ASN/MN-CSE or ADN-AE changes. This subscription is made to the roamingStatus and/or networkID attributes of the <node> resource.

The IN-CSE may be configured with policies to control whether to buffer requests targeting ASN/MN-CSEs or ADN-AEs hosted on 3GPP Ues that are roaming. The method for configuring these policies is outside the scope of the present document.

Step 1: IN-CSE determines to monitor Roaming Status Request

If the IN-CSE can resolve the M2M-Ext-ID to a SCEF and IN-CSE policies allow for it, the IN-CSE issues a Roaming Status Request.

Note

These IN-CSE policies are outside the scope of the present document.

Step 2 : Request Monitoring Event Subscription to monitor Roaming Status

The IN-CSE requests to monitor roaming status reports using Monitoring Event Subscription which has specified in 3GPP TS 29.122 [4] for a particular ASN/MN-CSE or ADN-AE hosted on a UE. The fields of the MonitoringEventSubscription API are populated as follows.

• An HTTP POST method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription 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.
  • notificationDestination shall be set to a URI that the SCEF can target Roaming Status notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • monitoringType shall be set to ROAMING_STATUS
  • supportedFeatures shall be set to a string value of "5" indicating support for Roaming Status notifications.
  • maximumNumberOfReports is optional and may be set to a maximum number of event reports to be generated by 3GPP network entities e.g. HSS or MME/SSGN. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • monitorExpireTime is optional and may be set to an absolute time at which the monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • pLMNIndication shall be set to TRUE or FALSE to indicate whether the IN-CSE wants to know the identity of the PLMN that the UE is attached to.
  • msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency, maximumDetectionTime and maximumResponseTime are not supported by the present document and shall not be included.

Step 3 : Process Monitoring Event Subscription to monitor Roaming Status

The SCEF processes the Monitoring Event Subscription request together with 3GPP network entities as described in 3GPP TS 29.122 [4].

Step 4 : Response for Monitorinf Event Subscription to monitor Roaming Status

The SCEF sends a Monitoring Event Subscription Response message to the IN-CSE to acknowledge acceptance of the Monitoring Event Subscription Request.

The message includes the following information.

• A response code of 201 CREATED
• The URI of the Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload will include a MonitoringEventSubscription 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
  • monitoringEventReport may be included if a monitoring event report is available.

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

Step 5 : Detect Roaming Status Change in 3GPP network entities

When the 3GPP network entities detect the change of UE roaming status, the 3GPP network entities report Monitoring Event Report to the SCEF.

Step 6 : Monitoring Notification for Roaming Status from SCEF to IN-CSE

When the SCEF receives information of roaming status, the SCEF sends a Monitoring Notification to the corresponding notificationDestination of the IN-CSE that was configured in the Monitoring Event Subscription Request and that contains information as specified in 3GPP TS 29.122 [4].

Otherwise, the MonitoringNotification message is sent with appropriate information in accordance with the monitoringType

The Monitoring Notification report for roaming status includes:

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Monitoring Event Subscription Request.
• The request payload will include a MonitoringNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to
  • configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelind shall be ignored by the IN-CSE if present since it is not supported by the present document
  • monitoringEventReports configured with one or more change of Roaming Status monitoring reports wherein each report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalIDs configured with one or more externalID that will be configured with the same values of the M2M-Ext-ID of the UE as step 2.
    • monitoringType configured with ROAMING_STATUS
    • plmnId if pLMNIIndication in the Monitoring Event Subscription was set to TRUE, this parameter is included and indicate the UE's serving PLMN
    • roamingStatus is configured with ROAMING or NOT_ROAMING

Step 7 : Response for Monitoring Notification from IN-CSE to SCEF

After receiving a Monitoring Notification on roaming status, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Step 8 : Process Monitoring Notification at IN-CSE

The IN-CSE shall update the roamingStatus and networkID attributes of the <node> resource that is linked to_<AE_> or <remoteCSE> resources having a M2M-Ext-ID attribute that matches the M2M-Ext-ID configured in the Roaming Status Request.

In addition, the IN-CSE may determine to delay or reject the processing of requests targeting ASN/MN-CSEs or ADN-AEs hosted on roaming UEs via one or more of the following approaches. How the IN-CSE makes this determination is outside the scope of the current document and may be based on policies and agreements with the MNO.

• An IN-CSE may reject requests that target ASN/MN-CSEs or ADN-AEs hosted on roaming UEs. If an IN-CSE rejects a request due to a roaming UE, it shall return a corresponding response code informing the cause of rejection is due to lack of accessibility to a roaming network node.
• An IN-CSE may delay the processing of requests (i.e. buffer) that target ASN/MN-CSEs or ADN-AEs hosted on roaming UEs.
  • If the request is a blocking request, the IN-CSE should not delay the processing of the request and should instead reject the request with a corresponding response code informing the cause of rejection is due to the destination node is roaming.
  • If the request includes an Event Category that is set to immediate the IN-CSE should not delay the processing of the request and should instead reject the request with a corresponding response code informing the cause of rejection is due to the destination node is roaming. In this case, the IN-AE may decide to resubmit the request with the Event Category set to "bestEffort" or "latest" to indicate the IN-CSE may buffer the request.

Step 9 (Optional) : Request to delete Monitoring Event Subscription on Roaming Status

The IN-CSE sends a DELETE request targeting the URI of the subscription resource corresponding to this Monitoring Event Subscription. This step may be triggered by IN-CSE when a ADN-AE(s) or ASN/MN-CSE hosted on the UE de-registers from the IN-CSE.

The request is configured as follows.

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

Steps 10 and 11 (Optional) : Process Roaming Status Cancellation Request

The SCEF handles the request to delete Monitoring Event Subscription together with the 3GPP network entities. The SCEF responds to the IN-CSE with a response code of 204 NO CONTENT to acknowledge the Monitoring Event Subscription has been deleted

7.4.7 Location Reporting

7.4.7.1 Introduction

The 3GPP SCEF Event Monitoring functionality described in 3GPP TS 29.122 [4] supports an API to allow an IN-CSE to be informed when the 3GPP network entities detect the current location of a UE as well as the last known location of UE. This clause provides details on how the IN-CSE's oneM2M <locationPolicy>, <container> and <contentInstance> resources are used to interwork with the T8 API and provide location monitoring capability for an ASN/MN-CSE or ADN-AE hosted on a 3GPP UE. To interwork the 3GPP location reporting functionality with oneM2M, the <locationPolicy>, <container> and <contentInstance> resources and corresponding procedures are used.

7.4.7.2 Location updating triggered by retrieval

Figure 7.4.7.2-1: Location updating triggered by retrieving

Step 1: Request for creation of <locationPolicy>

The IN-AE sends a <locationPolicy> create request which shall include following parameters as specified in clause 9.6.10 of oneM2M TS-0001 [1]:

• locationSource shall be set to Network Based.
• locationUpdatePeriod shall not be present or set to 0.
• locationTargetID shall be set to the M2M-Ext-ID of the targeted UE hosting an ASN/MN-CSE or ADN-AE.
• locationServer shall not be present.
• locationContainerID shall not be present.
• locationInformationType shall be set to position fix.
• retrieveLastKnownLocation shall be configured with either TRUE or FALSE based on the requirements of the IN-AE.
• locationUpdateEventCriteria shall not be present.

Step 2: Responds to creation < locationPolicy>

IN-CSE shall create the <locationPolicy> resource and corresponding <container> resource for storing location information based on the procedure specified in clause 10.2.9 of oneM2M TS-0001 [1].

Step 3: Retrieve Request for <latest>

The IN-AE sends a RETRIEVE request to the <latest> child resource of the <container> resource linked to the to <locationPolicy> created in Step 2.

Step 4: Request Monitoring Event Subscription to get Current Location

The IN-CSE checks the locationSource attribute of the <locationPolicy> resource that is linked to the <container> targeted by the RETRIEVE request in Step 3. If the locationSource attribute is set to Network Based and the locationUpdatePeriod attribute is set to zero or NULL, then the IN-CSE shall request a Monitoring Event Subscription to get current location to the SCEF. The Monitoring Event Subscription request shall contain the following information as specified in 3GPP TS 29.122 [4].

• An HTTP POST method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • externalId shall be set to the locationTargetID.
  • notificationDestination shall be set to a URI that the SCEF can target Location Reporting notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • monitoringType shall be set to LOCATION_REPORTING
  • supportedFeatures shall be set to a string value of "3" indicating support for Location Reporting notifications.
  • maximumNumberOfReports is optional and may be set to a maximum number of event reports to be generated by 3GPP network entities e.g. HSS or MME/SSGN. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • monitorExpireTime is optional and may be set to an absolute time at which the monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • locationType shall be set to CURRENT_LOCATION
  • accuracy shall be set set by the IN-CSE (e.g. CGI_ECGI, ENODEB, TA_RA, PLMN or TWAN_ID )
  • msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency, maximumDetectionTime and maximumResponseTime are not supported by the present document and shall not be included.

Step 5: Process Monitoring Event Subscription to get Current Location

The SCEF handles request for Monitoring Event Subscription togather with 3GPP network entities based on the procedure defined in 3GPP TS 29.122 [4].

Step 6: Response to Monitoring Event Subscription for Current Location

The SCEF sends a Monitoring Event Subscription Response message to the IN-CSE to acknowledge acceptance of the Monitoring Event Subscription Request.

The message includes the following information.

• A response code of 201 CREATED
• The URI of the Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId} which is identical to step 4. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload will include a MonitoringEventSubscription 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
  • monitoringEventReport may be included if a monitoring event report is available.

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

Step 7: Detect Current Location of UE

The 3GPP network entities detect the current location of UE and the SCEF receives a Monitoring Event Report for the location of UE.

Step 8: SCEF sends Monitoring Notification Report to IN-CSE

When the SCEF receives a current location information from the 3GPP network entities, the SCEF sends Monitoring Notification Report to the IN-CSE that contains information as specified in 3GPP TS 29.122 [4]. Otherwise, the MonitoringNotification message is sent with appropriate information in accordance with the monitoringType.

The Monitoring Notification report for LOCATION_REPORTING for current location shall include:

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Monitoring Event Subscription Request.
• The request payload will include a MonitoringNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to
  • configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelind shall be ignored by the IN-CSE if present since it is not supported by the present document
  • monitoringEventReports configured Location Reporting monitoring report(s) wherein a report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalID configured with the same value of M2M-Ext-ID of the UE as step 4.
    • monitoringType configured with LOCATION_REPORTING
    • locationInfo configured with the UE's current location information (e.g. ageOfLocationInfo, cellId, enodeBId, routingAreaId, trackingAreaId, plmmId and twanId )

Step 9: Response to Monitoring Notification for Current Location

After receiving a Monitoring Notification for current location, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Steps 10 and 11: Current Location Event Notification Handling at the IN-CSE

The IN-CSE shall create a new <contentInstance> child resource of the <container> targeted by the RETRIEVE request in Step 3. The IN-CSE shall store the UE's current location in this <contentInstance> and send the retrieve response for <latest> which is contains the current location to the IN-AE. The response shall include the newly created <contentInstance>.

Step 12: Request for 2^nd attempt Monitoring Event Subscription to get Last Known Location

If the Monitor Indication in Step 6 indicates a failure, then the IN-CSE shall send a Monitoring Event Subscription to the SCEF to get the last known location if the retrieveLastKnownLocation attribute of the <locationPolicy> is set to TRUE. The Monitoring Event Subscription request shall contain the following information as specified in 3GPP TS 29.122 [4].

• An HTTP POST method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/ which is identical to step 4. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription data structure as specified in 3GPP TS 29.122 [4] with the following attributes: externalId shall be set to the locationTargetID which shall be identical to step 4.
  • notificationDestination shall be set to a URI that the SCEF can target Location Reporting notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • monitoringType shall be set to LOCATION_REPORTING
  • supportedFeatures shall be set to a string value of "3" indicating support for Location Reporting notifications.
  • maximumNumberOfReports is optional and may be set to a maximum number of event reports to be generated by 3GPP network entities e.g. HSS or MME/SSGN. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • monitorExpireTime is optional and may be set to an absolute time at which the monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • locationType shall be set to LAST_KNOWN_LOCATION
  • accuracy shall be set set by the IN-CSE (e.g. CGI_ECGI, ENODEB, TA_RA, PLMN or TWAN_ID)
  • msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency, maximumDetectionTime and maximumResponseTime are not supported by the present document and shall not be included.

Step 13: Process Monitoring Event Subscription to get Last Known Location

The SCEF handles Monitoring Event Subsciption Request togather with 3GPP network entities based on the procedure defined in 3GPP TS 29.122 [4].

Step 14: Response to Monitoring Event Subscription for Last Known Location

The SCEF responds a Monitoring Event Subscription to get Last Known Location information to the IN-CSE to acknowledge acceptance of the Monitoring Event Subscription Request.

The message includes the following information.

• A response code of 201 CREATED
• The URI of the Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload will include a MonitoringEventSubscription 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
  • monitoringEventReport may be included if a monitoring event report is available.

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

Step 15: Detect Last Known Location of UE

The 3GPP network entities detect the last known location of UE and SCEF receives Monitoring Event Report for the last known location of UE

Step 16: SCEF sends Monitoring Notification for Last Known Location to IN-CSE

When the SCEF receives a last known location information from the 3GPP network entities, the SCEF sends Monitoring Notification Report to the IN-CSE that contains information as specified in 3GPP TS 29.122 [4]. Otherwise, the Monitoring Notification message is sent with appropriate information in accordance with the monitoringType.

The Monitoring Notification report for LOCATION_REPORTING for last known location shall include:

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Monitoring Event Subscription Request.
• The request payload will include a MonitoringNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to
  • configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelind shall be ignored by the IN-CSE if present since it is not supported by the present document
  • monitoringEventReports configured Location Reporting monitoring report(s) wherein a report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalID configured with the same value of M2M-Ext-ID of the UE as step 12.
    • monitoringType configured with LOCATION_REPORTING
    • locationInfo configured with the UE's last known location information (e.g. ageOfLocationInfo, cellId, enodeBId, routingAreaId, trackingAreaId, plmmId and twanId)

Step 17: Response to Monitoring Notification

After receiving a Monitoring Notification for last known location, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Steps 18 and 19: Current Location Reporting Event Handling at the IN-CSE

The IN-CSE shall create a new <contentInstance> child resource of the <container> initiated by the RETRIEVE request in Step 3. The IN-CSE shall store the UE's last known location in this <contentInstance> and send the retrieve response to IN-AE for <latest> which is contains the last known location. The response shall include the newly created <contentInstance>.

7.4.7.3 Location updating triggered by location change

Figure 7.4.7.3-1: Location updating triggered by location change

Step 1: Request for creation of <locationPolicy>

The IN-AE sends <locationPolicy> CREATE request which shall be included following parameters as specified in clause 9.6.10 of oneM2M TS-0001 [1]:

• locationSource shall be set to Network Based.
• locationUpdatePeriod shall not be present or set to 0.
• locationTargetID shall be set to the M2M-Ext-ID of the targeted UE hosting an ASN/MN-CSE or ADN-AE.
• locationServer shall not be present.
• locationContainerID shall not be present.
• locationInformationType shall be set to position fix.
• retrieveLastKnownLocation shall not be configured.
• locationUpdateEventCriteria shall be set to LocationChange

Step 2: Responds to creation <locationPolicy>

IN-CSE shall create the <locationPolicy> resource and corresponding <container> resource for storing location information and return a response based on the procedure specified in clause 10.2.9 of oneM2M TS-0001[1].

Step 3: Request Monitoring Event Subscription to get Current Location

The IN-CSE sends Monitoring Event Subscription to SCEF. The request 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-monitoring-event/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • externalId shall be set to the locationTargetID.
  • notificationDestination shall be set to a URI that the SCEF can target Location Reporting notifications towards. The value of this URI shall be based on internal IN-CSE policies.
  • monitoringType shall be set to LOCATION_REPORTING
  • supportedFeatures shall be set to a string value of "5" indicating support for Location Reporting notifications.
  • maximumNumberOfReports is optional and may be set to a maximum number of event reports to be generated by 3GPP network entities e.g. HSS or MME/SSGN. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • monitorExpireTime is optional and may be set to an absolute time at which the monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • locationType shall be set to CURRENT_LOCATION
  • accuracy shall be set set by the IN-CSE (e.g. CGI_ECGI, ENODEB, TA_RA, PLMN or TWAN_ID)
  • msisdn, ipv4Addr, ipv6Addr, externalGroupId, requestTestNotification, websockNotifConfig, groupReportGuardTime, maximumLatency, maximumDetectionTime and maximumResponseTime are not supported by the present document and shall not be included.

Step 4: Process Monitoring Event Subscription to get Current Location

The SCEF handles request for Monitoring Event Subscription together with 3GPP network entities based on the procedure defined in 3GPP TS 29.122 [4].

Step 5: Response to Monitoring Event Subscription for Current Location

The SCEF sends a Monitoring Event Subscription Response message to the IN-CSE to acknowledge acceptance of the Monitoring Event Subscription Request.

The message includes the following information.

• A response code of 201 CREATED
• The URI of the Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload will include a MonitoringEventSubscription 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
  • monitoringEventReport may be included if a monitoring event report is available.

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

Step 6: Request for Creation of <subscription>

The IN-AE sends the <subscription> CREATE request of <container> which stores location information to the IN-CSE.

Step 7: Response for Creation of <Subscription>

The IN-CSE sends the response to the IN-AE.

Step 8: Detect Current Location change of UE

The 3GPP network entities send a Monitoring Event Report for the current Indication to SCEF when detecting a change in location of the UE hosting an ASN/MN-CSE or ADN-AE.

Step 9: Report Monitoring Notification for Current Location from SCEF to IN-CSE

The SCEF sends a Monitoring Notification Report to the IN-CSE that contains information as specified in 3GPP TS 29.122 [4].

Otherwise, the Monitoring Notification message is sent with appropriate information in accordance with the monitoringType.

The Monitoring Notification report for LOCATION_REPORTING for current location shall include:

• An HTTP POST method is used
• URI is set to {notification_uri}. The {notification_uri} is configured by the IN-CSE in the Monitoring Event Subscription Request.
• The request payload will include a MonitoringNotification data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • subscription configured with a URI to the subscription resource for which this notification corresponds to
  • configResults is used for group-based monitoring and shall be ignored by the IN-CSE if present since group-based monitoring is not supported by the present document.
  • cancelind shall be ignored by the IN-CSE if present since it is not supported by the present document
  • monitoringEventReports configured Location Reporting monitoring report(s) wherein a report includes the following fields as defined in 3GPP TS 29.122 [4]:
    • externalID configured with the same value of M2M-Ext-ID of the UE as step 3.
    • monitoringType configured with LOCATION_REPORTING
    • locationInfo configured with the UE's current location information (e.g. ageOfLocationInfo, cellId, enodeBId, routingAreaId, trackingAreaId, plmmId and twanId)

Step 10: Response to Monitring Notification for Current Location

After receiving a Location Reporting Monitoring Notification, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Step 11: Handling Monitoring Notification for Current Location at the IN-CSE

The IN-CSE shall create a new <contentInstance> child resource of the <container> resource created in Step 2. The IN-CSE shall store the UE's current location in this <contentInstance> resource.

Step 12: Notify <contentInstance>

IN-CSE sends a NOTIFY request to the IN-AE. The NOTIFY includes the <contentInstance> with the UE's current location.

Step 13 (Optional): The IN-AE sends a request to update the locationUpdatePeriod to 0 or <locationPolicy> is deleted.

Step 14 (Optional): The IN-CSE sends a response to the IN-AE.

Step 15 (Optional): IN-CSE requests to SCEF to delete Monitoring Event Subscription

The IN-CSE sends a DELETE request targeting the URI of the subscription resource corresponding to this Monitoring Event Subscription. This step may be triggered by IN-CSE when a ADN-AE(s) or ASN/MN-CSE hosted on the UE de-registers from the IN-CSE.

The request is configured as follows.

• An HTTP DELETE method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId} which is identical to step 3. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} corresponds to the one configured by the SCEF and returned to the IN-CSE when the MonitoringEventSubscription was created.
• The request shall not contain a payload

Step 16 and 17 (Optional): Monitoring Event Subscription Delete Request Handling in the Underlying 3GPP network.

The SCEF handles request to delete the Monitoring Event Subscription together with the 3GPP network entities. The SCEF responds to the IN-CSE with a response code of 204 NO CONTENT to acknowledge the Monitoring Event Subscription has been deleted.

7.4.8 Number of UEs in an Area

The 3GPP SCEF functionality described in 3GPP TS 29.122 [4] supports an API to allow an IN-CSE to ask for the number of UEs that are in the geographic area described by the IN-CSE. Based on the reports, MNOs may be able to predict the general congestion status of each area based on the number of UEs.

A particular group of ASN/MN-CSEs and/or ADN-AEs hosted on UEs in an area may be identified in the underlying 3GPP network by an External Group Identifier available at the IN-CSE. The IN-CSE sends a Monitoring Event Request with the External Group Identifier and a geographic area to the corresponding SCEF. When the IN-CSE receives a Monitoring Event Response from the SCEF, the IN-CSE receives the number of group member UEs found at the area. Note that and the External Identifier(s) of the registree ASN/MN-CSEs/ADN-AEs may or may not be provided in the response, depending on MNO configuration of MME/SGSN. Based on this information, the IN-CSE can take necessary measures such as adjusting other monitoring procedures for the group. The IN-CSE may also take other actions, such as modifying the <schedule> resource of the group members. Upon detecting an updated scheduleElement, the group members will modify when they send requests and make themselves available to receive requests.

Figure 7.4.8-1: Monitoring for Number of UEs in an Area

Pre-conditions:

There is a relationship in place between the Service Provider and MNO allowing the IN-CSE to request Monitoring events for number of UEs present in an area. The method for establishing this relationship is outside the scope of the present document.

An ASN/MN-CSE or ADN-AE registers with the IN-CSE and configures the M2M-Ext-ID attribute of its <remoteCSE> or <AE> resource. The IN-CSE examines the M2M-Ext-ID and recognizes that it is associated with an MNO that it has a relationship with.

If the deployment uses External Group Identifier (externalGroupId) as described in 3GPP TS29.122 [4], when ASN/MN-CSEs or ADN-AEs register with the IN-CSE, then they use externalGroupId information to configure the externalGroupID of the corresponding <remoteCSE> or <AE> resources (see clause 6.3 when externalGroupID is configured).

The IN-CSE is configured to be able to determine a location area (i.e. locationArea and/or locationArea5G) of interest in the underlying 3GPP network. The IN-CSE may use its location services or other location information. How the location area of interest is determined is outside the scope of the present document.

The IN-CSE is configured with system defaults for:

• The specified actions to generate the network congestion levels based on the number of UEs in an area.
• The specified actions to take based on the severity of each congestion level.

The configuration methods for these system defaults are outside the scope of the present document.

The ADN-AE's or the ASN/MN-CSE's <node> resource hosted on the IN-CSE has a child <schedule> resource and the IN-CSE has permissions to update it. The ADN-AE or the ASN/MN-CSE has a <subscription> for its <schedule> resource and when it receives a notification from the IN-CSE, it updates its communication schedule accordingly.

Step 1: IN-CSE determines to send a Monitoring Event Request for number of UEs in a geographic area.

The IN-CSE determines to send to a SCEF a Monitoring Event Request for number of UEs present in an area of interest. The IN-CSE may determine the externalGroupID of a group of interest in the request, in which case the Monitoring Event Request is for the number of group-member UEs present in the area of interest.

The IN-CSE gets the externalGroupID information according to the attribute externalGroupID of the resource <remoteCSE> and <AE> of the UEs which location are in the area of interest. If there are multiple externalGroupIDs, the IN-CSE determines by local policy to send this request by each externalGroupID or send this request without externalGroupID.

Step 2: IN-CSE sends a Monitoring Event Request for the number of UEs in the area.

The IN-CSE sends a Monitoring Event Request for the geographical area of interest to the SCEF. The Monitoring Event Subscription request from the IN-CSE to the SCEF shall comply with 3GPP TS 29.122 [4] as follows:

• An HTTP POST method shall be used
• URI shall be set to {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
• The request payload shall include a MonitoringEventSubscription data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
  • monitoringType shall be set to NUMBER_OF_UES_IN_AN_AREA indicating the number of UEs in a given geographic area
  • monitorExpireTime is optional and may be set to an absolute time at which the monitoring event request is considered to expire. If used, the IN-CSE shall configure this time based on Service Provider and MNO policies.
  • locationType shall be set to LAST_KNOWN_LOCATION.
  • supportedFeatures shall be set to a string value of "8" and/or "12" indicating support for Location Reporting notifications. If it is set to the value of "8" (Number_of_UEs_in_an_area_notification), the feature supports the pre-5G (e.g. 4G) requirement. If it is set to the value of "12" (Number_of_UEs_in_an_area_notification_5G), the feature supports the 5G requirement (only be supported in 5G).
  • locationArea and/or locationArea5G shall be included to indicate the area of interest within which the IN-CSE requests the number of UEs. If supportedFeatures is set to the value of "8", the locationArea attribute is applicable. If supportedFeatures is set to the value of "12", the locationArea5G attribute is applicable.
  • externalGroupId shall be set to the externalGroupID if in step 1 the IN-CSE monitoring request targets identifying the number of UEs from a specific group in the area and the IN-CSE determined an externalGroupID to be monitored.
  • maximumNumberOfReports shall be set to an integer value of "1" indicating one-time reporting.
  • requestTestNotification, websockNotifConfig, addExtGroupIds and groupReportGuardTime are not supported by the present document and shall not be included.

Step 3: SCEF processes the Monitoring Event Request.

The SCEF processes the Monitoring Request together with the 3GPP network entities as described in 3GPP TS 29.122 [4].

Step 4: SCEF sends a Monitoring Event Response.

The SCEF sends a Monitoring Event Response to the IN-CSE to acknowledge the request has been accepted. This response is described in 3GPP TS 29.122 [4] and includes the following information.

• A response code of 200 OK.
• The URI of the Monitoring Event Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-monitoring-event/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
• The response payload shall include a MonitoringEventReport data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
  • ueCount is configured to indicate the number of UEs found at the location. If an externalGroupId has been provided in the request, the count indicates the number of UEs from the given group which are found at the location.
  • externalIds is configured to indicate External Identifier(s) of the UEs included in the number of UEs found denoted by ueCount. Note that and the External Identifier(s) information may or may not be provided in the response, depending on MNO configuration of MME/SGSN.
  • self is configured with a URI to the resource created by the SCEF for the request.

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

Step 5: Monitoring Event handling at the IN-CSE .

The IN-CSE may use the information provided in the Monitoring Event Report to modify the <schedule> resource of the group members such that they modify the times they send or receive requests.

How the IN-CSE determines the use of the information received from the monitoring event is outside the scope of the current document and may be based on agreements with the MNO.