Skip to content

Address Issue #64 #76

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
RamTMO wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Address Issue #64 #76

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
54005a2
Address Issue #64
RamTMO Nov 21, 2025
f20ee2d
Fixed lint errors
RamTMO Jan 8, 2026
c27ab0c
Second set of lint fixes
RamTMO Jan 8, 2026
6c834cc
Linit fixes - 3rd attempt
RamTMO Jan 8, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 51 additions & 37 deletions code/API_definitions/qos-booking-and-assignment.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,18 +103,15 @@ paths:
- QoS Booking
summary: This operation reserves required QoS in advance up to a certain number of devices in certain serviceArea and time slot. The devices have to be attached with a subsequent operation.
description: |
Triggers a new booking in advance and assign this reserved booking profile to one or more devices when the devices are ready.
- If the booking is completed synchronously, the response will be 201 with `status` = `SUCCESSFUL`.
- If the booking request is accepted but not yet completed, the response will be 201 with `status` = `PENDING`.
- If the operator determines synchronously that the booking request cannot be fulfilled, the response will be 201 with `status` = `FAILURE`.
- If the operator is not able to determine the booking availability immediately and the request includes a notification callback, the client will receive a `status-changed` event with the outcome of the process.
- The operator determines immediately:
- `SUCCESSFUL` or `FAILURE`
- If the operator needs more time to determine the availability
- `PENDING`
- The devices can be assigned anytime from the time booking is successful (`status` = `SUCCESSFUL`) and before the scheduled duration ends.
This operation reserves a Quality of Service (QoS) booking for a specified number of devices, service area, and scheduled time/duration.
Devices can be assigned to the booking at any time after the reservation is successful and before the scheduled end-time.
- `Pre-assigned devices :` These devices will be automatically provisioned and activated with the requested QoS profile exactly when the scheduled start time arrives.
- `Late-assigned devices:` Devices assigned after the schedule starts (but before it ends) will be provisioned and activated with the requested QoS profile immediately upon assignment.
This operation will return with the following responses:
- `HTTP 201 (status: SUCCESSFUL):` The operator was able to confirm the booking immediately.
- `HTTP 202 (status: PENDING). :` The operator is unable to confirm immediately, and the booking status is pending. A subsequent notification will be sent to confirm the final status, if available.
- `HTTP 4xx (Failure Condition) :` The operator determined that the booking is unavailable. The response will include specific status codes and descriptions detailing the error.
- Respective `statusInfo` contains additional information under certain conditions.

operationId: createBooking
parameters:
- $ref: "#/components/parameters/x-correlator"
Expand Down Expand Up @@ -166,7 +163,7 @@ paths:
- notificationsBearerAuth: []
responses:
"201":
description: Booking created
description: Booking creation is successful.
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
Expand All @@ -177,8 +174,18 @@ paths:
examples:
BOOKING_SUCCESSFUL:
$ref: "#/components/examples/BOOKING_SUCCESSFUL"
BOOKING_FAILURE:
$ref: "#/components/examples/BOOKING_FAILURE"
"202":
description: |
Booking request is accepted but pending.
Confirmation of success or failure will be sent as a callback notification.
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/BookingOutput"
examples:
BOOKING_PENDING:
$ref: "#/components/examples/BOOKING_PENDING"
"400":
Expand All @@ -205,12 +212,10 @@ paths:
- QoS Booking
summary: Get the Booking information for a given QoS Booking identified by `bookingId`.
description: |
This endpoint gets booking information for the given bookingId.
- A booking request may be failed (`status` = `FAILURE`). `statusInfo` contains additional information.
- Based on the status of the booking, an appropriate error message will be returned.
- If a booking is available (`status` = `SUCCESSFUL` and booking is active) then this endpoint will return the booking information along with number of devices still can be assigned to the booking.
- `statusInfo` contains additional information under certain conditions.

This operation is synchronous and retrieves the details of an existing Quality of Service (QoS) booking using its unique identifier (`bookingId`). This `bookingId` is the identifier returned by the initial booking operation upon successful creation.
Response Scenarios:
- `HTTP 200 (status: SUCCESSFUL):` The booking details are successfully retrieved and returned in the response body along with the remaining number of devices still can be assigned to the booking.
- `HTTP 4xx (Failure Condition) :` The request failed, and an appropriate HTTP 4xx error code is returned with a specific status and description.
operationId: getBookingById
parameters:
- $ref: "#/components/parameters/BookingId"
Expand Down Expand Up @@ -245,18 +250,17 @@ paths:
delete:
tags:
- QoS Booking
summary: Cancel an existing QoS Booking
summary: This operation cancels an existing QoS Booking and release the associated resources.
description: |
Cancel an existing booking and release resources related to that booking.
- The QoS Booking must have been created by the same API client given in the access token.
- `SUCCESSFUL` and `FAILURE` condition of deleting a booking is based on the implementation of the operator.
- Operator SHOULD properly document their 'delete' behavior. Following are some guidelines:

