new API proposal Network Slicing API

[chinaunicomyangfan]

No description provided.

[jordonezlucena]

This PR is associated with #316

[Bart-Ericsson]

Thank you for the proposal.
The use cases look mostly to address scheduled QoS for selected UEs. As such an alternative would be to have the QoD API extended with a scheduling option, the realisation can then be chosen by the operator to deliver through slicing (e.g. in 5G networks) or other mechanisms in other networks. In that case a new API would not be needed, rather an extension of the existing API. Do you see needs that would avoid such approach?

[chinaunicomyangfan]

Thank you for the proposal. The use cases look mostly to address scheduled QoS for selected UEs. As such an alternative would be to have the QoD API extended with a scheduling option, the realisation can then be chosen by the operator to deliver through slicing (e.g. in 5G networks) or other mechanisms in other networks. In that case a new API would not be needed, rather an extension of the existing API. Do you see needs that would avoid such approach?

Thanks Bart. An API is a product, for operators, we believe slice can be sell as a product as well. Slice may provide customers dedicated, isolated network resources. From application scenario, end api consumers, price and billing, Slice are quite different than QoD. Eg, now in China Unicom, we have different products for QoS and Slice. This is our point of view.

[eric-murray]

@chinaunicomyangfan
I agree with @Bart-Ericsson that, if the purpose of this API proposal is to sell QoS to the end user, then there already is an API under development that does exactly this in the Quality on Demand sub-project.

It is important to realise that CAMARA does not define end-to-end solutions, and using network slicing to implement QoS profiles for the QoD API is an entirely valid implementation should a network operator choose to do that. An end user buying QoS will not care whether their improved QoS profile is achieved through network slicing or some other solution. They do not want to have to chose between different APIs for different network operator solutions to their problem.

However, if the end user is specifically buying a network slice to use as they choose with no QoS guarantees, then a new API is required for that. I have been told that such end users exist, who specifically want a network slice rather than a QoS guarantee, however unlikely this might appear. If this use case is valid, then there will be a market for this API.

But the place to discuss use cases is the GSMA Open Gateway Product Workstream, whose working procedures you are already well aware of. If it is agreed that a product that specifically sells network slices is required, then that can be included in a later drop. But as currently proposed, this API is just a special use case for the existing QoD API.

[bigludo7]

@chinaunicomyangfan
Thanks for the proposal.

From Orange perspective, booking, querying & provisioning a slice require orchestration. The slice itself is one component but other service components must also be accordingly fulfilled.
We are more willing to use generic service API agnostic to the service. Indeed if we introduce specific API per service we are afraid of the multiplicity of the API and the associated cost management.

We see a collision with TMF API: we will probably use TMF 645 service qualification (to trigger pre evaluation & booking), then use standard TMF622 Product Order and then TMF641 Service Order for managing the customer request and then the service delivering orchestration. Finally, TMF Service 623 to perform SLA Monitoring.

TMF API allows to describe specific service descriptor, so in our view we can describe Slice service specification template (from GSMA NG116 definition for example) and then embed the instantiation of the service within above listed TMF API. This is for example what has been done in MEF with dedicated service payload dependently defined from generic business entity API like Order.

[jordonezlucena]

I very much agree with @eric-murray point on steering this discussion through Open Gateway Product Workstream, in order to better circumscribed the scope of the API from product viewpoint.
I concur with @bigludo7 that network slicing API may trigger a provisioning workflow involving NEST (or an abstracted/simplified view of it), potentially conveyed through TMF641 (service order) and captured by 3GPP management system (see 28.531 for network slicing provisioning solutions and 28.541 for Slice NRM fragment).
@chinaunicomyangfan: currently there is a Taskforce within OPAG that precisely touches on network slice as a service (selling network slice as a dedicated product to a 3rd party), from technical standpoint. You might flag them about the technical enablers of your API (so OPAG can feed you back) before bringing it to Open Gateway Product WS (recommended though not mandatory path).

[Bart-Ericsson]

Thanks for your comments. I concur with @eric-murray that Camara APIs are external APIs, the realisation can be operator and network specific, that was the main reason for my comment.
@bigludo7 your comments on realisation do make sense to me for the technical realisation in a network where slicing is chosen. This is activity out of scope for Camara in my view, GSMA OPAG is trying to document this so I would like you to direct those comments in that forum as also suggested by @jordonezlucena .

Please note that I find it strange that the use case discussion is redirected to another forum, this denies other parties than the 35 operators in Open Gateway to be part of the discussion, missing out the views from the end users, vendors and system integrators.

[eric-murray]

Please note that I find it strange that the use case discussion is redirected to another forum

