Skip to content

7.15 Network Monitoring Request

7.15.1 Overview

This clause provides details on how an AE (Originator) exchanges with underlying 3GPP network parameters to be used for optimizing the data traffic over the underlying 3GPP network for a set of Field Domain Nodes hosted on UEs. If the AE (Originator) sets the type of network request with the associated attributes such as a geographic area, congestion threshold and External Group ID, the Hosting CSE determines the corresponding T8 API(s) based on the type of network request, maps the attributes to the T8 API(s), and communicates with the SCEF. When the SCEF returns a response to the Hosting CSE, the Hosting CSE maps the response to the specified oneM2M resource and sends a response to the AE (Originator). Based on the information, the AE (Originator) may adjust data processing/transfer for the Field Domain Nodes (ASN/MN/ADN).

7.15.2 Resource Structure

Refer to the clause 9.6.64 Resource Type <nwMonitoringReq> of oneM2M TS-0001 [1].

7.15.3 Procedures

This clause describes procedures to retrieve an underlying 3GPP network information in a particular geographic area initiated by a request from an AE. The following T8 APIs are applicable for this procedure.

  • Network Status Reports API
  • Monitoring Event API (Monitoring Type: Number of UEs in an Area)

7.15.3.1 Procedure for Network Status Reports API

Figure 7.15.3.1-1 depicts a procedure to retrieve an underlying 3GPP network information in a particular geographic area with Network Status Reports API.

Figure 7.15.3.1-1: Procedure for Network Status Reports API

Figure 7.15.3.1-1: Procedure for Network Status Reports API

Pre-conditions:

There is a relationship in place between the Service Provider and MNO allowing the AE (Originator) to request 3GPP T8 API information from the underlying 3GPP network. The method for establishing this relationship is outside the scope of the present document.

The Hosting CSE is configured with system defaults as described in clause 7.8 and/or clause 7.4.8.

Step 1: CREATE <nwMonitoringReq> Request & Response, Subscription creation

An Originator (AE) requests the creation of a <nwMonitoringReq> resource at the Hosting CSE. The request shall include the following parameter as specified in clause 9.6.64 of oneM2M TS-0001 [1]

  • monitorStatus shall be set to DISABLED.

If the operation is successful, the Originator receives a response message. And the Originator shall subsequently create the <subscription> resource as the child of the <nwMonitoringReq> resource to get notified of network monitoring status.

Step 2: UPDATE <nwMonitoringReq> Request for enable network monitoring

In order to initiate a monitoring request, the Originator sends a request to update the monitorEnable attribute of the <nwMonitoringReq> resource.

  • monitorEnable shall be set to MonitorCongestion.
  • geographicArea shall be set to the geographic area where the Originator wants to retrieve an underlying 3GPP network information.
  • congestionLevel shall be set to one of following values:
    • The list of congestion level(s) with exact value and specify what congestion threshold(s) the Originator wants to receive a report for.
    • The list of enumerated types with values HIGH, MEDIUM and LOW that specify the type of congestion status the Originator would like to receive a report for.

If the value of monitorStatus is set to ENABLED, the Originator shall not send an UPDATE request.

Step 3: UPDATE <nwMonitoringReq> Response

The Hosting CSE shall update the <nwMonitoringReq> resource and return a response to the Originator.

If the value of monitorEnable is MonitorCongestion, the Hosting CSE shall check if congestionLevel attribute and geographicArea attribute are included in the request.

  • If the attributes are present, the Hosting CSE shall set the value of monitorStatus to ENABLED, and the subsequent Update procedures of the Hosting CSE shall be performed for the resource.
  • If the attributes are not present, the Hosting CSE shall not process the request and shall return a response primitive with a Response Status Code indicating "BAD_REQUEST" error.

If the value of monitorStatus is ENABLED, the Hosting CSE shall reject the request with a Response Status Code indicating "CONFLICT" error.

If the Hosting CSE receives a request for deletion of monitorEnable attribute, the Hosting CSE shall set the value of monitorStatus to DISABLED.

Step 4: Process Network Status Reports Request

The Hosting CSE shall map the attributes of the <nwMonitoringReq> resource to the following attributes of Network Status Reports API as described in clause 7.8.

  • The Hosting CSE shall set the fixed parameters with the corresponding attributes of the API (e.g. URI, monitorExpireTime, supportedFeatures).
  • geographicArea of the <nwMonitoringReq> resource shall be set to locationArea.
  • If the congestionLevel of the <nwMonitoringReq> resource indicates an abstracted value for congestion level(s) (e.g. HIGH, MEDIUM or LOW), thresholdTypes shall be set to the abstracted value of the congestionLevel. If congestionLevel indicates an exact value for congestion level(s) (e.g. between 0 and 31), thresholdValues shall be set to the exact value of the congestionLevel.

