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

Loading

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.

[Masa8106]

Hi @jlurien, I am fine with considering location for the booking.

Hi all,
Updates of User Story (Please find bold parts.) and state diagram are the followings:

[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, location 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.

The benefit for users is that they can secure the right to high quality connection service in advance, as the number of device which can utilize such service simultaneously is limited in an environment with limited radio resource.

[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)
-Detect malfunction (e.g. deletion of QoS profile, network trouble) by back-end system during Scheduled and Available status.

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

Loading

[jlurien]

Thanks @Masa8106 for the update. This makes more sense to me. If we add the location input to the booking request, I think that the use case is more relevant for the session scenario (to reserve certain QoS at certain location for a given period), than for the indefinite provisioning scenario, as a device is not likely to be at same location indefinitely.

[jlurien]

@Masa8106, as it was commented during the last meeting, this new functionality makes sense to be added as a new differentiated API. Even if we proceed with a PR here, the right WoW would be to open also a new issue in the API Backlog Working Group, proposing the new API, filling the required templates, and discussing the content within that WG. This would help also to socialize more the proposal and get more explicit support from interested parties.

[Masa8106]

@jlurien, thank you for the advice. I will try to create a issue in the API Backlog WG and to discuss it, in parallel with proceeding PR here.

[jlurien]

Thanks @Masa8106, fyi @jgarciahospital (who is leading the Backlog WG, to be aware of this)

[hdamker]

Reopening the issue as it was obviously closed by accident.