8.3 Error Handling
8.3.1 Overview
An IN-CSE that interworks to a 3GPP SCEF via the T8 reference point shall support handling the following types of error conditions:
- Unavailable SCEF - If the IN-CSE sends a request to the SCEF, but the SCEF does not respond back, the IN-CSE shall be robust to this scenario. At a minimum, the IN-CSE shall support timing out the request. The IN-CSE may support retrying requests but these details are out of scope of the present document.
- Errors returned by the SCEF to the IN-CSE within T8 responses - Table 8.3-1 provides a list of the supported T8 mandatory error response codes applicable to all T8 APIs defined by 3GPP 29.122 [4]. -40x response codes indicate a problem due to malformed requests from the IN-CSE that need to be addressed. -50x response codes typically indicate a problem with the SCEF that needs to be addressed.
Table 8.3.1-1: T8 Error response codes
| Response Codes | Remarks |
|---|---|
| 400 Bad Request | Incorrect parameters were passed in the request issued by the IN-CSE. |
| 401 Unauthorized | The IN-CSE is not authorized to issue request to SCEF. |
| 403 Forbidden | This represents the case when the SCEF is able to understand the request but unable to fulfil the request due to errors (e.g. the requested parameters are out of range). |
| 404 Not Found | The resource URI was incorrect, for instance because of a wrong "scsAsId" field. |
| 411 Length Required | The code indicates that the SCEF refuses to accept the request without a Content-Length header field. |
| 413 Payload Too Large | The request contains a payload larger than the SCEF is able to process. |
| 415 Unsupported Media Type | The code indicates that the resource is in a format which is not supported by the SCEF for the method. |
| 429 Too Many Requests | The code indicates that due to excessive traffic which, if continued over time, may lead to (or may increase) an overload situation. The HTTP header field "Retry-After" may be added in the response to indicate how long the IN-CSE has to wait before making a new request. |
| 500 Internal Server Error | The SCEF encountered an unexpected condition that prevented it from fulfilling the request. |
| 503 Service Unavailable | The SCEF is unable to handle the request. |
Note
Depending on the specific procedure, the IN-CSE performs different error handling actions. These procedure specific error-handling actions are defined in the respective sub-clauses of this specification.
8.3.2 Error handling for Monitoring events
8.3.2.1 Internal Server Error
If a SCEF receives a Monitoring event request to create a subscription resource for a monitoring event that it does not support, the SCEF will reject the request by sending a "500 Internal Server Error" HTTP error response with the application error "EVENT_UNSUPPORTED".
Figure 8.3.2.1-1 shows an example of the error handling procedure for the case where the SCEF doesn't support the event requested by the SCS (IN-CSE). The SCEF supports the monitoring type of UE Reachability and does not support the monitoring type of Location Reporting. If an IN-CSE sends a Monitoring Event Subscription Request with the monitoring type of Location Reporting, the SCEF will reject the request by sending the above error response with the application error.
If the IN-CSE receives the error response from the SCEF, the IN-CSE may obtain the location information of an ASN/MN-CSE or ADN-AE by using Device-based method or Sharing-based method configured with locationSource attributes of <_locationPolicy> resource based on the IN-CSE local policy.
Figure 8.3.2.1-1: Error handling procedures for Location Reporting of Monitoring events
Figure 8.3.2.1-2 shows another example of the error handling procedure. The SCEF supports the monitoring type of UE Reachability and does not support the monitoring type of UE Loss of Connectivity. If an IN-CSE sends a Monitoring Event Subscription Request with the monitoring type of UE Loss of Connectivity, the SCEF will reject the request by sending the above error response with the application error.
If the IN-CSE receives the error response from the SCEF, the IN-CSE may retry the request with the monitoring type of UE Reachability for managing unreachable devices, based on the IN-CSE local policy.
Figure 8.3.2.1-2: Error handling procedures for UE Loss of Connectivity of Monitoring events
8.3.2.2 Forbidden
If a SCEF receives a Monitoring event request to create a subscription resource, the SCEF will check whether the parameters (e.g. Maximum Number of Reports) in the request body are within the range defined by MNO policies. If one or more of these parameters are not within the range, the SCEF may reject the request by sending a "403 Forbidden " HTTP error response with the application error "PARAMETER_OUT_OF_RANGE".
Figure 8.3.2.2-1 shows an example of the error handling procedure. The SCEF supports the monitoring type of Communication Failure and maximumNumberOfReports parameter is set to "10" defined by MNO policies. If an IN-CSE sends a Monitoring Event Subscription Request for Communication Failure with maximumNumberOfReports parameter set to "20", the SCEF will reject the request by sending the above error response with the application error.
If the IN-CSE receives the error response from the SCEF, the IN-CSE may retry the request with the parameters set within the range (e.g. 8), based on the IN-CSE local policy.
Figure 8.3.2.2-1: Error handling procedures for Communication Failure of Monitoring events
If the SCEF receives a Monitoring event request to create a subscription resource, the SCEF will check whether the Idle Status Indication is included for UE reachability event. If the Idle Status Indication is received in the request but not supported by the network, the SCEF may reject the request by sending sending a "403 Forbidden" HTTP error response with the application error "IDLE_STATUS_UNSUPPORTED" in the "cause" attribute of the "ProblemDetails" structure.
Figure 8.3.2.2-2 shows an example of the error handling procedure. The SCEF supports the monitoring type of UE Reachability and does not support to send notifications to an IN-CSE when the UE transitions into PSM idle mode, connected mode or receives an eDRX paging occasion. If the IN-CSE sends a Monitoring Event Subscription Request for UE Reachability with idleStatusIndication parameter set to "TRUE", the SCEF will reject the request by sending the above error response with the application error.
If the IN-CSE receives the error response from the SCEF, the IN-CSE may retry the request with idleStatusIndication parameter set to "FALSE" for one-time monitoring request, based on the IN-CSE local policy.
Figure 8.3.2.2-2: Error handling procedures for UE Reachability of Monitoring events
8.3.2.3 Bad Request
If a SCEF receives a request from an IN-CSE, but without an indication of the support for the feature, the SCEF will ignore the feature or reject the request by sending an error response. The response from the SCEF is different depending on the type of supportedFeatures.
This clause introduces error handling procedures for a mandatory supportedFeatures. If a SCEF receives a Monitoring Event Subscription Request for a Monitoring Event, but without an indication of the support for the feature corresponding to the Monitoring Event, the SCEF will reject the request by sending a 400 "Bad Request" HTTP error response with the application error "EVENT_FEATURE_MISMATCH".
Figure 8.3.2.3-1 shows an example of the error handling procedure for a mandatory supportedFeatures. A SCEF supports Location Reporting of Monitoring Event API. If an IN-CSE sends a Monitoring Event Subscription Request (monitoringType is set to LOCATION_REPORTING, supportedFeature is set to a value of Roaming Status Notification), the SCEF will reject the request by sending the above error response with the application error. Because the feature corresponding to the event type of Monitoring Event needs to be set to the value of Location Notifications.
If the IN-CSE receives the error response from the SCEF, the IN-CSE may retry the request with the value of Location_Notifications.
Figure 8.3.2.3-1: Error handling procedures for a mandatory supportedFeatures