[Backlog] Question on QoD booking proposal

[jgarciahospital]

(As discussed in API backlog https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/52068488/2024-12-12+API+backlog+minutes)

Problem description

QoD booking API is proposed in CAMARA backlog as an enhancement of current QoD API "family". During Backlog discussion, questions are raised about the relationship with Dedicated Network APIs.

Q: Will this API be a new repo or a new API of QoD repo?

@tanja de Groot Could QoS booking API be considered as another "variant" of the Dedicated Networks API?

@Masaharu Hattori: Dedicated Network is focused on booking network resources, while QoD booking is related to book a quality session, independent to specific resources. Dev schedules just a QoD session to fulfill a required profile.

@jan Friman Dedicated Networks is handling this use cases of booking resources to fill the needs of an app, closely related to this proposal

@eric Murray proposal inherits from QoD API, but may consider a sue case overlap as booking resources.

LINK TO API PROPOSAL: camaraproject/APIBacklog#155

Expected action

To discuss in Dedicated Network (Monday 16th 9UTC)

CC: @eric-murray @tanjadegroot @Masa8106 @FrimanJan @jgarciahospital

[Masa8106]

@jgarciahospital, thank you for raising up this topic as issue.

To all, I will upload the slide to show a relation between QoS booking proposal and Dedicated network API. Please find the following, especially slide#6:
APIproposal_QoS-Booking_r2.pdf

I hope to keep discussion here in order to clarify the relation.

[Masa8106]

@tlohmar, some comments from my side:

Connectivity management for each device by Dedicated network API

Actually I was wondering how it can be realized, as far as I saw the proposal document of Dedicated network API. However, in the API design considerations (PR#15), I can find considerations for QoD API usage are mentioned. This is same with what I mentioned, that is, QoD API (QoS booking API in some case) may be used for connectivity on the top of Dedicated network API.

Some “B” would not know how many “tickets” can be sold (since they don't know capacity).

When we assume the above scenario where "B" uses both APIs, the "B" first book network resources via Dedicated network API and know how many tickets the "B" can sell, and the "B" start selling tickets to end users.

[tlohmar]

@Masa8106 , thanks for the comments and the slides.

wrt Slide #6 of APIproposal_QoS-Booking_r2.pdf:

• Yes, the key difference is the number of devices, the DN API aims at multiple devices. It is allowed to have only one device, but I see this as a rather niche case for the DN API.
• QOD booking seems to target the "2C" cases, either B2C or B2B2C, where is single device can benefit from a QOD Session during a time window. Is there a "target service area" concept in QOD or should the reservation target the entire network area?

I can find considerations for QoD API usage are mentioned. This is same with what I mentioned, that is, QoD API (QoS booking API in some case) may be used for connectivity on the top of Dedicated network API.

This aspect is indeed missing and needs to be addressed. The idea is that the QOD API (or other APIs) can be used, when the Dedicated Network is available (i.e. in activated state)

[Masa8106]

@tlohmar , thank you for your comment.

QOD booking seems to target the "2C" cases, either B2C or B2B2C, where is single device can benefit from a QOD Session during a time window. Is there a "target service area" concept in QOD or should the reservation target the entire network area?

At this moment, there is no "target service area" concept in QOD. This concept will introduce by QoS Booking API for the first time in QoD API family. This is because I assume the use case of QoS Booking API is premium connection ticket service which is available at particular place such as event venue. On the other hand, I also assume a case where the reservation target is the entire network area if "target service area" is not specified by API invoker.

Anyway, discussion on "target service area" concept is about to start soon.