It is only proposed to redirect the discussion back to the GSMA OGW Product Workstream because the proponent (i.e. China Unicom) is already part of that process, and has chosen to ignore their working procedures and submit directly to CAMARA. And, as can be seen from the discussion above, the proposal was consequently badly formulated. Once it returns after GSMA OGW Product Workstream review, the proposal will, of course, be further discussed within CAMARA.

Besides, it is entirely possible for non-operators to work directly with operators in formulating proposals to the OGW Product Workstream.

[EthanMinDong]

It is important to realise that CAMARA does not define end-to-end solutions, and using network slicing to implement QoS profiles for the QoD API is an entirely valid implementation should a network operator choose to do that. An end user buying QoS will not care whether their improved QoS profile is achieved through network slicing or some other solution. They do not want to have to chose between different APIs for different network operator solutions to their problem.

However, if the end user is specifically buying a network slice to use as they choose with no QoS guarantees, then a new API is required for that. I have been told that such end users exist, who specifically want a network slice rather than a QoS guarantee, however unlikely this might appear. If this use case is valid, then there will be a market for this API.

@eric-murray
Your perspective is something I find quite admirable.
When it comes to offering QoS services alone, there are various technical methods available to provide end-users with differentiated experiences, ensuring a distinct quality. Users need not be concerned with the specific network technologies utilized, focusing instead on the outcomes they can achieve and the costs involved.
However, a notable drawback of selling QoS services is the difficulty users face in perceiving what they are purchasing. When network is free, they will find nothing different after their purchasing. But Network slicing, in contrast, offers a perceptible product to users. In fact, this need has already been recognized. In China, operators have experimented with two models: QoD acceleration packages targeted at end-users and dedicated network slices for B2B enterprises. The results have shown that while dedicated slices for B2B enterprises have achieved significant commercial success, the QoD acceleration packages intended for end-users have not met the expected outcomes.
Therefore, from a commercial standpoint, reservable network slices are akin to a reservable "private lane", offering customers a reservable, dedicated, secure, guaranteed, and perceptible network product (tariff package), all of which can be commercially monetizable. So, providing a specific Network Slice Exposure API for these use cases is indeed valuable.

[bigludo7]

Therefore, from a commercial standpoint, reservable network slices are akin to a reservable "private lane", offering customers a reservable, dedicated, secure, guaranteed, and perceptible network product (tariff package), all of which can be commercially monetizable. So, providing a specific Network Slice Exposure API for these use cases is indeed valuable.

Hi @EthanMinDong I'm following your thinking but from my perspective we should avoid to have one specific API per product that we sell. If we have one dedicated API for selling Ethernet line and another for SD_WAN and a third for 5G Slice, and so on I'm afraid of the complexity to manage this.

That's why I tend to think that we should try to use a generic ordering API and then have specific product schema for the ordered product. This is a pattern described in TMF and leveraging with good success in MEF .

To provide you a concrete example with some link:
Here in MEF you have the generic API https://github.com/MEF-GIT/MEF-LSO-Sonata-SDK/tree/working-draft/productApi so you'll find here the order function and here the product payload https://github.com/MEF-GIT/MEF-LSO-Sonata-SDK/tree/working-draft/productSchema and here we can imagine to have a 5G Slice description.

Hope it makes sense.

[jordonezlucena]

@bigludo7: I'm not quite fan of MEF to convey slice orderings. As I noted in one of my previous comments, I expect a network slicing API conveyed through TFM641, with payload based on NG.116 NEST, and this API call captured by 3GPP management system (3GPP SA5 is the reference here). I don't see the need to involve MEF in the overall picture.
@eric-murray: The QoS framework and network slicing are two independent features of the 5G mobile network architecture (3GPP TS 23.501). Please, have a look at this article for further details. I think keeping QoD API and Network Slicing API separate makes sense, as long as we acknowledge they targeted completely different use cases.

• QoD API allows the 3rd party (could be B2C or B2B) to upgrade the performance of a (collection of) ongoing QoS flows. The actual network solution that operator uses to fulfil this upgrade (SD-WAN, network slicing, DNN/APN provisioning...) should remain transparent to the 3rd party. The 3rd party is only interest in getting this request fulfilled, no matter what is the network solution used for that end. If the operator decides to use network slicing, this is somewhat related to the model that 3GPP acknowledges as "Network Slice as NOP internals"
• Network slicing API allows the 3rd party (likely B2B) to ask for the allocation of dedicated resource capacity. This is somewhat related to the model that 3GPP acknowledges as "Network Slice as a Service". This model offers the flexibility for operator offer to a particular customer a dedicated network slice as a product. This product will carry all PDU connectivity services as the customer requires, potentially towards different DNNs (e.g., local breakout in the tenants computing centre, public voice to IMS, and towards public internet), while each PDU connectivity service might carry multiple QoS flows of different QoS.

