API BACKLOG - Dedicated Networks: Scope Enhancement proposal

[TEF-RicardoSerr]

Hello team!
Recently, we have received in API Backlog an API proposal (camaraproject/APIBacklog#60) named Dedicated Networks.

This API aims to focus in the creation of virtual dedicated networks based in technologies such as slicing, APN/DNNs, RRP etc. Basically the proposal seems to fit very well as an Scope Enhancement of this subproject.

The thoughts of the API Backlog group are the following (minutes of last meetings are available here for your reference):

• As CAMARA is focusing in the North Bound interfaces the API result should be agnostic to underlying technology
• 4G and 5G NSA technologies should not be omited within the scope
• Makes no sense to have two APIs for the same use cases
• Telco language should NOT be used (not so many people knows what an APN or Network Slice is). Most of the developers/API consumers works in terms of SLAs or terms as private, improved QoS, isolated connectivity etc.

Proposal

There is two possible options:
Enhance the scope of the NetworkSliceBooking subproject:

• so to reach up to other technologies (DNN etc.) and generations (4G/NSA)
• make it easier to understand to API consumer by omiting Telco Terms and work in terms of SLA and characteristical names that allows ourselves (telcos) to keep selling specific technologies such as dynamic slicing

Make different repos

• To keep with separate working lines regarding each of the technologies (telco specific names should be adressed anyhow)
• Alignment should occur so maybe regular meetings for this may happen

[philipxujin]

It is recommended to separate these two sup-projects in the short term for the following reasons:
The target scenario for NSB is relatively clear, making it easier for CSPs and their API customers to validate and launch this API within a short period, thus maximizing the commercial value of the API in the short term.
The Dedicated Networks API has a broader scope and requires more clarity during the commercialization process. The two sets of APIs can be considered as long-term goals for potential collaboration.

[ShutingQing]

Hi Ricardo,

Thanks for syncronizing the info. Thorsten gave us a great presentation about Dedicated Networks API, we thought it a good idea for long term NaaS evolution, which aims to simplify the end users complexities of choosing the network.

Dedicated Network has a larger scope, as the proposal mentioned, it will conclude fixed and mobile network scenarios. There are more than tens of ways of dedicated network compositions. If it comes to end devices side, it also differs given on scenarios of cloud or site, etc. The composition of network differes, mapping to NaaS Service API it differs. In order to fit in one API, then foreseeable the API will be think and complex again. Meanwhile, in terms of network layer, as we can see right now, even if based on one specific scenario, to NaaS a complex network capability, it takes huge works in the network recompositions. So for the perspective of to have a commercial trial, we would like to keep the NaaS API simple as what the WG aiming to right now, once we have progress, and considering to add more stuffs in.

However I also see the value of Thorsten's proposal as a long term trial, that in the future, we do need to consider how to really realize the simplification of End Users facing with the complex, thick network situation. Probably this needs huge work to to the Automation in the Network Layer. Possible ways we can see as TMF Autonomous Network, as a way to solve the complexity of Network Layer.

So I would suggest to do "Dedicated Networks API" parallelly as different repo and API projects.

[Bart-Ericsson]

I think there is some misunderstanding on the proposal. The scope towards the developer is exactly the same.

The proposal leaves it to the operator to choose the technology used to realise the requested capability that the developer asks for. This can be any of the mechanisms mentioned by Thorsten in the presentation, being a slice or any of the other mechanisms mentioned. This is especially useful when 5G SA is not available in a region or if a fixed-network operator would want to adopt and offer the API.
The Camara API itself will be very similar to the one of Network Slice Booking as it does not mandate the technology it only needs the same information as the NSB proposal. One example of information needed can be seen in GSMA OPG.02 version 6 chapter 3.4.16 which also includes some cloud aspects.
If an operator decides to only use slicing in order to realise the dedicated networks then the internal logic for the operator is the same as with Network Slice Booking. If an operator wants to do more flavours then the internal logic increases but this is outside of the Camara scope. You can see this also in the initial message from @TEF-RicardoSerr

The result of having 2 APIs would in my opinion be that there are 2 nearly identical APIs with a different name, this would only confuse the developer further and be counterproductive for Camara.

[ShutingQing]

What excatly kind of "Dedicated Network" way of network resolutions that can be supported, have that been clarified?

[hdamker]

This is for now resolved by the decision within the TSC to create DedicatedNetworks as a new API Repository, ask both team to collaborate when the APIs are more visible and defer the final alignment to later. See https://wiki.camaraproject.org/display/CAM/2024-09-19+TSC+Minutes