A single 5G network is expected to support very different service worlds at the same time. One user may be watching high-definition video, another may be using a massive IoT sensor connection, while an industrial customer may need ultra-low latency and higher reliability for a local production process. These services do not ask the network for the same bandwidth, delay, security, device density or coverage behavior.
Building a separate physical mobile network for every service type is not realistic. The cost would be too high, resources would be difficult to manage, and deployment would be slow. 5GC network slicing solves this problem by creating logical private networks over shared physical infrastructure. Each slice can be designed with its own service characteristics, while still reusing common access, transport, computing and core network resources.
In simple terms, a network slice is a customized logical network for a specific service group, industry customer or application category. It is not just a 5GC concept inside the core. It is an end-to-end idea that may involve the 5G access network, transport or bearer network and 5G core network. The value comes from balancing two goals: physical resource sharing for cost efficiency, and logical isolation for service differentiation.
Why Slices Exist
The background of 5GC network slicing is the large difference among 5G service scenarios. The common categories are eMBB, mMTC and uRLLC. Enhanced mobile broadband focuses on high throughput and rich user experience. Massive machine type communication focuses on a very large number of low-rate devices. Ultra-reliable low-latency communication focuses on strict latency, reliability and service assurance.
These categories create different network design priorities. eMBB may need high or ultra-high per-device throughput and broad coverage. mMTC may require massive device density, low data rate and low cost per bit. uRLLC may require very low latency, higher reliability and tighter control over service behavior. Treating all these services as ordinary best-effort traffic would waste the potential of 5G.
Network slicing allows an operator to serve these different needs through logical separation. A consumer broadband slice, an industrial control slice and an IoT slice can share physical infrastructure, but their service policies, core network functions, QoS behavior and operational rules can be different. This creates a more flexible way to sell and operate mobile network capability.
What A Slice Contains
A network slice is a logical network that provides specific network capabilities and characteristics. A Network Slice Instance, or NSI, is the deployed version of that slice. It contains a set of network function instances and the resources needed to run them, such as computing, storage and networking resources.
In a 5GC deployment, some functions may be shared by multiple slices, while others may be dedicated to one slice. For example, several slices may share common control plane functions such as AMF in some designs. At the same time, each slice may use its own SMF and UPF so that session handling and user plane traffic can follow slice-specific requirements.
This creates a clear distinction between common parts and slice-specific parts. The common part reduces duplication and saves resources. The slice-specific part gives each service its own behavior, data path and service treatment. In many designs, one UE may also access more than one slice, with different PDU sessions using different slice-related paths.
Network slicing does not require every function to run on a physically separate server. Different slice functions may run on the same X86 server cluster and still remain isolated through virtualization, KVM, container namespaces, VPN mechanisms and management policies. This is one reason slicing is more practical than building separate physical networks.
How Slice Identity Works
Slice selection depends on identifiers. The key identifier is S-NSSAI, or Single Network Slice Selection Assistance Information. It uniquely identifies one network slice. NSSAI is a collection of multiple S-NSSAIs, so it represents a group of slices rather than only one.
S-NSSAI contains two main parts. SST, or Slice/Service Type, identifies the slice type. Common SST values include 1 for eMBB, 2 for URLLC, 3 for MIOT and 4 for V2X. SD, or Slice Differentiator, is used to distinguish different slices of the same type. This is useful when two slices both belong to the same service class but serve different customers, regions or business policies.
Several NSSAI terms are important in real procedures. Configured NSSAI may be preconfigured in the UE or delivered by AMF, and it helps the UE generate its requested slice information. Subscribed NSSAI is the slice subscription data stored for the user. Requested NSSAI is carried by the UE in the registration request. Allowed NSSAI is the slice set the UE is allowed to access in the current registration area. Rejected NSSAI tells the UE which slice access has been denied.
The allowed slice set is not decided by the UE alone. It is affected by NSSF policy, UDM subscription data, AMF support capability and registration area conditions. The final allowed result is delivered by AMF to the UE in the registration accept message. A UE can be allowed to access up to eight slices at the same time, meaning the Allowed NSSAI can contain up to eight S-NSSAIs.
How Selection Is Decided
5G introduces NSSF, the Network Slice Selection Function, to help select a proper slice instance, choose an AMF entry point for the slice and determine Allowed NSSAI. Slice selection happens in two major stages. The first stage occurs during initial registration, where the network selects the AMF associated with the slice and determines the slice set allowed for the UE. The second stage occurs during PDU session establishment, where SMF, UPF and related user plane handling are selected.
During registration, the UE may choose a Requested NSSAI based on its Configured NSSAI or previously saved Allowed NSSAI. When the gNB needs to select an AMF, it may use 5G-S-TMSI or GUAMI if available. If these identifiers are not available, the gNB can use Requested NSSAI to guide AMF selection. If none of these conditions helps, the message may be sent to a default AMF.
Requested S-NSSAI improves the first AMF selection attempt. Instead of choosing blindly, the gNB has slice-related information that increases the chance of selecting a suitable AMF. If the selected AMF can serve the requested slice and the UE has subscription permission, AMF can send registration accept with the proper Allowed NSSAI.
If the AMF cannot serve the requested slice, or if the UE is not subscribed to that slice, the AMF may need to query NSSF. NSSF can return a different Allowed NSSAI and a suitable AMF. The registration request may then be rerouted directly or indirectly toward the correct AMF. This keeps the slice selection process flexible while still controlled by subscription, policy and network capability.
Why Isolation Matters
Isolation is one of the main reasons enterprises and industry customers care about slicing. Each slice should behave like a logical private network, even though physical resources are shared. Different slices should not freely see or affect one another. This supports security, operational independence and service-level control.
Isolation can be implemented at several layers. Slice selection separates the service access path. Virtual machines or containers separate compute environments. Namespace mechanisms can isolate container-level resources. VPN and transport separation can protect traffic paths. Policy control can define different QoS and service rules. Management systems can also separate customer visibility and operational permissions.
At the business level, isolation makes it easier to provide customized service. A factory slice may need stronger reliability and lower latency. A video broadband slice may need high throughput. An IoT slice may need large device capacity and low signaling cost. Each slice can be shaped around different requirements while avoiding the cost of a fully separate physical network.
Lifecycle Management Matters
Network slices are not static objects. Like network functions, they have a lifecycle. A slice can be prepared, instantiated, configured, activated, monitored, scaled, modified, deactivated and terminated. This lifecycle management is important because slicing only becomes commercially useful when it can be created, changed and removed efficiently.
The lifecycle can be viewed in four stages. The first is preparation, including slice template design, pre-provisioning and network environment preparation. The second is instantiation, configuration and activation, where the slice is created, service configuration is loaded and the slice is brought into service. The third is runtime operation, where KPIs, alarms, reports and service performance are monitored. Based on those results, the system may trigger self-healing or automatic scaling. The fourth is decommissioning, where users may be migrated, the slice is deactivated and resources are released.
This process is usually handled by a slice manager together with MANO. MANO includes orchestration, VNF management and virtual infrastructure management. EMS or NMS functions handle network element management, configuration, alarm, performance and security-related operations. Together, these systems help turn a slice design into a deployed and manageable network service.
Templates Enable NSaaS
A slice template describes the network functions, specifications, resources, connections and service parameters required by the slice. To external customers, it can look like a slice template. Inside the operator environment, it may need to be converted into a network service template that MANO can understand. Formats such as HOT, OVF and TOSCA may be used depending on the orchestration environment.
Template design begins with customer requirements. The operator needs to understand QoS demand, bandwidth, online user scale, redundancy, security and service coverage. These requirements are then translated into network resources and 5GC parameters, such as 5QI and related policy control. After that, the template can be uploaded to the slice manager or orchestrator for lifecycle management.
This creates the idea of Network Slice as a Service, or NSaaS. In an ideal model, an industry customer can select a slice template online, submit service requirements, complete an order and receive slice parameters after automated creation. The slice mall or customer portal sends the order to BOSS and the orchestrator. The orchestrator works with VNFM, VIM and EMS or NMS to instantiate the slice, allocate resources, configure network functions and confirm service readiness.
The result is a new commercial model. Instead of long offline negotiation and manual activation, the customer may receive a self-management portal, faster provisioning and elastic expansion. A small customer could start with a slice supporting 500 users, run it for one year and later expand to 1000 users. If the service ends, the slice can be deleted and resources can be released. This is the practical value of slicing: customized service, faster time to market and better resource reuse.
FAQ
Can a network slice exist without dedicated physical hardware?
Yes. A slice is a logical network. It can share physical servers, transport resources and access infrastructure while using virtualization, containers and policy control to maintain separation.
Why does one UE need multiple slices?
A UE may run different service types at the same time. For example, one PDU session may use an enterprise service slice while another uses a general internet or IMS-related slice.
What decides whether a slice request is accepted?
Acceptance depends on subscription data, AMF capability, NSSF policy, registration area conditions and whether the requested S-NSSAI is supported in the current network context.
Why is SD needed if SST already identifies the slice type?
SST identifies the service type, while SD distinguishes different slices within the same type. This allows multiple eMBB, URLLC or IoT slices to coexist with different business meanings.
How does slicing shorten commercial deployment time?
Templates, orchestration and automated lifecycle management reduce manual design and deployment work. Scaling, activation and resource release can happen much faster than traditional dedicated network construction.
5GC network slicing is not only a technical architecture. It is a way to package mobile network capability into logical, isolated and service-specific networks. By combining shared infrastructure, slice identity, controlled selection, lifecycle management and template-based orchestration, operators can support different industries and service types without building a separate physical network for every customer.
