From 16e8268419bd0c28e6a8d7c3f81f490f1d35051d Mon Sep 17 00:00:00 2001 From: Murat Karabulut <88037779+gmuratk@users.noreply.github.com> Date: Fri, 16 Oct 2026 15:32:02 -0400 Subject: [PATCH 1/5] Fix QoS B&A Validation Warnings for Snapshot r2.2 --- .../qos-booking-and-assignment.yaml | 26 +++---------------- 1 file changed, 4 insertions(+), 22 deletions(-) diff --git a/code/API_definitions/qos-booking-and-assignment.yaml b/code/API_definitions/qos-booking-and-assignment.yaml index 9472054..43c78fe 100644 --- a/code/API_definitions/qos-booking-and-assignment.yaml +++ b/code/API_definitions/qos-booking-and-assignment.yaml @@ -138,9 +138,8 @@ info: # Identifying the device from the access token This API requires the API consumer to identify a device as the subject of the API as follows: - - When the API is invoked using a two-legged access token, the subject will be identified from the optional `device` or `devices` object, which therefore MUST be provided. - - - When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token. In this case, only one device can be provided at a time. + - When the API is invoked using a two-legged access token, the subject will be identified from the optional `device` object, which therefore MUST be provided. + - When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token. This approach simplifies API usage for API consumers using a three-legged access token to invoke the API by relying on the information that is associated with the access token and was identified during the authentication process. @@ -1116,6 +1115,7 @@ components: * `BOOKING_UNKNOWN_ERROR` - An unknown error occurred. * `BOOKING_ACCEPTED` - Deprecated. Use `BOOKING_SCHEDULED` instead. type: string + pattern: ^[A-Z][A-Z0-9_]*$ maxLength: 256 example: "BOOKING_SCHEDULED" @@ -1137,6 +1137,7 @@ components: * `BOOKING_EXPIRED` - The booking referenced has expired and is no longer active. * `BOOKING_TERMINATED` - The booking was terminated by the operator. type: string + pattern: ^[A-Z][A-Z0-9_]*$ maxLength: 256 example: "ASSIGNMENT_COMPLETED" @@ -1578,25 +1579,6 @@ components: bookingStatus: "ACTIVATED" statusInfo: "BOOKING_ACTIVATED" - BOOKING_CANCELLED: - summary: Booking Cancelled (notification payload) - description: Example `booking-status-changed` CloudEvent payload when a booking is successfully cancelled. - value: - bookingId: "8e2f6f30-0a1c-4c6b-92e1-1bd05aef1c58" - bookingDeviceCount: 15 - remainingDevices: 15 - qosProfile: "QOS_MEDIA_BROADCAST" - startTime: "2025-10-27T15:00:00.000Z" - duration: 3600 - serviceArea: - areaType: "CIRCLE" - center: - latitude: 37.735851 - longitude: -127.10066 - radius: 100 - bookingStatus: "TERMINATED" - statusInfo: "BOOKING_CANCELLED" - CANCELLATION_PENDING: summary: Cancellation is Requested description: Delete a booking using a valid `bookingId`. Delete operation is pending as operator may need more time to process the request. From bc9e280aa3ea1f0a740a8e28d0f03ac5a6e7ee5e Mon Sep 17 00:00:00 2001 From: Murat Karabulut <88037779+gmuratk@users.noreply.github.com> Date: Fri, 16 Oct 2026 15:32:42 -0400 Subject: [PATCH 2/5] Update scenario for deleted QoS booking verification --- .../qos-booking-and-assignment-deleteBooking.feature | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/code/Test_definitions/qos-booking-and-assignment-deleteBooking.feature b/code/Test_definitions/qos-booking-and-assignment-deleteBooking.feature index 186ccbb..875aebf 100644 --- a/code/Test_definitions/qos-booking-and-assignment-deleteBooking.feature +++ b/code/Test_definitions/qos-booking-and-assignment-deleteBooking.feature @@ -55,10 +55,9 @@ Feature: CAMARA QoS Booking and Assignment API, vwip - Operation deleteBooking @qos_booking_and_assignment_deleteBooking_03_booking_not_readable_after_deletion Scenario: A deleted QoS booking can no longer be read Given an existing QoS booking created by operation "createBooking" with no devices assigned + And the QoS booking has been deleted with operation "deleteBooking" and the deletion has completed And the path parameter "bookingId" is set to the value of the identifier for that QoS booking - When the request "deleteBooking" is sent - Then the response status code is 204 - When the request "getBookingById" is sent with the same path parameter "bookingId" + When the request "getBookingById" is sent Then the response status code is 404 And the response property "$.status" is 404 And the response property "$.code" is "NOT_FOUND" From 7d521816d66027d167cfc558fc6a49522203d9bc Mon Sep 17 00:00:00 2001 From: Murat Karabulut <88037779+gmuratk@users.noreply.github.com> Date: Fri, 16 Oct 2026 15:34:07 -0400 Subject: [PATCH 3/5] Update createBooking feature for getBookingById scenario Refactor the getBookingById scenario to streamline the process of verifying the created booking details. --- ...ooking-and-assignment-createBooking.feature | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/code/Test_definitions/qos-booking-and-assignment-createBooking.feature b/code/Test_definitions/qos-booking-and-assignment-createBooking.feature index 1bd139a..c576d9a 100644 --- a/code/Test_definitions/qos-booking-and-assignment-createBooking.feature +++ b/code/Test_definitions/qos-booking-and-assignment-createBooking.feature @@ -119,17 +119,15 @@ Feature: CAMARA QoS Booking and Assignment API, vwip - Operation createBooking @qos_booking_and_assignment_createBooking_08_booking_readable_after_creation Scenario: The created booking can be read with getBookingById - Given the request body is compliant with the schema at "#/components/schemas/BookingInput" - When the request "createBooking" is sent - Then the response status code is 201 - And the response property "$.bookingId" exists and is a valid UUID - When the request "getBookingById" is sent with the path parameter "bookingId" set to the value of "$.bookingId" of the creation response + Given a QoS booking has been created successfully with operation "createBooking" + And the path parameter "bookingId" is set to the value of "$.bookingId" of the createBooking response + When the request "getBookingById" is sent Then the response status code is 200 - And the response property "$.bookingId" has the same value as in the creation response - And the response property "$.qosProfile" has the same value as in the creation request body - And the response property "$.startTime" has the same value as in the creation request body - And the response property "$.duration" has the same value as in the creation request body - And the response property "$.serviceArea" has the same value as in the creation request body + And the response property "$.bookingId" has the same value as in the createBooking response + And the response property "$.qosProfile" has the same value as in the createBooking request body + And the response property "$.startTime" has the same value as in the createBooking request body + And the response property "$.duration" has the same value as in the createBooking request body + And the response property "$.serviceArea" has the same value as in the createBooking request body @qos_booking_and_assignment_createBooking_09_event_notification Scenario: Event is received when a booking status changes after using sink From 557df06016a4c0a7ac3aa4d184ce721b51c7d4a4 Mon Sep 17 00:00:00 2001 From: Murat Karabulut <88037779+gmuratk@users.noreply.github.com> Date: Fri, 16 Oct 2026 15:34:45 -0400 Subject: [PATCH 4/5] Refactor scenario for assigned devices retrieval --- .../qos-booking-and-assignment-assignDevices.feature | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/code/Test_definitions/qos-booking-and-assignment-assignDevices.feature b/code/Test_definitions/qos-booking-and-assignment-assignDevices.feature index 5dee00e..ea773d0 100644 --- a/code/Test_definitions/qos-booking-and-assignment-assignDevices.feature +++ b/code/Test_definitions/qos-booking-and-assignment-assignDevices.feature @@ -63,14 +63,13 @@ Feature: CAMARA QoS Booking and Assignment API, vwip - Operation assignDevices And the response property "$.devices" may not contain the assigned device information @qos_booking_and_assignment_assignDevices_03_assigned_devices_listed - Scenario: Assigned devices are returned by getDevicesByBookingId + Scenario: Assigned devices are returned by getDevicesByBookingId Given the header "Authorization" is set to a valid 2-legged access token - And the request body property "$.devices" is set to a valid array of device identifiers compliant with the schema at "#/components/schemas/Devices" - When the request "assignDevices" is sent - Then the response status code is 201 - When the request "getDevicesByBookingId" is sent with the same path parameter "bookingId" + And devices have been assigned to the QoS booking with operation "assignDevices" using a valid array of device identifiers compliant with the schema at "#/components/schemas/Devices" + And the path parameter "bookingId" is set to the identifier of that QoS booking + When the request "getDevicesByBookingId" is sent Then the response status code is 200 - And the response property "$.devices" contains the device identifiers returned by the assignment response + And the response property "$.devices" contains the device identifiers returned by the assignDevices response # CONDITIONAL: only applicable if the API provider supports partial assignment @qos_booking_and_assignment_assignDevices_04_partial_success From a54a5204bfeb2d6d5f6d1ef01f6a345cb83d378c Mon Sep 17 00:00:00 2001 From: Murat Karabulut <88037779+gmuratk@users.noreply.github.com> Date: Fri, 16 Oct 2026 15:35:24 -0400 Subject: [PATCH 5/5] Refactor scenario for released devices in feature file Updated scenario for released devices to include booking ID parameter and removed redundant request. --- .../qos-booking-and-assignment-releaseDevices.feature | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/code/Test_definitions/qos-booking-and-assignment-releaseDevices.feature b/code/Test_definitions/qos-booking-and-assignment-releaseDevices.feature index 6c8c74e..8a40d3c 100644 --- a/code/Test_definitions/qos-booking-and-assignment-releaseDevices.feature +++ b/code/Test_definitions/qos-booking-and-assignment-releaseDevices.feature @@ -64,10 +64,9 @@ Feature: CAMARA QoS Booking and Assignment API, vwip - Operation releaseDevices @qos_booking_and_assignment_releaseDevices_03_released_devices_not_listed Scenario: Released devices are no longer returned by getDevicesByBookingId Given the header "Authorization" is set to a valid 2-legged access token - And the request body property "$.devices" is set to a valid array of device identifiers that are assigned to the QoS booking - When the request "releaseDevices" is sent - Then the response status code is 200 - When the request "getDevicesByBookingId" is sent with the same path parameter "bookingId" + And devices assigned to the QoS booking have been released with operation "releaseDevices" + And the path parameter "bookingId" is set to the identifier of that QoS booking + When the request "getDevicesByBookingId" is sent Then the response status code is 200 And the response property "$.devices" does not contain any of the released device identifiers