Then the Hosting CSE shall send a Network Status Report request to the SCEF, and the SCEF sends a Network Status Report response to the Hosting CSE as described in clause 7.8.

Step 5: NOTIFY <nwMonitoringReq>

The Hosting CSE sends a notification request of <nwMonitoringReq> resource to the Originator. The notification is configured as follows:

  • After receiving a Network Status Report Notification request from the SCEF, the Hosting CSE shall map the following attributes of the Network Status Reports API described in clause 7.8 to the attribute of the <nwMonitoringReq> resource.
    • nsiValue or nsiType shall be set to the congestionStatus of the <nwMonitoringReq> resource.

If the Hosting CSE receives an error response from the SCEF, the Hosting CSE shall set the value of monitorStatus to FAILED, and shall map the error response code to the corresponding value of failureReason. Then, the Hosting CSE shall send a notification request of <nwMonitoringReq> resource to the Originator. The each error response code is configured as follows:

  • 400 Bad Request shall be set to BAD_REQUEST.
  • 401 Unauthorized shall be set to UNAUTHORIZED.
  • 403 Forbidden shall be set to FORBIDDEN.
  • 404 Not Found shall be set to NOT_FOUND.
  • 411 Length Required shall be set to LENGTH_REQUIRED.
  • 413 Payload Too Large shall be set to PAYLOAD_TOO_LARGE.
  • 415 Unsupported Media Type shall be set to UNSUPPORTED_MEDIA_TYPE.
  • 429 Too Many Requests shall be set to TOO_MANY_REQUESTS.
  • 500 Internal Server Error shall be set to INTERNAL_SERVER_ERROR.
  • 503 Service Unavailable shall be set to SERVICE_UNAVAILABLE.

Step 6: The Originator adjusts data processing/transfer for Field Domain Nodes (ASN/MN/ADN)

The Originator may use the information provided in step 4 in order to adjusts data processing/transfer for Field Domain Nodes (ASN/MN/ADN).

If the value of failureReason is set to FORBIDDEN, the Originator may be configured with the values (e.g. congestionLevel,geographicArea) within the range defined by MNO policies.

If the value of failureReason is set to PAYLOAD_TOO_LARGE, the Originator may retry the request without optional attribute(s).

If the value of failureReason is set to TOO_MANY_REQUESTS, the Originator may reduce the frequency of requests or avoid immediate retries.

Step 7 (Optional): DELETE <nwMonitoringReq> Request

The Originator sends a request to delete the <nwMonitoringReq> resource.

Step 8 (Optional): Proce ss deletion of Network Status Reports

The Hosting CSE shall send a DELETE request of the Network Status Reports API to the SCEF as described in clause 7.8.

Step 9 (Optional): The Hosting CSE deletes the <nwMonitoringReq> resource

If in step 8 the Hosting CSE receives a 204 No Content response code from the SCEF, the Hosting CSE shall delete the <nwMonitoringReq> resource. Otherwise, the Hosting CSE shall not delete the <nwMonitoringReq> resource.

Step 10 (Optional): The Hosting CSE returns response to the Originator.

The Hosting CSE shall send a DELETE response back to the Originator.

7.15.3.2 Procedure for Monitoring Event API (Monitoring Type: Number of UEs in an Area)

Figure 7.15.3.2-1 depicts a procedure to retrieve an underlying 3GPP network information in a particular geographic area with Monitoring Event API (Monitoring Type: Number of UEs in an Area).

Figure 7.15.3.2-1: Procedure for Monitoring Event API (Monitoring Type: Number of UEs in an Area)

Figure 7.15.3.2-1: Procedure for Monitoring Event API (Monitoring Type: Number of UEs in an Area)

Pre-conditions:

There is a relationship in place between the Service Provider and MNO allowing the AE (Originator) to request 3GPP T8 API information from the underlying 3GPP network. The method for establishing this relationship is outside the scope of the present document.

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 Hosting CSE (SCS), 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 Hosting CSE is configured with system defaults as described in clause 7.4.8.

Step 1: CREATE <nwMonitoringReq> Request & Response, Subscription creation

An Originator (AE) requests the creation of a <nwMonitoringReq> resource at the Hosting CSE. The request shall include the following parameter as specified in clause 9.6.64 of oneM2M TS-0001 [1]:

  • monitorStatus shall be set to DISABLED.

If the operation is successful, the Originator receives a response message. And the Originator shall subsequently create the <subscription> resource as the child of the <nwMonitoringReq> resource to get notified of network monitoring status.

Step 2: UPDATE <nwMonitoringReq> Request for enable network monitoring

