Scope of Network Slice Booking Work Group

[tlohmar]

Problem description Not all 5G deployments support the “Network Slice” feature, specifically 5G-NSA deployments (and 4G deployments). There are other tools available (like prioritized DNNs) to provide a similar or even same behavior. Does this WG only focus on 5G-SA capabilities (meaning, is it a prerequisite for the API, that the network deployment supports the Network Slice feature)? A result could be, that an additional API is needed, when other tools like DNNs are used to offer the same / similar network capability.

Device Connection Management: A Network Slice is not automatically becoming available to all connected devices. Only authorized devices (per subscription) can access the Network Slice. The Network Slice owner should be able to influence, which devices (per subscription) get access to the reserved Network Slice. Is the workgroup looking into APIs for device connection activation, so that the owner of the booked Network Slice can manage the access (to the Network Slice and to the DNN)?

Expected action Clarify the scope and the assumption of the work group.

Additional context

[ShutingQing]

Thanks for your question. Regarding on the scope, we focous on the Network Slice. If we are selling QoS, then we should discuss under QoD, but if we want to sell a slice as a service, then Slice Booking API make sense. Reference material, https://github.com/camaraproject/WorkingGroups/pull/333. If DNN in NSA is ensuring the QoS, so we may not inlude here.

Regarding on the second question. It depends on how we can make the API more useful for customers. I agree on the idea that "Slice Owner" should be able to influence which devices to get access to the reserved slice. This can make the Slice Ability to be more flexible. So this function is valued to be included.

[tlohmar]

Hi Shuting, on the second question: Does 'So this function is valued to be included.' means, that you consider such a "reserved slice access control for devices" as in-scope for the working group?

[ShutingQing]

Hi tlohmar, do you have any suggestion on this?

[tlohmar]

Hi Shuting,

The term “Isolated and Dedicated Network” is often used in your supporting slides (e.g. Slide 2 of Slides). Lets assume, that the API consumer is booking such an “Isolated and Dedicated Network” for a give time duration, at a given location with a specific performance characteristics. Since this “booked dedicated network” is isolated, no device (with a SIM) has access. The access to the “booked dedicated network” can to be managed per device subscription.

My proposal is, that the work group also provides a procedure for adding devices (better “device subscriptions”) to the “booked dedicated network”. This would give the API consumer some level of freedom to interact with its “dedicated network”, i.e. before the booked duration and also during the booked duration. At the end of the booked duration, all device subscriptions lose their access to the dedicated network (e.g. because the resources are destroyed).

Whether this dedicated-network-access-management procedure (adding / removing subscriptions) is a separate API or API endpoint is “for discussion”.

[tanjadegroot]

Thanks for your question. Regarding on the scope, we focous on the Network Slice. If we are selling QoS, then we should discuss under QoD, but if we want to sell a slice as a service, then Slice Booking API make sense. Reference material, camaraproject/WorkingGroups#333. If DNN in NSA is ensuring the QoS, so we may not inlude here.

Regarding on the second question. It depends on how we can make the API more useful for customers. I agree on the idea that "Slice Owner" should be able to influence which devices to get access to the reserved slice. This can make the Slice Ability to be more flexible. So this function is valued to be included.

Hi all, Shuting,

on the point "If we are selling QoS, then we should discuss under QoD", I fully agree that this API is not about QoS. To our understanding, it is about a "dedicated network" (set of resources with certain characteristics) for use by the API consumer / application. This dedicated network may be created for various purposes such as isolation, security, traffic steering or even grouping traffic with a given QoS, if so desired, however the point is not to sell QoS, but to sell a "dedicate network".

I think a main question is: do we want to 1) limit this API's implementation on only 5G SA networks which then uses the slicing technology to realize the "dedicated network" 2) allow implementation on other underlying network technologies as well ?

IMHO for 1) if we limit this API to 5G SA slicing, then we may need a very similar API to offer this feature on other types of network technology (4G, fixed, cable ...), which sort of defeats the purpose of the network technology abstraction that CAMARA is after.

for 2), this does not exclude any operator to market one or more API Product for this API e.g. "Slice as a Service", "VPN on demand" etc. to their market if they feel this is appropriate. In this case, using an API like e.g. {apiRoot}/dedicated-networks/ is I think easy to understand by the non-Telco developer community.