- If a booking is made, and no devices are assigned - `SUCCESSFUL`. Return message will contain only booking info.
- If a booking is made, and devices are assigned, but session is not active - `SUCCESSFUL`. Return message will contain information related to booking.
- If a booking is made, and devices are not assigned, but session is active - `SUCCESSFUL`. Return message will contain only booking info
- If a booking is made, and devices are assigned, and the session is active - `SUCCESSFUL / FAILURE` is determined by the operator. The Operator may terminate the session, release the devices, and release the booking.

This operation cancels and deletes a specific QoS booking using its unique identifier and releases the resources related to that booking. It supports both synchronous and asynchronous processing.
Constraints & Notes:
- The Quality of Service (QoS) booking must have been created by the same API client identified in the access token.
- The SUCCESSFUL and FAILURE conditions for a deletion are dependent on the operator's specific implementation.
- Operators SHOULD properly document their `Booking Cancellation` behavior with clear policies and the respective terms and conditions.
Response Scenarios:
- `HTTP 200 (status: SUCCESSFUL):` The booking was deleted immediately (synchronous success).
- `HTTP 202 (status: PENDING). :` The request has been accepted for processing, but the deletion is not yet complete (asynchronous processing). A subsequent notification will be sent to confirm the final status.
- `HTTP 4xx (Failure Condition) :` The request failed, and an appropriate HTTP 4xx error code is returned with a specific status and description.
operationId: deleteBooking
parameters:
- $ref: "#/components/parameters/BookingId"
Expand Down Expand Up @@ -307,14 +311,12 @@ paths:
summary: Assign one or more devices to an existing QoS Booking identified by `bookingId`
description: |
This endpoint allows the end user to assign one or more devices to the existing QoS Booking.
- status = `SUCCESSFUL` if the assignment is successful for all the devices, and the network is available for the said devices to connect and use them at the requested time
- status = `FAILURE` if the assignment is unsuccessful and the 'statusInfo' will have more information.
- If the assignment is successful for all the devices, the call will return 201 success code with status `SUCCESSFUL` and the network is available for the said devices to connect and use them at the requested time
- If the assignment request failed for some reason, this call we be retured with 4xx error code with appropirate status codes
- This is an asynchronous call, and status = `PENDING` if the network is still working on your request. A callback will come with appropriate status.
- If the network could not assign all the requested devices, then status = `PARTIAL_SUCCESS` and the `statusInfo` will have additional information.
- If a 2-legged access token is used, then the device details SHOULD BE provided as part of the input, and the output will return the array of actually assigned devices.
- If a 3-legged access token is used, then the device information are identified from the access token, so only one device is implicitly assigned, and the return value may not contain the assigned device information


operationId: assignDevices
parameters:
- $ref: "#/components/parameters/BookingId"
Expand Down Expand Up @@ -384,8 +386,22 @@ paths:
$ref: "#/components/examples/ASSIGNMENT_FAILURE_1"
ASSIGNMENT_FAILURE_2:
$ref: "#/components/examples/ASSIGNMENT_FAILURE_2"

"202":
description: |
Assignment request is accepted but pending decision.
Once the decision is made a callback notification will be sent with appropirate success or failure Confirmation
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/DeviceAssignmentOutput"
examples:
ASSIGNMENT_PENDING:
$ref: "#/components/examples/ASSIGNMENT_PENDING"

"400":
$ref: "#/components/responses/CreateBookingOrAssign400"
"401":
Expand Down Expand Up @@ -526,15 +542,13 @@ paths:
summary: Retrieves all the bookings that corresponds to a device
description: |
Querying for QoS Booking resource information details for a device.

**NOTES:**
- The access token may be either 2-legged or 3-legged.
- If a 3-legged access token is used, the subject associated with the QoS Booking must also be associated with the access token. In this case the optional `device` parameter MUST NOT be provided in the request.
- If a 2-legged access token is used, the device parameter must be provided and identify a device.
- The QoS Booking must have been created by the same API client given in the access token.
- If no QoS booking is found for the requested device, an empty array is returned.
- This call uses the POST method to comply with the CAMARA Commonalities guidelines for sending sensitive or complex data in API calls. Since the device field may contain personally identifiable information, it should not be sent via GET.

operationId: retrieveBookingByDevice
parameters:
- $ref: "#/components/parameters/x-correlator"
Expand Down