[bigludo7]

@jordonezlucena Not to enter a debate about TMF/MEF API.... of course we are also using TMF64 ServiceOrder but for us this API is only used internally between our Customer Order Management and Service Order Management components. In TMF641 make completely sense to use NG116 for slice description. Aligned with you.

The MEF ordering API is a TMF 622 specialization and this one is offered northbound of Customer Order Management and open to external. Here the offering is a restriction/abstraction of the slice with only the attribute relavant for the customer.

Hope it makes sense.

BTW I took the MEF as an example to illustrate decoupling between the business transaction (ordering) and the service.... not as a proposition to involve MEF.

[chinaunicomyangfan]

Thanks for Ludovic and Jose’s discussion, that’s very informative.

I expect a network slicing API conveyed through TFM641, with payload based on NG.116 NEST, and this API call captured by 3GPP management system (3GPP SA5 is the reference here).

we concur with the idea, “I expect a network slicing API conveyed through TMF641, with payload based on NG.116 NEST, and this API captured by 3GPP management system(3GPP SA5 is reference here). I don’t see the need to involve MEF in the overall picture.

For Network Slicing API, we are defining it as a service API, facing to B2B customers, who require dedicated network resources. For network resource layer, network slicing API can be conveyed and aligned with 3GPP or TMF. Since currently CAMARA scope only focus on service API, this part we can discuss, but we suggest not a focus.

[eric-murray]

I still have a problem with the statement in the proposal that the purpose of the API is "to provide rate and time assurance for such scenarios", because this is what the QoD API is intended to do, and I don't understand how such "assurances" will be managed by the network slicing API.

I'm fine with the idea that the API provides a way of selling a network slice (reserved network resources) as a product, but am wary that the network operator is expected to monitor the QoS actually being achieved over the network slice, and then "doing something about it" if the required QoS is not being achieved.

The proposal states that the API OAS definition is "In Progress". When will this be available, even as a draft? That would give a better insight into how the API is intended to operate and its differences to the QoD API.

[Kai-hw]

Thanks @eric-murray for your valuable comments. I agree with your observation.

For the statement in the proposal that the purpose of the API is "to provide rate and time assurance for such scenarios": yes, that wording is misleading and I suggest changing to "The on-demand network slicing service technology can be used to provide a network slice reservation method for such scenarios to meet the SLA assurance expected by developers for a specific time period and a dedicated service area" to reflect the purpose of the API correctly. Hope now it is clear. We will change the API summary accordingly.

Yes, it is absolutely needed for operator to monitor and evaluate the SLA (QoS) assurance for the reserved network slice when the slice is in-service and do the optimization/re-configuration for the slice network resources if needed to ensure the reserved SLA of that slice is guaranteed. This needs the network layer actions and I think some SDOs are taking care of this, like 3GPP.

For the API OAS definition is "In Progress": maybe a YAML is needed later. For now, to show the intention of this API and its differences to the QoD API, please see the input and output of this API as following:

Input Parameters:

• Expected Service Time Period：Start Time ~ End Time
• Expected Service Area：Geographical area (Point, Line, Area)
• Guaranteed terminals：Number of terminals
• SLA Targets：SLA KPIs (such as DL/UL average Throughput, Latency)

Output Parameters:

• Slice Reservation Result：Network slice reservation success or failure

A typical use scenario:
A developer may use this user-friendly API to book a network slice with expected service time period, expected service area, expected guaranteed numbers of terminals and expected SLA targets in advance (e.g. 2 hours or 2 weeks in advance) for some scheduled event like a live video streaming show scheduled during some time period and in some area place. Based on the reservation result, the API user will get the slice reservation result of success or failure.

Thank you.

[Bart-Ericsson]

Thank you for the comments before, a couple of thoughts on this proposal for your consideration

• The API should NOT mention slicing, this is because the realisation might be other than a slice, especially when not on 5G. Why not "connectivity management" or "resource management". The commitment level when reserving connectivity or resources should be high, but CSP determined.
• The API should contain a time range (e.g. start time / stop time) and a location range (Geo Area) and a desired connectivity performance (e.g. throughput, approximate number of devices, etc)
• The API should not dictate how the reserved capacity is used unless this is needed and influences the network preparation, Maybe the APIs should indicate a “max possible” capacity.
• The API should not include target MSISDNs, in my view this is a separate API (in the same workgroup) to connect/disconnect devices to the reserved resources.

Thank you for your considerations.

[Kai-hw]

Hello @Bart-Ericsson , thanks for sharing your thoughts.

Regarding your 1st bullet, I am not against investigating a more general idea not focusing on 5G via other activities in CAMARA further. But here, the purpose of this proposal is really targeting on the slicing which is a key feature of 5G and accepted by the verticals to buy as a service (3GPP acknowledges this as "Network Slice as a Service"). As you see from the previous discussion (#333 (comment) from operator China Unicom reply as "An API is a product, for operators, we believe slice can be sell as a product as well. Slice may provide customers dedicated, isolated network resources. From application scenario, end API consumers, price and billing". If CAMARA can provide such API towards 3rd party (like B2B), then it will offer the flexibility for operators to offer to a particular customer a dedicated network slice as a product. As I explained to @FabrizioMoggio here (#317 (comment)), <seems two threads (one is #317, the other one is this thread here) sometimes are used? >:

• A developer may use this user-friendly API to book a network slice with expected service time period, expected service area, expected guaranteed numbers of terminals and expected SLA targets in advance (e.g. 2 hours or 2 weeks in advance) for some planned event like a live video streaming show scheduled in some place during some time period.
• The Network slicing API allows Operators/CSPs to offer dedicated resources to different tenants (as B2B customers) via the Network slice as a Service. This is a kind of commodity and business monetization opportunities for operators to sell on-demand slice service to third-party tenants.

Regarding the 2nd bullet, yes, I agree with that very much. This aligns with the input of this API.

Regarding the 3rd bullet, yes, I agree that the API should not dictate how the reserved capacity is used unless this is needed and influences the network preparation. This API is a user-friendly API which should only express the service requirements from the customers point of view (just as "What"). If it is confirmed successfully by the operators as a slice reservation result, I think then the asked service requirements need to be ensured, otherwise how the operator can get the payment from the customers? :) I think this is quite similarly like the case of hotel room booking: the hotel service providers need to ensure the rooms are available for customers to be checked-in later after the room reservations done successfully by the customers. :)

Regarding the 4th bullet, yes, I think no intention for this API to include the "target MSISDNs" uniquely identifying the mobile users. In the Input parameters of this API, it is just "Guaranteed terminals: Number of terminals" which means the "approximate number of devices" mentioned in your 2nd bullet.

Thank you.

[ShutingQing]

LGTM

[jordonezlucena]

Let's keep this PR open - don't merge until backlog WG decides the API proposal is ready for approval.

[jordonezlucena]

@Kai-hw: in the application template, there is some room for improvement on technical availability:

• "RAN management domain" is wide open. It can mean different things for different operators. What I think it's important here is to specify that we need 'radio resource partitioning' feature, as 'priority scheduling' might not suffice. If this assumption is correct (please correct me otherwise), then this should be explicitly captured, since this is a technical enabler without which an operator will not be able to offer this API.
• UDM and PCF are not specified in 28.531/28.541, but in 23.501 instead.
• Regarding 28.531, it’d be advisable to specify which operations need to be available, and the baseline release.
• Regarding 28.541, it’d be advisable which parts of the network slice NRM fragment need to be available, and the baseline release.

[eric-murray]

Slice Reservation Result：Network slice reservation success or failure

This implies that the output is just a boolean - true or false. That seems unlikely. But assuming it is just a boolean, and the API returns true, how is the slice then accessed by the intended device? How does the network even know which UEs are allowed to use the network slice?

I am still missing a lot of information on the intended use case, and suspect the whole end to end journey of connecting a specific device to its target server via a network slice involves far more than just calling this API.

[Kai-hw]

Slice Reservation Result：Network slice reservation success or failure

This implies that the output is just a boolean - true or false. That seems unlikely. But assuming it is just a boolean, and the API returns true, how is the slice then accessed by the intended device? How does the network even know which UEs are allowed to use the network slice?

I am still missing a lot of information on the intended use case, and suspect the whole end to end journey of connecting a specific device to its target server via a network slice involves far more than just calling this API.

Hi, Eric.

Thanks for your comments.
For the successful case of Slice Reservation Result, the booked slice ID needs to be provided to the consumers, not only a boolean. Then the reserved slice can be accessed via this ID (as S-NSSAI) by the devices for the reserved time period.
We can discuss further in today's backlog call for any further clarifications.

[chinaunicomyangfan]

We add some slides(see page 11~14) to summarize the previous discussion on the list.

[ShutingQing]

Input output params are depicted in details in the latest version slides. And Q&A summaries in brief. lgtm, other reviewers pls review.

[jordonezlucena]

The WG has decided (on 11th Jan call) to bring this API proposal for TSC approval (on 18th Jan call), so the PR can be merged.