Skip to content

7.8 Informing about Potential Network Issues

7.8.1 Throttling of requests based on Network Status Reports

The 3GPP SCEF Network Status Monitoring functionality described in 3GPP TS 29.122 [4] supports an API to allow an IN-CSE to be informed when there are network congestion issues in a geographical area in the underlying 3GPP network.

An IN-CSE may request to receive notifications from an underlying 3GPP network when the network congestion level in a specified geographical area crosses defined threshold value(s). Based on these reports, the IN-CSE can start/stop throttling of requests initiated by or targeted towards its registree AEs and CSEs that are hosted on Ues residing in this geographical area to help manage the congestion levels in the underlying 3GPP network.

Figure 7.8.1-1: Request for Network Status Reports

Figure 7.8.1-1: Request for Network Status Reports

Pre-conditions:

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

The IN-CSE is configured with system defaults for the following. The method for configuring these system defaults is outside the scope of the present document.

  • The network congestion levels to receive reports
  • The severity of each specified congestion level
  • The specified actions to take based on the severity of each congestion level.

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 IN-CSE is able to detect the location of its registree ASN/MN-CSEs and/or ADN-AEs. For example, a <locationPolicy> resource may be used by an IN-CSE to detect the location of each ASN/MN-CSE or ADN-AE.

The ADN-AE'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 has a <subscription> to its <schedule> resource and when it receives a notification from the IN-CSE it updates its communication schedule accordingly.

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 ASN/MN-CSE has a <subscription> to its <schedule> resource and when it receives a notification from the IN-CSE it updates its communication schedule accordingly.

Step 1: IN-CSE issues a Network Status Request

The IN-CSE issues a Network Status Report request to the SCEF via one or more of the following approaches.

  • The IN-CSE may periodically check the location of its registree ASN/MN-CSEs and ADN-AEs. When the IN-CSE detects that a certain number of ASN/MN-CSEs and/or ADN-AEs are in the same geographical area, it may further check if the ASN/MN-CSEs and ADN-AEs are connected to the same network. The IN-CSE can detect if the ASN/MN-CSEs and ADN-AEs are connected to the same network by examining their M2M-Ext-ID attributes. For example, a 3GPP external identifier is composed of a local identifier and a domain identifier. If the ASN/MN-CSEs and ADN-AEs have the same domain identifier, they may be connected to the same network. When the IN-CSE detects that a number of ASN/MN-CSEs and/or ADN-AEs are in the same geographical area and attached to the same network, it may decide to request a Network Status Report in that geographical area.
  • The IN-CSE may use [cmdhNwAccessRule] resources for corresponding registree CSEs that support CMDH functionality. The IN-CSE may check the targetNetwork attribute and use this attribute to identify a SCEF and issue a Network Status Request to this SCEF. When issuing the request for a Network Status Report, the IN-CSE shall provide a geographic area for which the report will apply. The IN-CSE may detect the geographic area for which the policy applies by checking the location that is associated with each CSE. For example, <locationPolicy> resources may be associated with a registree CSE for which the CMDH policies apply and used by an IN-CSE to detect locations for the CSEs.

How the IN-CSE determines which of the above approach(es) to use is implementation specific and outside the scope of the present document.

Step 2: Network Status Report Request

The IN-CSE requests network status reports for a geographical area. The Network Status Reporting 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-net-stat-report/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
  • The request payload shall include a NetworkStatusReportingSubscription data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • notificationDestination shall be set to a URI that the SCEF can target Network Status Report notifications towards. The value of this URI shall be based on internal IN-CSE policies.
    • thresholdValues shall be a list of integer values in the range of 0 to 31 and specify what congestion threshold(s) the IN-CSE wants to receive a report for. Whenever the congestion in the geographical area goes above or below an indicated threshold, a report will be sent. The threshold(s) that are indicated by the IN-CSE are determined based on local IN-CSE policies. The definition of these policies is outside the scope of the present document.
    • thresholdTypes shall be a list of enumerated types with values HIGH, MEDIUM and LOW that specify the type of congestion status the IN-CSE would like to receive a report for. The threshold type(s) that are indicated by the IN-CSE are determined based on local IN-CSE policies. The definition of these policies is outside the scope of the present document. The IN-CSE shall not include thresholdValue and thresholdType in the same request. They shall be used mutually exclusive of one another.
    • timeDuration shall indicate the date and time that the SCEF will stop sending reports to the IN-CSE. The data and time value is determined based on local IN-CSE policies. The definition of these policies is outside the scope of the present document.

Note

