Potential enhancement of booking feature for qod-provision

[Masa8106]

Problem description In Issue #268, there was discussion on booking feature for QoD Provision API which is not supported by the API yaml file at this moment. As the Issue #268 was closed, I would like to resume discussion here to add support the booking feature (booking start and end time of sessions in advance) for the API.

Possible evolution Add two properties, which are booking start time and booking end time, in CreateProvision schema for QoD Provision API.

Alternative solution

Additional context See comments in #268 (comment) where this point was discussed.

[eric-murray]

@Masa8106 Is it expected that the booking will create a "contract" between the API consumer and provider such that, if the time of the booking arrives but the QoS provisioning fails, then the API consumer will expect to be compensated?

Or is this feature just a courtesy for the API consumer so that they themselves don't need to automate requesting and terminating the QoS provisioning at some point in the future, but can rely on the API provider to make those requests? So the API provider makes the request at the scheduled time, but need not make any special provision in advance to ensure that the request succeeds at that time.

In other words, what would be the consequence to the API provider if a booking fails to be actioned at the booked time?

[Masa8106]

@eric-murray Thank you for your comments.

Basically it is not expected that the booking will create a "contract" and then API provider will always take responsibility for compensation. The aim is to increase convenience for API consumers by providing a booking function on the API provider's side.

Of cource, from business perspective, there may be cases that some API providers provide this feature to API consumers on top of a contract. However, I think it is business matter.

From technical perspective, I think it is needed to consider mechanisms in a case to fail changing QoS at the booked time , e.g. mechanism for notification of failure to API consumer.

[Masa8106]

@jlurien As discussed at the meeting on 6th September, I drafted a use case of this booking feature as the following. I welcome your comments on this.

[Activities/Steps] Starts when: The customer application server makes a POST request to the QoD provisioning API to book creating a new QoD session resource with a specified start time and duration and an available QoS Profile, and optionally registers a callback URL for receiving notification events.

Step1: The platform of the API Provider switches the QoS Flow with requested QoS profile at the specified start time. In case the callback URL was registered, a result to switch QoS Flow is notified to the customer application server.

Ends when: The customer application server makes a DELETE request to the QoD Provisioning API, or the QoD session resource deletion was triggered automatically because the set duration has expired.

[Exceptions]
Several exceptions might occur during the QoD Provisioning API operations

• Fail to switch the specified QoS at the start time (e.g. due to lack of network resources)

[jlurien]

Thanks @Masa8106. We have to refine the details, for example around the statuses of the life cycle. We already have REQUESTED, AVAILABLE and UNAVAILABLE. One possibility is to keep status as REQUESTED until start time, or we may define a new status BOOKED, to make more explicit that booking request has been accepted and it is scheduled.

[hdamker]

or we may define a new status BOOKED, to make more explicit that booking request has been accepted and it is scheduled

What about SCHEDULED instead BOOKED?

[Masa8106]

Hi @hdamker, @jlurien, @eric-murray

Let me respond to some comments from you in the previous meeting on 4th October. I illustrated a draft state diagram which I assume at this moment.

    stateDiagram
    [*] --> Requested : API Invocation
    Requested --> Scheduled : Booking accepted
    Requested --> [*] : Booking declined
    Scheduled --> Available : Creation of QoS Flow
    Scheduled --> Unavailable : Failure to create QoS Flow
    Available --> [*] : Duration expiration, Delete booking
    Unavailable --> [*] : Delete booking

And regarding the question if the “booking” comes with reservation of resources or only a scheduling of the session/provisioning creation, I intend this API treats only a scheduling of the session/provisioning creation. This is because the original QoD API and QoD Provisioning API don't have resource reservation capability in my understanding. I think we can use APIs to reserve resources, e.g. NetworkSliceBooking API and/or Dedicated NW API, togather with this API, if needed.

[jlurien]

Another topic that was raised during the previous meeting is whether location should be considered for the booking, to accept the booking. If not, the implementation would need to decide at startTime whether the requested session/provisoning can be created at the device location in that moment, so an accepted booking wouldn't mean any guarantee, only a postponed decision depending on the device conditions at startTime.