qos-booking-and-assignment: A new endpoint needed to check QoS availability

[RamTMO]

Problem description
The current API lacks a pre-booking inquiry function. Users have no way to verify if their desired QoS profile is feasible before committing a booking request. This forces users to attempt bookings, which can then fail due to resource constraints or lack of availability. Furthermore, users cannot determine the maximum capacity of devices that can be supported for a given QoS profile, time, and location, which is crucial for capacity planning and efficient resource utilization.

Possible evolution
A new, read-only endpoint is required to allow a user to check the availability of a specific QoS profile for a given time, duration, and geographic area, without creating a booking. This endpoint should also return the maximum number of devices that can be supported by the operator for the requested Service Area and QoS profile, without degrading the quality.

Alternative solution

Additional context

@murthygorty
@gmuratk

[tlohmar]

Users have no way to verify if their desired QoS profile is feasible before committing a booking request.

Is this about (A) a technical constrain (e.g. the deployed carrier bandwidth can only allow for 5 simultaneous QoS Profile usages) or more (B) an operational constrain (e.g. a number of books have already been accepted)?

The heading contains "device capacity": Is this about the capacity of a single device? Or about "how many devices with the same QoS profiles can be supported in the targeted area"?

[RamTMO]

@tlohmar My intention was to cover both -- irrespective of whether it is technical or operational constrain the user should able to understand whether the required QoS is available in that area, for the required number of devices, during the requested time. In general, this API is useful to understand what do I need (or I get) before I sign the contract that involves $$. It may happen via operator's web/software platform for these type of services. Some operator might do it manually or using different offline methods.

This endpoint should return:

1. Supported / Not. (YES or NO)
2. In both situations the endpoint will return
   Maximum number of devices supported for the requested qos, area, and time
   Actual area cover based on the operator grid layout (optional -- we don't know how many operator can provide this level of details) - worst case just return the actual requested area

Regarding device capacity: Agree, it is cofusing. capacity in network world will be interpreted as capacity of a device. It should be device count, better remove it. Will fix it.

[RamTMO]

We should evaluate PredictiveConnectivityData in this respect (Thanks @gmuratk) . If we plan to use this API for our QoS inquiry then we should review and work with them to support common requirements. Let us discuss.

1. Standardized QoS Profile should be used. Otherwise will confuse our customers, as well as it is not useful to our requirements.
2. Return value should have some useful information for the customer to make appropriate operational and financial decision, like how many devices can be supported etc.,
3. The use of geohash in that API is good; but for the end user it is meaningless -- they may say, I want to know the qos availability of this conference center, given a circle with co-ordinates and radius, please let me know the availability (Yes/no) if YES, what are the bounding coordinates(polygon). This translation can happen at the API layer or at the App layer. Debatable. Again, it is optional.

[RamTMO]

There is another option to incorporate this as a return value of the booking itself.

So there are three options to start with:

1. Seperate end point
2. Work with PredictiveConnectivityData
3. Incorporate it part of the current booking API as an extended return value

We can keep these options open for discussion