Handling Missing Notifications from Network to QoD API for Successful Resource Allocation

[Chintanlodariya]

Scenario:

As per the standard flow, when a QoD session creation request is received from the application server to the QoD API, the session creation request is forwarded to the NEF/PCF. The PCF then enforces the new policy towards the enforcement function (PGW/SMF) and sends an acknowledgement back to the PCF/NEF. Based on this acknowledgement, a 201 response is forwarded to the external application server via the QoD API, and the QoS status is marked as "requested." Once the PGW enforces the policy and allocates the resource to the user, it notifies the PCF, which in turn notifies the NEF and then the QoD API about the successful resource allocation, changing the QoS status to "available."

Question:

What should be the course of action if, for any reason, the notification for "successful resource allocation" is not received by the QoD API from the network? Should the QoD API inform the application server about a QoD failure in such a case?

[eric-murray]

If network resources are never allocated for the requested QoS profile but no error is received from the network, then the session will remain in REQUESTED state before moving to UNAVAILABLE when the session is terminated for whatever reason.

In principle, the session could remain in REQUESTED state indefinitely, waiting for the API consumer to cancel it. In practice, it is probably wise for the API implementation to terminate the session before that, after waiting a reasonable time for the network to respond.

But if that happens frequently, it suggests that there is a problem with the network implementation, as the network itself should either allocate resources or respond with an error within a reasonable period of time.

[Chintanlodariya]

In principle, the session could remain in REQUESTED state indefinitely, waiting for the API consumer to cancel it. In practice, it is probably wise for the API implementation to terminate the session before that, after waiting a reasonable time for the network to respond.

I think to maintain the integrity and reliability of the service, we need to implement a timeout mechanism in the QoD API. If the notification is not received from the network within a predefined time frame, the QoD API should assume that the resource allocation has failed and share the qosStatus as UNAVAILABLE and statusInfo as NETWORK_TERMINATED

[hdamker]

I think to maintain the integrity and reliability of the service, we need to implement a timeout mechanism in the QoD API. If the notification is not received from the network within a predefined time frame, the QoD API should assume that the resource allocation has failed and share the qosStatus as UNAVAILABLE and statusInfo as NETWORK_TERMINATED

@Chintanlodariya Full agreement with this statement, it is required within any service provider implementation of the API that it handles timeout scenarios.

But as this is internal to the implementation there is no change to API definition itself. The proposal within the QoD call at Jan 10th was to close the issue. Do you agree?

[Chintanlodariya]

But as this is internal to the implementation there is no change to API definition itself. The proposal within the QoD call at Jan 10th was to close the issue. Do you agree?

@hdamker : I understand your point about handling timeout scenarios being an internal implementation detail. However, since the notification mechanism is asynchronous, incorporating a timeout as part of the QoD API definition ensures consistency and reliability across different implementations. This way, we can standardize the behavior when a notification is not received within the expected timeframe, making the API more robust. Therefore, I believe it is essential to include the timeout mechanism in the QoD API specification.

[hdamker]

@Chintanlodariya Would you be so kind to propose a pull request which the changes you would like to see? That would allow a concrete discussion. The assumption within the QoD call on Friday 24th was that this will impact in the API definition only the documentation, but would be good to see the actual needed changes.