qos-booking-and-assignment: An end-point to get the current state of the given device in the context of a booking

[RamTMO]

Problem description
A new API endpoint is needed to allow owners of a QoS booking and/or owners of devices within that booking to retrieve the status of a specific device(s). This status is critical for providing valuable, real-time information about the device's state in the context of a QoS booking.

Possible evolution
The current API lacks a standardized way for users to query the detailed status of a device associated with a QoS booking. This results in a lack of visibility, making it difficult for stakeholders to understand the operational state of their devices. The required status information includes, but is not limited to:

Device is not in booking: Device is not visible to booking, it is not in the booking

Booking not open: Device is part of the booking but not yet operational

Device is active: Schedule has started and device is fully active

Device is inactive: Schedule has started and device is not actively operating

Booking closed: Device is in the booking, but schedule is closed

Device is outside perimeter: Schedule has started and the device seem to move out of the perimeter and lost agreed QoS

Device status unknown: There are situation device status is not known or confidential and can't be disclosed

Alternative solution

Additional context

@murthygorty
@gmuratk

[tlohmar]

Good list. I start getting multiple questions:

allow owners of a QoS booking and/or owners of devices

What is the consequence on authorization, when different entities are using the API? We seem to start looking onto B2B2C or B2C, correct?

Device is active: Schedule has started and device is fully active

Is this implying some additional realization assumptions, e.g. that the QoS profile has been activated for the device (similar like QOS Provisioning, but time limited)?

Device is inactive: Schedule has started and device is not actively operating

What does "not actively operating" mean? The user is not sending traffic?

Device is outside perimeter: Schedule has started and the device seem to move out of the perimeter and lost agreed QoS

is this "device location tracking" an optional feature?

[RamTMO]

@tlohmar

Yes, it supports both B2B2C, B2B, and B2C -- regarding B2C, it is jurisdiction based; some countries/states might have laws that will prohibit the differentiated QoS for the consumers. The authorization might be a bit complicated - it is like delegation. Company B1 worked with Operator O1 and got the booking completed, including the required financial agreement. Now company B1 does not have the required devices; it delegates the authority to company B2 to deliver the service. These are operation and administrative tasks and can be handled by the operator directly through their service layer off of CAMARA per my understanding.

Yes, When the schedule starts all the successfully assigned devices are in the active state (in the QoS booking perspective) when they are in the agreed service area and are actively transmitting.

We can discuss this. The booking started, the device is in the booking, and seems to be within the perimeter, but not actively transmitting. There will be some overlap on the status codes like: inactive, out of perimeter, status unknown. A discussion topic.

The perimeter is the grid cover or overlay of the requested area. If the operator can detect if the device moves out this cover, the operator can return this status, and it is optional. We can say the device is in the booking, schedule started, but the device is currently located out of perimeter. So, it MAY not get the required QoS.

Overall, the specification won't mandate the operator SHOULD detect, conclude, and report the status exactly. Realistically, it is not possible. The operator makes the best effort to provide the state/status of the device in the context of booking.