Considerations for Network Slicing Parameters in the First Version of NSB API

[Jason-ZTE]

Dear Team,

I understand that our principles of Service APIs as follows:

1. The goal of Service APIs is not to specify the implementation technology, but rather to be implementable and easily understood and used by enterprises in terms of business definitions and descriptions for their application.
2. At the same time, these API parameters will be used for billing, and all parameters must be measurable by the network with the capability to produce detailed billing records.

Problem description Consideration 1: Concerns regarding latency as a Service API parameter for slicing The understanding of latency by enterprise customers should be from the terminal to the enterprise access point. In mobile networks, the roaming nature of mobile terminals introduces considerable uncertainty into the aforementioned latency. Additionally, operators find it challenging to provide precise measurement and statistics of latency for all packets during the service period to support billing. It might be considered in future versions, but it is recommended not to include latency in the first version.

Consideration 2: Concerns regarding the minimum bandwidth for slicing as a Service API parameter From the current state of mobile network slicing technology, the number of users and reserved resources of a slice do not absolutely guarantee the minimum bandwidth for users. Often, the signal strength of the user's terminal is a decisive factor, and many times the user's traffic is determined by the APP-side requirements. Including this minimum bandwidth parameter in billing records and billing could pose a risk of not being able to explain it to customers.

Alternative solution Proposal1： In the first version, consider the total number of network slice users and the estimated average data speed (Thpt) per user as input parameters In the current parameters, the definition of geographical scope and service time is necessary. It is suggested to only consider the total number of users and the estimated average data speed (Thpt) per user as parameters. These two parameters can actually define the resources required for slicing. Additionally, it is recommended that billing be based on the service duration of the slice.

Proposal2: It is suggested to add a set of APIs for adding designated terminals to a slice and removing them from a slice. This API is very necessary in practical applications. The return parameters for removing from a slice could include some service information for the user, such as slice service time, average bandwidth, maximum bandwidth, etc.

[ShutingQing]

Thanks Jason. Maybe next biweekly meeting, you can share the proposals with us. Happy to know your suggestions. :)