The ability for the API consumer / dedicated network owner to add their devices (as suggested by Thorsten) to this "dedicated network" makes sense as well. E.g. {apiRoot}/dedicated-networks/{dedicatedNetworkId}/device

other thoughts ?

[ShutingQing]

Thanks Thorsten and Tanja for the detailed elaboration. That's quite valuable. I agree on the idea that we need to provide the freedom to the customers to manage the access from their devices to the slice. This motion needs to be flexible enough, that provide customers a option to book the slice without knowing the end devices at that time, and later they may easily and flexibly add or remove the devices to the slice.

This would give the API consumer some level of freedom to interact with its “dedicated network”, i.e. before the booked duration and also during the booked duration. At the end of the booked duration, all device subscriptions lose their access to the dedicated network (e.g. because the resources are destroyed).

And for the procedure, based on discussions above that one slice booking, one device access management, one slice query, one slice destroy api are requried, to support the functions. And any other thoughts?

Whether this dedicated-network-access-management procedure (adding / removing subscriptions) is a separate API or API endpoint is “for discussion”.

[DanXu-ChinaTelecom]

@tanjadegroot @ShutingQing I agree "dedicated network" with the network technology (5G, fixed, cable ...)， since 4G doesn't has the networking slicing feature, maybe "5G dedicated network" is one clear option.

[ShutingQing]

Again thanks for the proposal and discussion. : ）For the question whether 4G, fixed slice, cable slice should be considered.

Our opinion is, fixed slice, cable slice make sense to be considered. Agree on this. For us, in the first release, due to workload reason, we will focus on 5G firstly and make an initial version. But if someone who would like to volunteer to on fixed and cable, this will be very welcome.

For 4G, we think this should not be included under network slice booking. Refer to 3GPP TS 38.300, the general principle releated to Network Slicing is, slicing needs to be connected to 5GC.

For the API URL, we don't suggest {api-root}/dedicated-networks/xxx . Dedicated network resource is one great feature of slice, but “dedicated network resources” includes more than slice, which can cause some misunderstanding. But agree on the idea about the naming. Later needs to figure out a term which is user firendly and accurate.

[tlohmar]

For the question whether 4G, fixed slice, cable slice should be considered.

there is no "slice" concept at fixed lines or cable. I suggest to avoid the term "slice" in the API and keep it generic, so that the API is independent, how the network capability is realized in the underlying network.

I suggest (like @tanjadegroot and @DanXu-ChinaTelecom) to use Dedicated Network as term and use {api-root}/dedicated-networks/xxx as API endpoints.

[SteveV-Vodafone]

I'd agree with @tlohmar. Keeping some flexibility to address different network capabilities seems more generally useful to wider set of users than narrowly focussing on the term slice.

[Kai-hw]

For the question whether 4G, fixed slice, cable slice should be considered.

there is no "slice" concept at fixed lines or cable. I suggest to avoid the term "slice" in the API and keep it generic, so that the API is independent, how the network capability is realized in the underlying network.

I suggest (like @tanjadegroot and @DanXu-ChinaTelecom) to use Dedicated Network as term and use {api-root}/dedicated-networks/xxx as API endpoints.

Hello CAMARA colleagues,

From procedure point of view, I am not sure that we need to discuss the naming or scope of this network slice booking API again here, I mean, it was discussed a lot and decided in the previous discussions of APIBacklog group and TSC meeting.

From technical point of view, I think the beginning of this discussion thread was triggered by one question as "Not all 5G deployments support the “Network Slice” feature, specifically 5G-NSA deployments (and 4G deployments)" - based on the previous online call it was clarified that this slice booking API is not for 4G which does not support the slicing feature. Imho, the naming and scope of the API is quite clear - it is about slicing. If the underlying network deployments supports the slicing feature, then this Service API will be supported by the network deployments.

Please note in the places where the "Dedicated Network" is used it is just to illustrate the slicing benefit/usage which can offer logical network that provides specific network capabilities and network characteristics. I think no need to use Dedicated Network as term for this API because that term will trigger many unclear things like the relation to VPN camara API/NPN...(actually that was discussed and clarified in the previous APIbacklog discussions).

