Scope conflict: qos-booking-and-assignment duplicates functionality of existing dedicated-networks API

[albertoramosmonagas]

Problem description
We would like to raise a concern regarding the recently introduced API qos-booking-and-assignment.yaml, contributed by T-Mobile US under the QoS Booking workstream.

This API introduces functionality — specifically the assignment of devices to dedicated network resources or slices — that already exists in the dedicated-networks API, which was previously approved through a formal API Proposal in the CAMARA backlog and developed under a separate working group.

Launching a second API with overlapping scope violates the CAMARA principle of “one functionality, one API”, undermines governance decisions already made, and introduces fragmentation that makes implementation more difficult for both operators and ecosystem partners.

Expected action

• The QoS Booking working group should review the scope of qos-booking-and-assignment.yaml and clarify why this functionality was introduced in parallel to an existing CAMARA API.
• If the intent is to cover use cases that differ from those in dedicated-networks, this should be clearly and explicitly justified, with proper coordination between the working groups.
• Otherwise, the API should be reconsidered, consolidated, or withdrawn to avoid long-term confusion and duplication.

Additional context

• The dedicated-networks API was developed and approved in a separate CAMARA workstream with a defined scope, which includes the assignment of devices to network slices or dedicated resources.
• The /assignDevices operation in qos-booking-and-assignment.yaml overlaps functionally with that API.
• We understand that T-Mobile US has been leading this contribution, but we urge the group to ensure proper coordination and adherence to established CAMARA governance.

[gmuratk]

@albertoramosmonagas

While I wasn’t a primary contributor, I’ve closely followed the development of this API from its inception.

Some quick insights:

• Regarding DedicatedNetworks overlap, the API has been discussed extensively over the past couple of months in bi-weekly meetings and documented on the LF CAMARA Confluence. Its creation as a separate API was based on guidance from the group after considering several alternatives. Relevant issues and PRs have also received thoughtful input from multiple contributors.
• Regarding separation of ‘booking’ and ‘Assignment’ construct, our position is that this together is one function -> booking doesn’t have value without uplift/assignment and uplift/assignment doesn’t have meaning outside of the booking that was done. Want to share that this is not a slam-dunk aggregation scenario.

Few of our (TMUS) key contributors are out for the next two weeks. I request holding off on any decisions until we’ve had a chance to weigh in.
cc: @murthygorty

[Masa8106]

The QoS Booking working group should review the scope of qos-booking-and-assignment.yaml and clarify why this functionality was introduced in parallel to an existing CAMARA API.

Just a comment.

Regarding the 1st bullet of the expected action, as you may know, we have made a comparison table here.
As we have a API release candidate now, we can update this table to clarify differences between two APIs from functionality perspective.
I believe this clarification helps our discussion to make any decision on way forward.

[albertoramosmonagas]

Thanks for the comments and for sharing additional context @gmuratk and @Masa8106,

We appreciate that the qos-booking-and-assignment API has been discussed in the QoS Booking workstream and that alternatives were considered. However, from a cross-WG perspective, there are points that remain concerning:

1. Scope conflict with dedicated-networks – The core function of assigning devices to dedicated network resources is already defined in the dedicated-networks API, approved through its API Proposal in a separate WG.
2. Governance principle – Even if booking and assignment are considered a single function, this overlap goes against CAMARA’s “one functionality, one API” principle and risks fragmentation.
3. Evidence from comparison – The table (thanks for sharing!, it was very helpful) already shows duplication in assignment logic, multi-device provisioning, and related flows.

Next steps: We will raise this in the next CAMARA backlog meeting so all members are aware and can provide input on how to address the overlap.

[murthygorty]

Thanks so much for the update @albertoramosmonagas .

One note on your first point, from my PoV:

• QoS Booking does NOT assume that the network is dedicated to the API caller and abstracts the network underpinnings from the API caller, much like other QoS/QoD APIs.

It also seems to me that the #1 is closely tied to #3, we can keep the major concerns to 2 rather than 3

@gmuratk @RamTMO

[tlohmar]

Thanks for bringing up the topic. There is a scope overlap between the three APIs. The scope overlap between QoS Booking and Dedicated Networks has been discussed in Dec'24 and reported to API Backlog (link). With the new QoS Booking & Assignment API, we have a third API. All three APIs are motivated by use-cases and address resource reservations. The key difference between the API is on the level of complexity.

• QoS Booking & Assignment is more sophisticated than QoS Booking, since it adds two features (decoupling of devices from the booking and allow booking of the same QoS profile for multiple devices).
• Dedicated Networks further allows booking of multiple QoS Profiles for the same device. In principle, QoS Booking and Assignment can also allow assigning multiple QoS profiles (aka bookingIds) to the same device, since there is no error code nor any restricting text.

But, what is happening, when a fourth or a fifth API resource reservation is proposed? For example, there can be a need for another more feature-rich API than QoS Booking, but simpler than QoS Booking & Assignment...

[hdamker]

As Dedicated Networks has accepted the proposal which was proposed by @tlohmar and me to the groups, to join the DedicatedNetworks Sandbox API Repository into the Quality On Demand (name to be changed) Sub Project, we can plan the next steps and work on the alignment of the family of "Booking" APIs.

But first we need to formalize the join of DedicatedNetworks. Next steps:

• Create an issue within QualityOnDemand to decide to join DedicatedNetworks into the Sub Project
• Create an issue (within QualityOnDemand) to collect proposal for a new Sub Project name
• Put both issues on the agenda of the QualityOnDemand call on Friday, September 5th
• Start the content discussion about how the APIs can get aligned and create respective issues

BTW: we don't need to wait until Spring25, as all three APIs are initial v0.1.0 we can immediately work on the next versions and publish them whenever we see that it makes sense.