Problem Statement of Supervised Heterogeneous Network Slicing

The concept of network slicing is not new but energized greatly under 5G work in 3GPP. It is expected that further 5G network should be capable of providing dedicated private network for different verticals according to their specific requirements, which are created by diversity of new services such as high definition (HD) video, virtual reality (VR) and V2X applications. Looking at the development of future network, no matter the service is connected via 5G cellular RAN, FTTx optical access network or other dedicated connections, this resource dedication has become a fundamental technology for services requiring extreme quality of user experience. The best effort transport is not good enough as both subscribers and application providers are looking for and willing to pay for certain level of quality dedication. Therefore it is inevitable for service providers (telecommunication infrastructure owners) to rethink the means of management and operation of their networks, which should support end-to-end slicing capabilities. The requirements from different verticals may be extremely diversified. Typical examples includes high bandwidth, low latency, high level of isolation, specific security and encryption requirements and etc. These requirements may also change dynamically along time since the services of certain industry vertical changes very fast, and sometime spontaneously (i.e. burst bandwidth/latency requirement from on-line shopping provider on certain period). It is expected that the configuration of certain network slice instances are very dynamic in a case-by-case manner. Meanwhile, there are many technology options to fulfil particular requirements depending on considerations on many aspects including cost, TTM and etc. The diversity of both requirements and technology options makes network slices significantly heterogeneous. In order to provide cost-effective and efficient network slice configuration, service provider needs to understand specifically the components it can make use to create a network slice instance and how these components map with the customer requirements. These components include both network resources and management entities.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Network Slice Instance - A network slice instance (NSI) is a managed group of subsets of network resources, network functions and network management entities, forming a complete instantiated logical/physical network to meet certain network characteristics required by the network slice tenant(s). A network slice instance may also be shared across multiple services provided by the network slice tenant. It is re-configurable and is managed by network slice provider. Network Slice Provider - A network slicing provider (NSP), typically a telecommunication service provider, is the owner or tenant of the network infrastructures from which network slices are created. The network slicing provider takes the responsibilities of managing and orchestrating corresponding resource and management components that the network slicing consists of. Network Slice End-point - A network slice end-point (NSE) is a network-slice-aware terminal, typically subscribed to the service which is hosted in a network slice instance. A network slice end-point may be capable of subscribing to multiple services hosted independently in different network slice instance simultaneously. Network Slice Tenant - A network slice tenant (NST) is the user of specific NSIs, in which specific services are hosted and can be provided to NSEs. Network slice tenants can make requests of the creation of new network slice instances. Certain level of management capability should be exposed to network slice tenant from network slice service provider by pre-allocated outsource management entities. End-to-end Network Slice - A cross-domain network slice which may consist of access network (fixed or cellular), transport network, (mobile) core network and etc. End-to-end network slice can be customized according to the requirements of network slice tenants Network Function (NF) - A processing function in a network. It includes but is not limited to network nodes functionality, e.g. session management, mobility management, switching, routing functions, which has defined functional behaviour and interfaces. Network functions can be implemented as a network node on a dedicated hardware or as a virtualized software functions. Data, Control, Management, Orchestration planes functions are Network Functions. Virtual Network Function (VNF) - A network function whose functional software is decoupled from hardware. One or more virtual machines running different software and processes on top of industry-standard high-volume servers, switches and storage, or cloud computing infrastructure, and capable of implementing network functions traditionally implemented via custom hardware appliances and middle-boxes (e.g. router, NAT, firewall, load balancer, etc.)

Fundamentally, NSIs are created based on the shared network infrastructures. One can not create or define an NSI with components that are not available in the shared infrastructure. Hence, it is extremely important, both for NST and NSP, to understand a clear scope of the usable components for NSI construction. An NSP can therefore refer to this general scope to decide how each component can be orchestrated and provided as a packaged network slice service to NSTs. Based on this information, NSP can also further outline and figure out the what capability each component can offer and how they meet NST's demands. Overall, it is not possible to map the offered capability of a network slice instance with the specific demands from an NST if an NSP is not clear on what components and corresponding characteristics can be provided. Network slice instance consists of dedicated network resources which are orchestrated using all the available components offered by a NSP network. In general, the components that an NSP can use to create an NSI include connectivity, computing, storage, and management entity.

Connectivity is one of the essential components for an NSI. It can be as simple as a best effort point-to-point VPN or a dedicated complex topology with other specific requirements including bandwidth, latency and etc. The characteristics of the connectivity component should include the following aspects. Connection topology - The description of connection topology of a NSI. It should explicitly describe the connectivity relationship between each access point of the NSI. An NSP should be able to understand the overall connectivity requirement of an NSI from this topology information. Bandwidth - The description of bandwidth requirements of specific links within an NSI. The requirements includes exactly amounts of assured bandwidth, maximum bandwidth and other bandwidth QoS-specific requirements Latency - The description of link latency requirements within an NSI. It should identify the exact amount of latency between a link defined in connection topology. Determinism - The description of the determinism of a link latency. This should be defined in addition to the latency, which further specify the jitter of the latency for a given link. Isolation level - The description of isolation level of an NSI. A NST may request logical isolation which can be mapped to tunnelling technologies. It may also request explicitly a dedicated lamda or even physical link for specific services.

If an NST would like to host virtualized functions in an NSI, it may be interested in asking for specific computing resource including both bare metal common servers and virtual machines. This resource should also be specified considering the following characteristics. CPU resources - The physical and virtual CPU specifications a NST may request a NSP to provide. GPU resources - The GPU specifications a NST may request a NSP to provide. RAM resources - The RAM size associated with the requested computing resources in a NSI. Instead of providing bare metal resources, NSP may also provide ready-to-used virtual machines and containers as part of the NSI. This virtual resources need also be specified with virtulization technology options, CPU/Virtual CPU requirements and etc.

It is necessary for NSP to provide storage components in an NSI since NSTs may want to host contents on dedicated resources. Meanwhile, NSP may also prefer to use dedicated storage for specific service policies,authentication information and other management profiles. General storage - The description of storage resource in a NSI. This may include the location, type, size and usage of the storage resource. The general storage requirements may closely related to the connectivity topology as well. CDN service - If an NSP can provide a turn-key CDN solution for the NST. It can also include CDN service withing an NSI

Many dedicated network functions, either physical or virtual, may requested by a NST. Typical example include common network functions as DHCP server, DNS, NAT, Firewall, SDN controller. Application-level functions may also exist in a NSI, such as session management, mobility management and etc. NSP should be able to provide such pre-defined function blocks according to NST's request. Physical network function blocks- The description of dedicated physical network functions. Physical network functions are network equipments with dedicated software and hardware, which are strictly coupled for the purpose of a providing specific network function. Virtual network function blocks- The description of virtualized network functions. VNFs are software entities which are normally hosted within pre-allocated virtual machines (or containers). The virtual resources which are required by the VNF should be also specified in terms of computing resources as described previously.

As NSTs are not expected to be "network experts", the requirements injected to a NSP may be diversified in forms. NSP may have different preferences for the network slice service model provided to potential NSTs. However, there is a need for a common information model which explicitly describes the components and parameters within a NSI.

As seen in Figure 1. The common information model is used to describe a NSI according to the service model provided by NSTs. It is then further de-composited to models that are used by various management domain within the NSP's network infrastructure.

The network slice management include two levels. One is network-slice level management which is maintained by NSP, the other is intra-slice management which is maintained by NST but supervised by NSP. Network slice management agent - This is the NS-level management agent provided by NSP. Each created NSI should have a logical entity serving as a network slice management agent. It executes the OAM messages received from the NSP network slice manager including life-cycle management, monitoring and etc. A profile of the created NSI should also be maintained within this agent, where the status of each element can be managed. Intra-slice management - As per agreement between NST and NSP, intra-slice management may be provide by NSP to oversee an given NSI as a general private network. NST are authorized to use this management capability to maintain the NSI. The NSI-level information is transparent to intra-slice management, which means the management system does not know the existence of network slice instances. The exposed management capability should be supervised by the NSP, so that the NSI will not violate NSI-level policies. Meanwhile, intra-slice management

This document makes no request of IANA.

Each layer of the system has its own security requirements.

5G Service-Guaranteed Network Slicing White Paper China Mobile Communication Corporation, Huawei Technologies Co. Deutsche Telekom AG,Volkswagen