In order to initiate a monitoring request, the Originator sends a request to update the monitorEnable attribute of the <nwMonitoringReq> resource.

  • monitorEnable shall be set to MonitorDeviceNumber.
  • geographicArea shall be set to the geographic area where the Originator wants to retrieve an underlying 3GPP network information.
  • externalGroupID shall be set to the 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.

If the value of monitorStatus is set to ENABLED, the Originator shall not send an UPDATE request.

Step 3: UPDATE <nwMonitoringReq> Response

The Hosting CSE shall update the <nwMonitoringReq> resource and return a response to the Originator.

If the value of monitorEnable is MonitorDeviceNumber, the Hosting CSE shall check if geographicArea attribute is included in the request.

  • If the attribute is present, the Hosting CSE shall set the value of monitorStatus to ENABLED, and the subsequent Update procedures of the Receiver shall be performed for the resource.
  • If the attribute is not present, the Hosting CSE shall not process the request and shall return a response primitive with a Response Status Code indicating "BAD_REQUEST" error.

If the value of monitorStatus is ENABLED, the Hosting CSE shall reject the request with a Response Status Code indicating "CONFLICT" error.

If the Hosting CSE receives a request for deletion of monitorEnable attribute, the Hosting CSE shall set the value of monitorStatus to DISABLED.

Step 4: Process Monitoring Event (Number of UEs in an area) Request

The Hosting CSE shall map the attributes of the <nwMonitoringReq> resource to the following attributes of Monitoring Event API (Number of UEs in an area) as described in clause 7.4.8.

  • The Hosting CSE shall set the fixed parameters with the corresponding attributes of the API (e.g. URI, supportedFeatures).
  • geographicArea of the <nwMonitoringReq> resource shall be set to locationArea.
  • externalGroupID of the <nwMonitoringReq> resource shall be set to externalGroupId if in step 2 the Hosting CSE monitoring request targets identifying the number of UEs from a specific group in the area and the Hosting CSE determined an externalGroupID to be monitored.

Then the Hosting CSE shall send a Monitoring Event request to the SCEF as described in clause 7.4.8.

Step 5: NOTIFY <nwMonitoringReq>

The Hosting CSE sends a notification request of <nwMonitoringReq> resource to the Originator. The notification is configured as follows:

  • After receiving a Monitoring Event response from the SCEF, the Hosting CSE shall map the following attributes of the Monitoring Event API described in clause 7.4.8 to the attributes of the <nwMonitoringReq> resource.
    • ueCount shall be set to the numberOfDevices of the <nwMonitoringReq> resource. 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 shall be set to M2M-Ext-ID attribute of the <nwMonitoringReq> resource, if an externalGroupId has been provided in the request.

If the Hosting CSE receives an error response from the SCEF, the Hosting CSE shall set the value of monitorStatus to FAILED, and shall map the error response code to the corresponding value of failureReason. Then, the Hosting CSE shall send a notification request of <nwMonitoringReq> resource to the Originator. The each error response code is configured as follows:

  • 400 Bad Request shall be set to BAD_REQUEST.
  • 401 Unauthorized shall be set to UNAUTHORIZED.
  • 403 Forbidden shall be set to FORBIDDEN.
  • 404 Not Found shall be set to NOT_FOUND.
  • 411 Length Required shall be set to LENGTH_REQUIRED.
  • 413 Payload Too Large shall be set to PAYLOAD_TOO_LARGE.
  • 415 Unsupported Media Type shall be set to UNSUPPORTED_MEDIA_TYPE.
  • 429 Too Many Requests shall be set to TOO_MANY_REQUESTS.
  • 500 Internal Server Error shall be set to INTERNAL_SERVER_ERROR.
  • 503 Service Unavailable shall be set to SERVICE_UNAVAILABLE.

Step 6: The Originator adjusts data processing/transfer for Field Domain Nodes (ASN/MN/ADN)

The Originator may use the information provided in Step 5 in order to adjusts data processing/transfer for Field Domain Nodes (ASN/MN/ADN).

If the value of failureReason is set to FORBIDDEN, the Originator may be configured with the values (e.g. geographicArea) within the range defined by MNO policies.

If the value of failureReason is set to PAYLOAD_TOO_LARGE, the Originator may retry the request without optional attribute(s).

If the value of failureReason is set to TOO_MANY_REQUESTS, the Originator may reduce the frequency of requests or avoid immediate retries.

Step 7 (Optional): DELETE <nwMonitoringReq> Request

The Originator sends a request to delete the <nwMonitoringReq> resource.

Step 8 (Optional): The Hosting CSE deletes the < nwMonitoringReq> resource

The Hosting CSE shall delete the <nwMonitoringReq> resource.

Step 9 (Optional): The Hosting CSE returns response to the Originator.

The Hosting CSE shall send a DELETE response back to the Originator.