Network Slicing
1. Overview
A. Definition
Network Slicing is a technology that creates multiple logically isolated end-to-end virtual networks (slices) on top of a single physical network infrastructure (radio access network, transport network, core network), independently guaranteeing different performance, functional, and security requirements for each slice.
The essence of network slicing is "using one physical network as if it were multiple purpose-specific dedicated networks." In a traditional carrier network, all subscribers and services share the same resource pool, making it hard to individually guarantee the latency, bandwidth, and reliability a specific service demands. Building on SDN (Software Defined Networking) and NFV (Network Function Virtualization), slicing partitions and reconfigures compute, storage, and network resources in software, instantly creating and delivering a tailored logical network for each service.
What matters here is that a slice is not a mere QoS (Quality of Service) priority adjustment but a separation of the entire end-to-end logical network, including the Control Plane and the User Plane. That is, everything from the radio scheduler's resource blocks to the transport network's paths and the core network's session-management and mobility-management functions is divided per slice. For this reason, slicing is regarded as the key characteristic that distinguishes the 5G architecture from earlier generations.
By analogy, slicing is like logically drawing an emergency-vehicle-only lane (URLLC), a bulk-freight lane (eMBB), and a many-small-vehicle lane (mMTC) onto a single highway (physical infrastructure). There is one road, but each lane has different traffic rules, speeds, and right-of-way, so an ambulance is not trapped in freight congestion. However, slicing goes beyond merely dividing lanes; it also attaches dedicated on-ramps, tollgates, and traffic control (control-plane functions) to each lane, giving it a stronger character of end-to-end separation.
B. Background and Necessity
5G must simultaneously accommodate three service classes with extremely different characteristics on a single infrastructure: eMBB (enhanced Mobile Broadband) demanding ultra-high-capacity streaming, URLLC (Ultra-Reliable Low-Latency Communication) demanding 1ms-class latency and 99.999% reliability, and mMTC (massive Machine-Type Communication) demanding low-power connectivity for tens of thousands to hundreds of thousands of devices. These three demands are in a trade-off relationship that cannot be optimized simultaneously, so a single "average" network cannot properly satisfy any one of them.
In the past, the response was to build a separate physical network per service (dedicated lines, dedicated equipment), but this excessively inflated capital expenditure (CAPEX) and operating expenditure (OPEX) and lowered resource utilization. Conversely, funneling all traffic onto one shared network causes interference, such as surging video traffic pushing out remote-control signals. Slicing resolves this dilemma with the compromise of "physically one, logically many": resources are shared, but each service's SLA (Service Level Agreement) is isolated and guaranteed.
Through 4G (LTE), such per-service differentiation stayed at QoS-class (QCI)-level priority adjustment. However, QoS alone cannot divide the control plane and core functions, making it hard to fundamentally isolate latency-extremely-sensitive mission-critical services from general traffic. As 5G targeted industry-convergence services such as autonomous driving and smart factories, end-to-end slicing—able to tailor performance, functionality, and security wholesale per service—emerged as an essential requirement.
Furthermore, from the mobile network operator (MNO) perspective, slicing becomes the basis for new revenue models. Slices tailored to industry-specific demands—autonomous driving, smart factories, telemedicine, large-scale event broadcasting—can be sold on demand (Network-as-a-Service), and it is even possible to delegate part of a slice's operational control to enterprise customers. Against this backdrop, 3GPP designated slicing as a core standard feature from Release 15.
Technically, slicing became possible thanks to the maturation of SDN and NFV. In the past, network functions were fixed to dedicated hardware (routers, gateways), requiring new physical equipment per service; NFV separated these functions into software (VNF/CNF) on general-purpose servers, while SDN split the control plane from the data plane to make paths programmable. As a result, resources could be divided and reconfigured with software commands alone, establishing the premise of slicing—"many logical networks on one physical network." This is why slicing is viewed as an "application" of SDN/NFV and a flagship use case of the 5G era.
C. Characteristics
- Isolation: A failure, overload, or security incident in one slice does not propagate to other slices.
- Customization: Each slice's topology, functions, and SLA are designed differently.
- Elasticity: Slice resources are dynamically scaled up and down as traffic changes.
- Automation: The entire process of designing, deploying, operating, and decommissioning a slice is automated through orchestration.
These four characteristics operate in interlock. If isolation is the foundation of SLA trust, customization provides the freedom to design that SLA per service, elasticity provides the ability to maintain the SLA amid demand fluctuations, and automation provides the execution power to make all of this repeatable at scale without human hands. In particular, without automation, individually managing hundreds of slices is unrealistic, so the commercial value of slicing can be seen as effectively proportional to orchestration maturity.
2. Overall Structure of Network Slicing
An end-to-end slice is completed only when the three domains—radio access network (RAN), transport network (Transport), and core network (Core)—are each carved out and linked into one. If even one segment is not sliced, that point becomes a bottleneck and the SLA collapses, so consistent partitioning across the three domains is a prerequisite. This is the same principle as a chain being governed by its weakest link: if the end-to-end latency target is 1ms, the latency budgets of the three segments must be summed, allocated to each segment, and verified. The structure diagram below shows how the three domains are connected into one slice.
flowchart LR
subgraph RAN["RAN slicing"]
R1["Radio resource blocks<br/>scheduler partitioning"]
end
subgraph TN["Transport slicing"]
T1["FlexE·VPN·<br/>segment routing"]
end
subgraph CN["Core slicing"]
C1["Virtualized NF<br/>SMF·UPF·AMF"]
end
UE["Device (UE)"] --> R1 --> T1 --> C1 --> DN["Data network (DN)"]
RAN slicing allocates a base station's radio resources (frequency/time resource blocks, scheduling priority) per slice. A URLLC slice is given a short transmission time interval (TTI) and preemptive scheduling to lower latency, while an eMBB slice is assigned wide bandwidth. Because the radio segment is fundamentally scarce in resources and subject to propagation conditions, the sophistication of RAN slicing often governs end-to-end performance. In practice, RAN commonly uses scheduler-level priority and resource reservation (a hard/soft slicing mix) rather than complete physical separation.
The fundamental reason RAN slicing is difficult is that radio resources are physically finite in time and frequency, and available capacity fluctuates moment to moment due to propagation conditions, interference, and mobility. Since a link cannot be statically carved up as in wired networks, the scheduler dynamically divides resource blocks at each transmission time interval, reflecting per-slice priority and minimum-guaranteed resources (weights). For example, if a URLLC slice reserves 15% of resources as a minimum guarantee, control signals are not pushed out even when other slices surge. In this way, in the RAN, soft slicing that "reserves but shares leftover resources" becomes the realistic solution that compromises between efficiency and guarantee.
Transport slicing divides the backhaul and fronthaul segments connecting the base station and the core. Representative techniques are FlexE (Flexible Ethernet), which splits the Ethernet physical layer in slot units, IP/MPLS VPN, and segment routing (SRv6, etc.), which specifies the path at the source. Because the transport network is a segment that must deterministically guarantee latency, jitter, and bandwidth, strong physical-layer-level isolation (FlexE) is preferred for URLLC slices.
The transport network is often overlooked but in reality frequently becomes the end-to-end SLA bottleneck. No matter how precisely the RAN and core are sliced, if queuing delay or contention arises in the transport segment connecting them, the 1ms-class target collapses. FlexE divides 100G Ethernet into sub-channels in 5G-rate units and dedicates physical slots to a specific slice, deterministically guaranteeing latency and bandwidth even amid bursts of other traffic. In contrast, the IP VPN approach that relies on statistical multiplexing is flexible and cheap but can suffer large jitter under congestion, so it may be unsuitable for mission-critical slices.
Core slicing virtually places the 5G core's network functions (NFs) as per-slice instances. It combines session management (SMF), the user plane (UPF), access and mobility management (AMF), and so on according to slice requirements; in particular, placing the UPF close to the user (at the edge) can greatly reduce latency. Because the core is software-based (virtual machines, containers), it is partitioned and replicated relatively flexibly.
Meanwhile, to weave the partitions of the three domains into one end-to-end slice, the slice identifier (S-NSSAI) must be consistently mapped at domain boundaries, and traffic must be carried to the correct downstream path. That is, traffic that the RAN classified into a specific slice must be delivered exactly to the transport network's corresponding path and the core's corresponding NF set; if this mapping is misaligned, isolation breaks. Thus end-to-end slicing is completed only when, in addition to each domain's partitioning technology, the identification, mapping, and policy consistency that connect them are all in place.
The decisive foundation that made core slicing possible is that the 5G core was redesigned as a Service-Based Architecture (SBA). Because functions are composed of finely divided microservice-style NFs that communicate via standard APIs, a "Lego-style" configuration that picks only the NFs each slice needs is possible. For example, an mMTC slice keeps only minimal functions to lightly process the sessions of large numbers of devices, while a URLLC slice places a dedicated UPF at the edge to shorten the user-plane path. In this way, a compromise configuration that shares part of the control plane (e.g., a common AMF) while dedicating the user plane (UPF) per slice is commonly used in practice, a design choice aimed at simultaneously obtaining signaling efficiency and data isolation.
| Domain | Representative partitioning technique | Isolation strength | Main purpose |
|---|---|---|---|
| RAN | Resource blocks·scheduler priority | Medium (soft) | Radio latency·bandwidth |
| Transport | FlexE·VPN·segment routing | High (hard possible) | Deterministic latency·bandwidth |
| Core | Virtual NF instance separation | High | Function·session tailoring |
Comparing the three domains reveals that the "ease" and "cost" of isolation differ. The core is software-based, so replicating and separating instances is relatively easy and low-cost, whereas the RAN handles physically finite radio resources, so strong isolation immediately entails a large opportunity cost (resources other slices cannot use). The transport network is in between: physical slot partitioning such as FlexE is powerful but comes with an equipment-support and design burden. Therefore, practical design becomes an optimization problem of deciding "how strong an isolation to place in which segment" differently per domain, weighing service requirements against cost.
3. Slice Management and Orchestration Architecture
A slice is not done once created; it is a managed object with a lifecycle of request intake → design → deployment → operation/monitoring → decommissioning. This lifecycle perspective makes slicing a living service rather than a static configuration. A slice is created on demand and reclaimed after an event ends, and during operation it is continuously adjusted to meet the SLA, so this dynamic nature cannot be handled without management automation. 3GPP (the TS 28.530 series) defines this management with three layers of management functions. The diagram below shows how an upper-layer customer requirement is decomposed into lower-layer subnet resource allocation.
flowchart TD
CSMF["CSMF<br/>Communication service mgmt"] --> NSMF["NSMF<br/>Slice mgmt"]
NSMF --> NSSMF1["NSSMF (RAN)"]
NSMF --> NSSMF2["NSSMF (Core)"]
NSMF --> NSSMF3["NSSMF (Transport)"]
NSSMF1 --> RES["Physical·virtual resources (MANO/NFVO)"]
NSSMF2 --> RES
NSSMF3 --> RES
This management architecture is easy to understand when compared with the cloud's IaaS layered model. The customer "orders" the desired service quality, the orchestration layer automatically decomposes and executes it into lower-layer resource allocation, and during operation it re-adjusts resources so there are no SLA violations. This is why slicing is often called "the cloudification of the network" or NaaS.
At the top, the CSMF (Communication Service Management Function) receives a service requirement expressed in the customer's (enterprise/service) language (e.g., "an autonomous-driving support network with latency of 10ms or less and 99.99% availability") and translates it into network slice requirements. That is, it plays the role of an interpreter between business requirements and technical requirements. Thanks to this layer, customers can order the quality they want without knowing the internal network structure.
The NSMF (Network Slice Management Function) oversees the creation, modification, monitoring, and decommissioning of the entire end-to-end slice. The NSMF decomposes one slice into multiple subnet slices (NSSI) such as RAN, Core, and Transport, delegates the requirements to the NSSMF in charge of each subnet, and then weaves them together to guarantee the SLA end to end. The NSMF is the center of closed-loop automation that collects real-time performance indicators (KPIs) and reallocates resources when an SLA violation is anticipated.
The NSSMF (Network Slice Subnet Management Function) manages the per-domain subnet, and the actual resource allocation is performed by instructing NFV MANO (NFVO·VNFM·VIM) and the SDN controller. Thanks to this layer separation, upper-layer management stays consistent even when each domain uses a different vendor or technology.
The practical benefit of this three-layer management model lies in the separation of concerns. By dividing business requirements (CSMF)—end-to-end slice orchestration (NSMF)—per-domain resource execution (NSSMF), each layer can evolve and be replaced independently, securing scalability even in multi-vendor environments. In addition, GSMA proposed the GST (Generic Network Slice Template), which describes slice requirements in a standard format, and NEST, which concretizes it per operator, to standardize slice-specification negotiation between customers and operators and automated deployment. Without such templating, each slice would require manual design, making on-demand commercialization practically impossible.
The standard identifier for a slice is the S-NSSAI (Single Network Slice Selection Assistance Information), composed of the SST (Slice/Service Type) denoting the slice kind and the SD (Slice Differentiator) by which the operator subdivides it. When a device attaches, the core's NSSF (Network Slice Selection Function) selects the appropriate slice (and AMF) based on the device's requested S-NSSAI and subscription information. It is also standardized for a single device to attach to multiple slices simultaneously (e.g., work URLLC + general internet eMBB).
The key to the operation phase is closed-loop SLA assurance. The NSMF continuously collects KPIs such as each slice's latency, throughput, and packet loss, and when these approach the target or a violation is anticipated, it automatically reallocates resources or scales out the slice. For example, if a specific URLLC slice's latency approaches a threshold, the orchestrator spins up an additional edge UPF or reroutes the transport path. Running this monitor—decide—act cycle automatically via policy/AI rather than by humans is the premise of large-scale slice operation, and recently it is evolving into intent-based management, where you merely declare "what you want" and the system configures itself accordingly.
4. Comparison of Slice Types and Isolation Methods
3GPP defines standard SST values such as eMBB (SST=1), URLLC (SST=2), mMTC/mIoT (SST=3), and V2X (SST=4). Each type requires a fundamentally different resource profile. eMBB aims to maximize bandwidth, so it is assigned wide frequency and high-throughput UPFs; URLLC aims for latency/reliability, so it is assigned an edge UPF, preemptive scheduling, and dual paths; and mMTC aims for connection density and low power, so it is optimized for signaling efficiency and large-scale session processing. Because "what is optimized" differs in this way, per-slice design diverges greatly even on the same physical network.
Why these three demands cannot be satisfied simultaneously stems from the conflict in resource allocation. To obtain ultra-low latency, resources must be reserved (preempted) in advance to eliminate waiting, which directly conflicts with the bandwidth-maximization (eMBB) strategy of raising utilization via statistical multiplexing. Also, mMTC, which holds hundreds of thousands of devices at low power, must avoid frequent retransmission and elaborate scheduling, so it conflicts with high reliability (URLLC) as well. Slicing avoids this conflict by, instead of "finding a single optimum," "grouping together those with the same demand and optimizing each." This very point is where slicing decisively diverges from mere QoS tuning.
The strength of isolation also varies with the slice's purpose. Hard isolation, which sets aside physical resources exclusively, offers clear performance and security guarantees but has low resource utilization and is expensive; soft isolation, which shares resources but divides them by scheduling and policy, is efficient but leaves a risk of interference under surges. In practice, a hybrid strategy applying hard isolation to URLLC/mission-critical slices and soft isolation to general eMBB is common.
| Category | eMBB | URLLC | mMTC |
|---|---|---|---|
| Core demand | Ultra-high-speed bandwidth | Ultra-low latency·high reliability | Massive connectivity·low power |
| Target figures | Several Gbps | 1ms·99.999% | 1 million devices per km² |
| Resource strategy | Wide bandwidth | Edge UPF·preemption | Signaling efficiency |
| Representative cases | 8K broadcast·AR/VR | Remote surgery·factory control | Smart meters·environmental sensors |
A slice is not fixed but is operated in two ways, static and dynamic. A static slice is maintained for a long time, like a long-term contract (e.g., a factory-dedicated URLLC), whereas a dynamic slice is created and decommissioned only during a specific event or time window. For example, if a large-capacity uplink slice is created for only a few hours at a festival or concert venue and reclaimed after it ends, quality can be guaranteed only when needed, without having to keep resources reserved at all times. This flexibility of dynamic operation is the economic advantage unique to slicing that is hard to obtain with the dedicated-network build approach, and it lets an operator reuse resources across many customers along the time axis as well.
Slicing appears similar to conventional VLAN·VPN·QoS on the surface, but its essence differs. VLAN·VPN stay mainly at logical separation at the transport layer, and QoS is merely packet priority adjustment, so they do not encompass the end-to-end span including radio resources, core functions, and the management lifecycle. In contrast, slicing binds everything from the RAN to core functions and the management plane into a single automated end-to-end logical network, which is where the difference arises. This difference leads directly to the practical implication of "whether an independent SLA and operational autonomy can be granted per slice."
The meaning of isolation also differs from a security standpoint. Whereas VPN focuses on the confidentiality of data (encryption), slice isolation also includes mutual non-interference of performance, resources, and failures. That is, even if one slice is hit by a DDoS attack and its resources are exhausted, the SLAs of other slices must be maintained, so resource reservation, rate limits, and per-slice authentication (NSSAA) are designed together. For this reason, slicing is a concept that simultaneously requires performance isolation and security isolation, and one must beware that trusting logical isolation alone and neglecting verification can actually enlarge the attack surface.
5. Deep Dive: Standards Trends and Practical Application Cases
The latest trends can be viewed along two broad lines: the evolution of standards and the spread of commercial deployment.
On the standards side, after its basic skeleton was defined in 3GPP Release 15 (2018), roaming/interoperability and management automation were reinforced in Release 16, and in Release 17, policies for when a single device uses multiple slices simultaneously (NSSAA, per-slice authentication/authorization) and per-slice maximum-device-count control were refined. In subsequent discussions (Release 18 and beyond, so-called 5G-Advanced), inter-slice resource optimization and AI-based closed-loop operation are the topics, and in 6G, slicing is expected to expand into hyper-connected, hyper-distributed slices spanning terrestrial, satellite, and non-terrestrial networks (NTN). However, since the detailed standards are being revised, whether a specific feature is mandatory should be confirmed against the latest specifications.
Lessons learned from early commercial deployments are also noteworthy. The standards prescribe end-to-end slicing, but in reality the device (chipset), RAN equipment, transport network, and core must all consistently support slicing and interoperability verification is needed, so the commercialization of full end-to-end isolation is proceeding in stages. Early on, core-centric slicing and URLLC-centric cases lead, with strong RAN and transport isolation following. Also, the lack of per-slice charging/SLA-measurement systems and the complexity of devices' multi-slice access policies remain practical challenges to broader adoption, and many assess that the maturation of these areas is the key to mass commercialization.
Domestically, in combination with the previously discussed [[private-5g]] (e-Um 5G) scheme, a representative case is a smart-factory operator separately operating a control URLLC slice and a video/data eMBB slice. For example, a 1ms-class low-latency slice is assigned to robot control and a high-bandwidth slice to quality-inspection video transmission, so the two traffic types do not push each other out. On the operator side, on-demand cases are increasing where a broadcast large-capacity uplink slice is temporarily created and operated during a large sporting-event broadcast and decommissioned after it ends. In the autonomous-driving and vehicle-communication (V2X) field, a structure separating an ultra-low-latency slice for safety messages and a bandwidth slice for infotainment is under discussion. What these cases have in common is that they isolate and guarantee traffic with extremely different service characteristics on a single infrastructure.
The telemedicine field also clearly reveals the value of slicing. The haptic feedback of a remote-surgery robot demands round-trip latency within a few ms and extreme reliability, whereas the same hospital's electronic-medical-record lookups or educational videos do not need that level of real-time performance. Here, if surgical control is given a URLLC slice with dual paths and hard isolation while general business traffic is given a soft-isolation eMBB slice, the hospital can safely run the two opposing demands in parallel on one 5G infrastructure. In this way, slicing "tailors the network to service requirements," greatly reducing capital and operating costs compared with the past approach of laying a dedicated network per service, while individually guaranteeing quality.
6. Considerations and Implications
- Trade-off between isolation and efficiency: Hard isolation firmly ensures SLA and security but lowers resource utilization. The key strategy is to apply hard/soft isolation differentially according to a service's degree of mission-criticality and to adjust the levels of resource reservation and over-provisioning based on data.
- End-to-end orchestration and automation maturity: The value of slicing comes from automated lifecycle management penetrating the RAN, transport, and core. Interoperability when domains/vendors differ, and the level of closed-loop (SLA monitoring → resource reallocation) automation, determine actual operational success or failure. Linkage with AIOps and intent-based management is anticipated.
- Security/isolation verification and attack-surface expansion: Since logical isolation does not equal complete security, isolation verification against inter-slice lateral movement and resource-exhaustion attacks, along with per-slice authentication (NSSAA), is needed. Considering that the attack surface has widened due to virtualization and multi-layer management, zero-trust principles must be applied.
- Business model and regulation/charging: A slice is the basis for NaaS and quality-differentiated sales, but it is intertwined with regulatory issues such as net neutrality and fair competition. A system that can meter, charge, and audit per-slice SLAs and a standard KPI definition become prerequisites for commercialization.
- Integration of related technologies: The combination with SDN·NFV·[[edge-computing]]·container orchestration governs slicing's performance and flexibility, and architecture design mindful of future expansion into integrated slicing with non-terrestrial networks such as satellites is required.
- End-to-end interoperability and standards compliance: As the device, RAN, transport, core, and management systems are composed of different vendors, interoperability verification compliant with 3GPP·GSMA·ITU-T standards (S-NSSAI, GST/NEST, KPI definitions) is essential. If even one segment is non-compliant, the end-to-end slice does not hold, so interoperability testing and a phased adoption roadmap must be designed together at the outset.
References
- 3GPP TS 23.501, System architecture for the 5G System (5GS)
- 3GPP TS 28.530/28.531, Management and orchestration; Concepts, use cases and requirements for network slicing
- GSMA, "Generic Network Slice Template (GST)"
- ITU-T Y.3112, Framework for the support of network slicing in the IMT-2020 network
In one line: Network slicing is a core 5G/6G technology that, building on SDN/NFV, creates multiple logically isolated end-to-end virtual networks penetrating the RAN, transport, and core on a single physical infrastructure, individually guaranteeing conflicting service demands such as eMBB, URLLC, and mMTC through per-slice SLAs.