Please note also in CAMARA we should focus on Service API level (just to facillate the operators to sell the slicing feature well known by the industry), no need for so much detailed discussion on the networks level here again. The slicing term is general enough. : )

[DanXu-ChinaTelecom]

I agree with @Kai-hw , "Dedicated Network" has larger scope, from service level, the scope "Dedicated Network" >("Network slice"="5G dedicated network")

[chinaunicomyangfan]

Agree to @Kai-hw , the clarification is pretty clear. API is about selling 5G Slicing. If the underlying network deployments supports the slicing feature, then this service api will be supported by the network deployments. Agree to @tlohmar , a procedure for adding devices to the booked 5G Slicing is a need. The Network Slice owner should be able to influence, which devices(per subscription) get access to the reserved Network Slice.

[tlohmar]

it was discussed a lot and decided in the previous discussions of APIBacklog group and TSC meeting

CAMARA does not restrict, that the workgroup is doing changes to the API name or the number of APIs. The Network Slice Booking WG would not be the first group, where such a thing happens.

Note on Transformation function definition of the CAMARA Project Charter

Transformation functions Service APIs and Service Management APIs mean an abstraction / aggregation of e.g. 3GPP APIs, Broadband Forum APIs or ETSI MEC APIs to hide telco complexity, keep control at the operator side and fulfill regulatory and data privacy constraints.

and

The definition and documentation of CAMARA APIs (including the mapping tables for the attributes to the southbound APIs if useful) is in scope of the Project and in scope of the harmonization. The transformations functions (business logic that calls the southbound APIs, transforms the data and provides the function for the CAMARA APIs) are in scope of the Project as example or reference implementations, but not in scope of the harmonization. So each telco operator can implement the transformation functions in the best manner considering network topology and vendors, and can use the reference implementation as an orientation and starting point.

CAMARA should only do examples on the a translation function. It is up for the telco operator, whether to use specific 3GPP features, like a Network Slice.

[Kai-hw]

As said <Please note in CAMARA we should focus on Service API level (just to facillate the operators to sell the slicing feature well known by the industry), no need for so much detailed discussion on the networks level here again. The slicing term is general enough. : ) >, here, the slicing term is a Service level term and used well by GSMA/CAMARA/operators to hide telco complextity.

[ShutingQing]

WG does not restrict doing changes to the API name and numbers. As above, @DanXu-ChinaTelecom @chinaunicomyangfan @Kai-hw they have given detailed technical opinions.

My opinion is, the WG does not restrict the network layer implementation. As I mentioned above, if some one volunteer to contribute for the transport network slice, the core network slice, that's very welcome. Not restricted to only access part 5G SA. However 4G does not support slice. So that's not good to be included.

Slice has alredy be as a product which help operators earn money. That was why we put slice as a service, and do it a service api here.

[haoj24]

From China Unicom's perspective, we've already monetized from 5G Slice products which the business feedback is pretty good. For example, as operator, we provide Service/Products named as 5G Slice for Business and First Class, 5G Slice for VIP Users. For the scope, we agree the idea to include transport and core network, since they are related to slie. We agree to @DanXu-ChinaTelecom , 4G does not support slice, then it should not included in the API scope.

[chinaunicomyangfan]

Comprehensively considering the comments and the maintainers' opinions, conclusions are:

1. Proposal 1: Can prioritized DNN be included? Conclusions: WG is focusing on Slice as a NaaS product. DNN does not suppot slice, so it's not considered.

2. Proposal 2: Device Connection Management Conclusions: Accepted. Device access management to the slice is good to be considered. From Customers' Perspective, as the slice owner, should have the option to manage devices access controls.

3. Proposal 3: Allow implementations on other underlying network technologies, not limit to the API on 5G SA, allow 4G, fixed, cable.. 1) Noted: WG does not accept or not accept about the underlying implementation. WG only defines Service API. 2) For the Question of whether the Slice Service API needs to consider 4G, fixed, cable... Conclusions: Accepted on Slice is end to end, from access part, to transport network, to core network. These are suggested to be considered. Not accepted on 4G, since 4G does not support slice.

4. Proposal 4: API URL using {apiRoot}/dedicated-networks/.. Conclusions: Not Accepted. Dedicated Network has larger scope from service level, may cause more misunderstanding.