# On the Rollout of Network Slicing in Carrier Networks: A Technology Radar
## 8 Oss Domain
### Capability Exposure
In this time frame, it is also expected that customers gain experience with slicing technology, and hence want to retain more control of their slice. This requires the operators to increasingly expose further capabilities, with the definition of new API families. Below, there is a list of API families that some tier-1 operators have started to test and validate with some industry verticals and hyperscalers. * **Edge computing**: these service APIs are available for those customers that want to extend their allocated slices with third party applications, with these applications hosted by the telco edge cloud. In a nutshell, this API family provides three main capabilities: (i) edge node discovery capability, which allows the customer to discover the set of edge nodes available in a certain region; (ii) edge node profile capability, whereby the customer can get information on capabilities and supported features of a given edge node, so as to check whether this node is valid for hosting the application;  
Figure 18: Capability exposure in network slicing environments. (iii) application resource allocation capability, that allows the customer to request the operator to deploy the application on a given edge node. * **Device configuration**: provides the customer with the ability to register a device into the network slice, and to update device subscription. Based on the subscription information received by the customer, the operator updates the Unified Data Management (UDM) accordingly. This API family is quite useful for (industrial) IoT scenarios, where B2B customers want to retain control of the configuration of their devices. For further information on UDM functionality, see Figure 4 and [10]. * **Network slice management data**: with this API family, the customers can subscribe to receive management data related to their allocated slices, at per S-NSSAI level. The individual customers might also choose how they want to consume these data, according to their preferences. For example, regarding performance management data, a customer could specify the KPIs to be informed, the batch format and the reporting period. * **QoS control**: provides the customer with the ability to set and modify quality for a slice (e.g., maximum latency, guaranteed throughput, maximum admissible packet rate), on demand. The operator captures the customer-triggered request and routes it through the NEF down to the PCF, which will ultimately set/modify the 5 QI associated with the in-slice PDU session(s). * **Traffic influence**: provides the customer with the ability to modify the connection policies of UEs attached to the slice, in terms of how the traffic flows. For example, if the customer has deployed a 3 rd party application in a specific edge node, with this API family the customer can then request the re-routing of the in-slice packet flows to this edge node. Finally, in the longer run, the integration of Rel-17+ features into the network and OSS layers will allow operators to unleash the full potential of NSaaS. Examples of API families that operators foresee to make available in five-to-seven years time are captured below. * **Slice day-2 configuration**: allows the customer to retain full control of slice day-to-day operation, which is the ultimate realization of tenant-managed slices. With this API family, the customer could request topology changes and resizing (e.g., scaling in/out) on the slice, based on the processing of alarms and KPIs received. * **Customer-defined slice composition**: allows the customer to request a slice _a la carte_. To enable this feature, the operator shall define a marketplace with different functions and applications. The customer should be able to browse this marketplace, design an E2E slice by connecting selected functions/applications (following a 'plug-and-play' approach), and order its provisioning. This is a giant step forward, and requires thinking of novel ways of designing slices and capturing their service requirements, beyond today's NEST approach.