Hello Thorsten.

Telefónica sees that the API could be segregated into 3 lines of work:

Dynamically manage QoD Policies

• Empower developers to create dynamic QoD profiles (independantly from traditional telco terms)
• This should be presented as a scope enhancement in the QoD subgroup and we will support this

Planning the assignment of QoS profiles

• Regarding QoD, current capabilities are based in an "assign now" view the proposal would be to enrich the way to assign QoS including temporal (eg. start not before than ) or spatial (eg. QoS for this geografic zone) planning
• This should be presented as a scope enhancement in the QoD subgroup and we will support this

Provisioning Privates Networks over public network

• Create a transactional API for Dedicated Network provisioning, characterized by parameters (including QoD Profile aligned with QoD policies of the QoD subproject). The API will determine viability and pre-reserve resources while awaiting line assignment.
• Our view is that given that the Slicing technology would be part of this potential working line, the NSB subproject scope should be reviewd so to not have two groups adressing the same use case.

It is important and, in fact, it is defined in the guidelines not to have references to specific telco technologies as you are proposing so maybe there is a good oportunity to re-visit the Scope of Network Slice Booking subproject. For us, dynamic Slicing proves such an interesting technology we would like to be part of, but it is important not to focus only in this technology (which actually is only available in 5G SA), but also support 4G and 5G NSA use cases.

Hi Ricardo,

thanks for the feedback. I also see a good re-use of QOD and other CAMARA features. Would be good to first progress on the last line (Provisioning Privates Networks over public network), before suggesting changes to existing APIs. One scenario is certainly allowing “on-demand” QOD API calls for the time, when dedicated network is in available state, and for devices, which are located in the service area of the dedicated network.

maybe there is a good oportunity to re-visit the Scope of Network Slice Booking subproject

Yes. Certainly an option.

More discussions can be found here. camaraproject/NetworkSliceBooking#39

1. The idea of dedicated network resources is good. But need to figure out what kind of network resolutions, what exactly of network compositions it support.
2. Correspondingly technical resolutions of each way of resolutions that Dedicated Network API is going to support is suggested to analyze.

The reason of the above two suggestions is because, when we look into the network layer, especailly the real situation of CSP network, network situations differ a lot. 1) The network requirement of parameters differ, in terms of way of composition, in terms of access situations. 2) To fulfill the NaaS Service API, network layer needs lots of adaptions. Most of the job related to dedicated network resources rely on human work.

Based on that, we can see that 1) How the service api will possibly be like? Can we really make it simple, and that means the idea is applicable, and that's great. Or will that be really very complex, since it need to include all way of dedicated networks compositions?

@ShutingQing
Can you clarify if you (and the Network Slice Booking sub-project) believe there is enough of a scope overlap between this new proposal and the existing Network Slice Booking sub-project such that this proposal should be considered as a scope enhancement to Network Slice Booking?

If so, then the proposal can be made a scope enhancement to Network Slice Booking, and any new API would get its own repository, but would be discussed in the existing Network Slice Booking meetings.

If not, then a new sub-project would be created for Dedicated Networks.

My view on the differences between the proposals, and to QoD, is:

• Network Slice Booking is for API consumers that know they will definitely require guaranteed QoS via a network slice at some point in the near future, in a known location, and for an extended period of time
• Dedicated Networks is for API consumers that know they will definitely require enhanced QoS at some point in the near future, in a known location, and for an extended period of time, but do not really care how that enhanced QoS is delivered so long as it is compatible with their device(s)
• QoD is for API consumers who want an immediate (unpredicted) short-term boost to the service QoS wherever they happen to be at the time

Of course, we could imagine one "super QoS API" that covers all these scenarios, but I think there is enough scope difference that these can all be considered separate APIs for the moment.

@eric-murray Thanks Eric for your info. Given on the current infomation from "Dedicated Network" material, my view on that is:

Dedicated Network focus on "Dedicated Network" Resources, and see it as a NaaS Product. From Service API layer, it's goal and direction is to include more scenarios in only one Service API. And later it will be one NaaS product selling dedicated network resources.

Network Slice Booking API see "Slice" specifically as a NaaS Product. From Service API layer, it's goal and direction is to focus on Slice related features only, and go to more functions, which are around slice, in later. And later it will be a NaaS Product selling slice.

So I agree with you that there is enough scope differences, especially from the goal and direction, and to those influences on API design, that we need to consider them as different APIs at the current moment.

Based on that, we can see that 1) How the service api will possibly be like? Can we really make it simple, and that means the idea is applicable, and that's great. Or will that be really very complex, since it need to include all way of dedicated networks compositions?

I would suggest to clarify these questions first before moving to TSC. Since currently it's like we only know the idea. "Dedicated Network" is a pretty big scope, that's good, but I'm worrying whether it's applicable or possible to include all ways of "dedicated network resolutions/situations"? From my perspective, I think it could be very hard, since the service API will be super complex. If we can not include all situations, which ways of dedicated network resources situations the API can support? This is better to figure it out.

As per TSC decision for this proposal:

Start the work in a sandbox (repo) and then with provided assets check/reassess collision/overlap with other CAMARA API (like network slicing booking API but other APIs could be affected)

Repo is to be created, @tlohmar @tanjadegroot @jgarciahospital @eric-murray (main contacts used, please include those who may be more related to this API if needed) please provide list of maintainer/codeowners (name, company, github user)

Hi @jgarciahospital

For Vodafone:
Codeowner: @eric-murray
Maintainer: @SteveV-Vodafone

@jgarciahospital @tanjadegroot @tlohmar @eric-murray @SteveV-Vodafone @MarkusKuemmerle

https://github.com/camaraproject/DedicatedNetworks is created. Please see camaraproject/DedicatedNetworks#3 and camaraproject/DedicatedNetworks#2 as first issues.

Current Summary: