Slicing is not a new concept. In a 5G network, multiple applications may need to run concurrently on the same infrastructure with different QoS (Quality of Service) requirements. Network slicing can virtualize a single physical infrastructure into multiple logical networks with their own custom topology and dedicated resources that can be flexibly configured with resources or virtualized functions to meet the QoS requirements of an application based on its needs.

5G/6G Network Slicing

With network slicing, each type of application can be served on a different slice. For example, one slice can be dedicated to providing reliable and low-latency communication for real-time interactive applications, while another slice can be configured to provide high-throughput communication for massive IoT applications.

Because slices collectively serve the same type of applications with similar QoS requirements, the configuration or operation of slices can be customized based on QoS requirements. This flexible configuration can be achieved through software-defined networking (SDN), a mechanism that separates the control plane from the data plane in a network to flexibly manage the data plane. With SDN technology, slices can be constructed as virtual networks on the data plane, with SDN controllers connected to switches on the data plane, to manage the slice's traffic in a centralized view.

Depending on the user's needs, slices can be dedicated to some specific users. These users are called tenants, and multiple slices serving the same type of application can be owned by different tenants. Slices may have different priorities based on priorities between tenants or QoS constraints on SLAs (Service Layer Agreements) between tenants and infrastructure providers. For example, slices from tenants who pay more, or slices with strict QoS constraints on SLAs, can be given higher priority.

Architecture Framework of Network Slicing

The following figure shows the system architecture design of network slicing. The system is divided into two layers: the network layer and the OSS layer.

The network layer provides the required user and control plane functions for individual slices; the OSS layer hosts all the assets used for the design, configuration, and operation of network slices.

The network layer consists of a modular set of network functions that can be flexibly combined together to build network slices. The image above shows an example with three different slices, each representing a major 5G service category. Since each slice requires a user and control plane equipped with customized services, dedicated NR and 5GC network functions need to be allocated in their RAN and CN slice subnets. Which network functions are dedicated to each slice, and which functions can be shared with other slices, depends on the isolation needs of the slice, and the type of customers using this slice.

The OSS layer hosts all the operations, administration, and maintenance (OAM) tools that operators can use to manage different slices throughout their lifecycle. Depending on the functional scope, these tools can be grouped into four broad categories: design, data management, assurance, and orchestration. Most notably orchestration, which is responsible for all activities related to slice configuration (i.e. from service orders to deployed network slices) and slice operations (i.e. keeping deployed slices in the desired state at runtime).

How to achieve end-to-end isolation of network slicing?

Slice isolation is an important requirement, that is, multiple slices sharing the same infrastructure coexist at the same time, and it is necessary to ensure that the performance of each slice cannot have any impact on the performance of other slices. According to the degree of isolation, network slicing can provide three levels of isolation: service isolation, resource isolation, and operation and maintenance isolation.

Service isolation: The service packets of a network slice will not be sent to service nodes in another network slice in the same network, that is, the isolation of service connections and access between different network slices is provided, so that the services of different network slices can be separated from each other. invisible to each other in the network.

Resource isolation: The network resources used by a network slice are isolated from those used by other network slices.

Operation and maintenance isolation: For some network slice users, on the basis of providing service isolation and resource isolation, it is also required to be able to independently manage and maintain network slices allocated by operators, that is, to approximate the use of network slices. To use a dedicated network, network slicing provides O&M isolation through the management plane interface opening.

Slice isolation of access network

The access network consists of wireless air interface and basic processing resources. The isolation of wireless spectrum resources can be divided into physical isolation and logical isolation. Physical isolation is to allocate dedicated spectrum bandwidth to network slices, and logical isolation is to allocate resource blocks on demand according to the requirements of different slices, and multiple slices share the total spectrum resources.

The base station processing part of the 5G access network consists of DUs and CUs. Therefore, the isolation of network slices in the base station processing part is achieved by the isolation of slices on DUs and CUs. DU currently relies on dedicated hardware implementation, and CU can be implemented using dedicated hardware or run on a general-purpose server in software by using virtualization technology. Physical isolation of network slices on DUs is achieved by assigning different DU boards or processing cores to different slices. When the CU software runs on dedicated hardware, the isolation is similar to the DU. When the CU software runs on a general-purpose server, the isolation of network slices in the CU can be implemented based on the Network Function Virtualization (NFV) isolation technology. Different virtual machines or containers are allocated to different slices, and slices can be implemented through the isolation of virtual machines or containers. Isolation on CU. According to the security isolation requirements of slices, the isolation mechanisms on the DU and CU can be used alone or in combination.

Slice isolation of bearer network

The isolation of network slicing in the bearer network can also be achieved through soft isolation or hard isolation. The soft isolation scheme is based on the existing network mechanism, and is realized by the mapping of virtual local area network (VLAN) tags and network slice identifiers. Network slicing has a unique slice identifier. According to the slice identifier, different slice data are mapped and encapsulated with different VLAN tags, and the network slice is isolated on the bearer network through VLAN isolation. Although this isolation method differentiates the data of different slices by VLAN, all slice data marked with VLAN tags are still scheduled and forwarded in a mixed manner, and isolation at the hardware and time slot levels cannot be achieved.

The hard isolation scheme is based on Flexible Ethernet (FlexE) technology. FlexE implements the decoupling of the MAC layer and PHY layer interface transceivers by introducing a Time Division Multiplexing (TDM) Flex Shim in the Physical Coding Sublayer (PCS) of Ethernet, thereby improving the flexibility of Ethernet networking. sex. FlexE customers use a flexible way to occupy time slots at the FlexE Shim layer, and specify which service the time slot is occupied by the FlexE overhead. FlexE supports multiple customer services through the time slot configuration at the Shim layer to achieve physical isolation between network slices carrying different customer services. FlexE slicing based on time slot scheduling divides physical Ethernet ports into multiple Ethernet elastic pipes, so that the bearer network not only has the characteristics of Ethernet statistical multiplexing and high network efficiency, but also has exclusive time slots and isolation similar to TDM. good feature.

Network slicing can also use a combination of soft isolation and hard isolation for the isolation of the bearer network. In the case of using VLAN to implement logical isolation for network slicing, FlexE slicing technology can be further used to achieve physical isolation at the time slot level.

Core network slice isolation

The 5G core network is built on a virtualized infrastructure, and its deployment architecture is divided into a resource layer, a network function layer, and a management and orchestration layer. The security isolation of network slicing can be achieved through the three-level isolation of the corresponding basic resource layer, the network layer, and the management layer, as shown in the following figure.

According to the security requirements of the application, two isolation schemes, physical isolation and logical isolation, can be provided. Physical isolation is to allocate independent physical resources for network slices. Each network slice has exclusive physical resources and does not affect each other, similar to traditional physical private networks.

Logical isolation is to establish an isolation mechanism for multiple network slices built on a shared resource pool. For isolation at the resource layer, refer to the NFV isolation mechanism. The NF isolation of the network layer is divided into isolation between slices and isolation within slices. The isolation of NF between slices is based on the isolation mechanism of virtual machines or containers. Multiple NFs in a slice have different security requirements due to different functions. Therefore, multiple NFs in a slice also have isolation requirements. Multiple NFs can be placed in different security domains by dividing the security domains, and they can be placed in different security domains. Configure security policies between them to achieve NF isolation. Isolation of slices at the management layer By assigning different accounts and permissions to tenants using slices, each tenant can only manage and maintain its own slices, and has no right to manage slices of other tenants. In addition, it is necessary to ensure the security of the management interface through mechanisms such as channel encryption.

challenge

The end-to-end (E2E) nature of slicing forces operators to maintain consistent behavior of a single slice across different domains, which can pose significant operational challenges to commercial networks, as described below:

Slicing preparations vary. The penetration of slice features in different technical fields is not the same. While network slicing support has been included in the core network since the first 5G release (3GPP R15), the transport network does not yet support any native slicing capabilities, and the first solution was only integrated into the radio access network last year. There are many Standards Development Organizations (SDOs), each of which addresses a portion of the E2E problem, leading to fragmentation of the standardization effort. For example, different SDO settings have different priorities.

Scalability burden. The greater the number of slices running in parallel, the greater the burden on the operator's OSS (Operation Support System) in terms of scalability. For micro network slices with a large number of instantiations, each slice requires separate control and management, which has a large impact on OSS functionality (orchestration, assurance, etc.).

Multi-vendor solution. The single-vendor model previously limited the open cooperation of the ecosystem, so 5G commercial networks are built with solutions from multiple technology providers. But in this multi-vendor ecosystem, the challenge for operators is how to properly combine components from different suppliers and ensure they work together within and across domains.

Source of the content of this article:

1.5G Network Slicing Security Isolation Mechanism and Application [Mao Yuxin, Chen Lin, You Shilin, Yan Xincheng, Wu Qiang]

2. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8659767/

3. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6630757/