If no duration is provided, then only one Network Status Report will be provided to the IN-CSE

  • locationArea shall be configured with location information specified by the IN-CSE. The IN-CSE may use location information that it collects from its registree's <locationPolicy> resources and/or M2M-Ext-IDs to configure this attribute. Shall be expressed as a list cell IDs, tracking areas, civic addresses or geopgraphic area.
  • supportedFeatures shall be set to a string value of "0" indicating no support for notifications via Websockets or notification test events.
  • requestTestNotification and websockNotifConfig are not supported by the present document and shall not be included.

General Exceptions:

The SCEF is not reachable when Hosting CSE (i.e. IN-CSE) tries to send Network Status Reporting Subscription request. In this case the IN-CSE will not be able to get receive network status reports from the underlying 3GPP network. Hence the IN-CSE will not be able to provide value-add services to the underlying 3GPP network such as throttling of requests targeted towards AEs and CSEs hosted on Ues residing in congested areas of the network.

Step 3: SCEF Processes Network Status Report Request

The SCEF and the underlying 3GPP network process the Network Status Report Request.

Step 4: Network Status Report Response

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

  • A response code of 201 CREATED
  • The URI of the Group Message Delivery resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-net-stat-report/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 an updated NetworkStatusReportingSubscription 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 link to the {apiRoot}/3gpp-net-stat-report/v1/{scsAsId}/subscriptions/{subscriptionId} 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: Detect Congestion

After receiving the initial Network Status Request or when the congestion level passes one of the indicated threshold(s), the SCEF will create a Network Status Report.

Step 6: Network Status Report

The SCEF sends a Network Status Report to the corresponding notificationDestination of the IN-CSE that was configured in Step 2. The report 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 Network Status Reporting Subscription Request.
  • The request payload will include a NetworkStatusReportingNotification 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
    • nsiValue configured with the network status indicator that is an integer in the range of 0 to 31 that indicates a congestion level as defined in 3GPP TS 29.122 [4]
    • nsiType configured with the network status indicator that is an enumerated value of HIGH, MEDIUM or LOW as defined in 3GPP TS 29.122 [4]

Note

A response will not contain both nsiType and nsiValue. They are mutually exclusive.

Step 7: Network Status Report Acknowledgement

After receiving a Network Status Report Notification, the IN-CSE returns a response having a response code of 204 NO CONTENT.

Step 8: Process Network Status Report

In response to the Network Status Report, the IN-CSE may decide to throttle up/down traffic in the congested area of the network via one or more of the following approaches.

  • An IN-CSE may reject requests that target nodes in congested areas of the network. If an IN-CSE rejects a request due to network congestion it shall return a EXTERNAL_OBJECT_NOT_REACHABLE response code. The IN-CSE may also inform the Originator to retry the request after some specified backoff delay. The method to inform the Originator is currently not specified in the present document however a message included in the payload of the response could be used.
  • An IN-CSE may delay the processing (i.e. buffer) of requests that target nodes in congested areas of the network.
    • If the request is a blocking request, the IN-CSE should not delay the processing of the request and should instead reject this request with a corresponding response code informing the cause of rejection is due to network congestion.
    • 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 EXTERNAL_OBJECT_NOT_REACHABLE response code. 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.
  • An IN-CSE may modify the <schedule> resource of its registree AEs or CSEs that are located in a congested area of the network such that they modify the times they send or receive requests.
    • A registree AE or CSE may retrieve or subscribe to its <schedule> resource such that it detects if the IN-CSE updates the scheduleElement attribute. Upon detecting an updated scheduleElement an AE or CSE shall modify the times which it sends requests and makes itself available to receive requests.
  • An IN-CSE may modify the [cmdhNwAccessRule] resources for corresponding registree CSEs that support CMDH functionality.

How the IN-CSE determines which of the above approach(es) to use is outside the scope of the current document and may be based on agreements with the MNO.

Step 9 (Optional) Network Status Request Cancellation

Before the Duration expires, the IN-CSE may request that the SCEF stop sending status reports. The IN-CSE may make this decision, for example, when it detects that a number of devices are no longer in the geographical area applicable to the Network Status Request.

The IN-CSE shall send a Network Status Cancellation Request as follows:

  • An HTTP DELETE method shall be used
  • URI shall be set to {apiRoot}/3gpp-net-stat-report/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 Network Status Reporting Subscription was created.
  • The request shall not contain a payload

Step 10 (Optional): Process Network Status Cancellation Request

The SCEF processes the cancelation request.

Step 1 1 (Optional): Acknowledge Network Status Cancellation Request

The SCEF acknowledges the request to cancel Network Status Reports for the geographical area with a response code of 204 NO CONTENT.

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