Network Slicing¶

Learning objectives¶

After reading this page, you will be able to:

• Explain the Why (why Network Slicing is needed) from the perspective of per-use-case optimization: it is hard to optimize ultra-high-speed video, ultra-low-latency control, and massive IoT all at once on a single physical network.
• Explain that a slice (Network Slice) is a logically independent virtual network built on a common physical infrastructure.
• Explain that an S-NSSAI (Single NSSAI) is the identifier of one slice, composed of an SST (Slice/Service Type) and an optional SD (Slice Differentiator).
• Distinguish and explain the differences and relationships among the four kinds of NSSAI (Requested / Allowed / Configured / Subscribed).
• Explain the role of the NSSF (Network Slice Selection Function) (assisting slice selection when the AMF cannot resolve it on its own, and managing NSSAIAvailability).
• Explain the two timings of slice selection: at registration (the UE presents the Requested NSSAI → the AMF decides the Allowed NSSAI) and at PDU Session time (selecting the in-slice SMF/UPF by S-NSSAI+DNN).
• Explain the representative use-case categories eMBB / URLLC / mMTC and that the standardized SSTs correspond to them (specific values: see TS 23.501, to be confirmed).
• Contrast the fact that 4G (EPC) has no standardized slice concept, and that separation via DNN≒APN and DECOR/eDECOR (dedicated core networks) are the nearest precursor concepts.

Prerequisites¶

It will go more smoothly if you first understand the following. If you haven't yet, start from the curriculum.

• Understanding of Registration (slice selection happens inside Registration; the UE presents the Requested NSSAI, and the AMF returns the Allowed NSSAI) → Initial Registration
• Understanding of the PDU Session (at PDU Session establishment, the in-slice SMF/UPF are chosen by S-NSSAI+DNN) → PDU Session Establishment
• Understanding of QoS (each slice can have a different QoS/DNN; slices and QoS are related) → QoS
• The role of the AMF (slice support, deciding/holding the Allowed NSSAI, querying the NSSF) → AMF

What you'll learn in this chapter¶

This chapter focuses narrowly on the core of Network Slicing (slice identification and selection). It makes the main topics slice identification via S-NSSAI (SST+SD), the four kinds of NSSAI, the role of the NSSF, and slice selection at registration and at PDU Session time.

• The Registration procedure itself is the topic of Initial Registration. This chapter makes the topic the details of slice selection that happen inside it, and defers the full registration procedure to registration.
• The details of QoS (QoS Flow / 5QI / GBR / AMBR) are deferred to QoS. This chapter only touches on the relationship that each slice can have a different QoS/DNN.
• The PDU Session establishment procedure itself is deferred to PDU Session Establishment. This chapter limits itself to the slice-selection perspective (S-NSSAI+DNN → in-slice NF selection).
• The details of NF Discovery / NRF and the details of radio-side slicing (RAN slicing) are out of scope, and are mentioned only conceptually (including parts that are implementation-dependent).

Why — why Network Slicing is needed¶

Let's start with the Why (why it's needed). A 5G network carries, at the same time, services with completely different requirement characteristics. Ultra-high-speed video (eMBB) needs large bandwidth, factory control and autonomous driving (URLLC) need millisecond-order ultra-low latency and high reliability, and massive IoT sensors (mMTC) need a huge number of simultaneous connections that are each small per device.

If these were all handled uniformly on one and the same network, the optimal design for each could not coexist. Push latency to the extreme and you sacrifice efficiency for massive connectivity; maximize bandwidth and latency guarantees loosen. Hence, building multiple logically independent virtual networks (slices), each optimized per use case, on top of a common physical infrastructure is Network Slicing. Each slice can have an NF configuration, resources, and policies (QoS/DNN, etc.) tailored to its use case.

Overview¶

The skeleton of Network Slicing is two things: the mechanism for identifying slices (S-NSSAI) and the mechanism for deciding which slice to use (NSSAI and slice selection).

• Slice (Network Slice) — a logically independent virtual network built on a common physical infrastructure. It is optimized per use case (eMBB/URLLC/mMTC, etc.).
• S-NSSAI (Single NSSAI) — the identifier that identifies one slice. It is composed of an SST (Slice/Service Type) plus an optional SD (Slice Differentiator).
• NSSAI (Network Slice Selection Assistance Information) — a set of S-NSSAIs. Depending on the use, there are four kinds — Requested / Allowed / Configured / Subscribed (see the table below).

The representative standardized SSTs are mapped to use cases.

The key point of slice selection is the two-stage structure of "the UE requests (Requested)" → "the network permits (Allowed)", with the NSSF assisting when the AMF cannot decide on its own.

Basic Concept — a beginner-friendly explanation¶

To understand Network Slicing, nail down three keywords.

1. What a slice is (a logically independent network)¶

A slice (Network Slice) is one logically independent network built on top of common physical equipment. Even though it physically uses the same base stations and the same server groups, it behaves as a separate network logically and is optimized per use case. To use the apartment analogy, the building (physical) is one, but each unit (a slice) is an independent living space.

2. What an S-NSSAI is (a slice's "jersey number" = SST+SD)¶

An S-NSSAI (Single NSSAI) is the jersey number (identifier) attached to one slice. It is made of two parts.

• SST (Slice/Service Type) — represents what kind of use case that slice is for (there are standardized values corresponding to eMBB / URLLC / mMTC, etc.; specific values are to be confirmed).
• SD (Slice Differentiator) — optional auxiliary information to further distinguish within the same SST (e.g., separating customer A's use from B's within the same eMBB). The SD is optional, and some S-NSSAIs have none.

In other words, it is a jersey number that does "broad classification by SST, finer classification by SD."

3. The four kinds of NSSAI (Requested, Allowed, Configured, Subscribed)¶

NSSAI is a collection of S-NSSAIs. It splits into four kinds by who holds it and when it is used. In plainer terms:

• Requested NSSAI (requested) — the list the UE asks the network for, saying "I want to use these."
• Allowed NSSAI (allowed) — the list the network returns, saying "you may use these" (notified in the Registration Accept).
• Configured NSSAI (configured) — the list preconfigured in the UE (the groundwork for what to request).
• Subscribed S-NSSAI (subscribed) — the slices permitted by the subscription (held by the UDM as subscription data).

To use a restaurant analogy: Configured = the menu in hand, Requested = your order, Subscribed = what you can order on your plan, Allowed = the items the restaurant has confirmed "we can make." That is the relationship.

Putting how these four are narrowed down to Allowed on a single sheet gives the following. The two on the UE side (Configured/Requested) and the two on the network side (Subscribed/Allowed) are cross-checked at registration and settle into the Allowed NSSAI.

flowchart LR
    subgraph UEside["Held by the UE side"]
        direction TB
        CONF["Configured NSSAI
Preconfigured in the UE (groundwork)"]
        REQ["Requested NSSAI
This time's 'want to use' request"]
        CONF -->|"Build the request on this groundwork"| REQ
    end
    subgraph NWside["Held/decided by the network side"]
        direction TB
        SUB["Subscribed S-NSSAI
Permitted by subscription (UDM)"]
        ALLOW["Allowed NSSAI
May be used this time (confirmed)"]
        SUB -->|"Gives the permitted range"| ALLOW
    end

    REQ ==>|"Presented at registration"| AMFcheck{"AMF cross-checks
(NSSF when needed)"}
    SUB ==>|"Cross-check material"| AMFcheck
    AMFcheck ==>|"Narrowing result"| ALLOW
    ALLOW ==>|"Notified in Registration Accept"| USE["The UE uses slices
within this range"]

    classDef ue fill:#efe,stroke:#3a3;
    classDef nw fill:#eef,stroke:#66a;
    classDef res fill:#fde,stroke:#c69,stroke-width:2px;
    class CONF,REQ ue;
    class SUB,ALLOW nw;
    class ALLOW res;

Architecture¶

Here are the elements involved in Network Slicing and the interfaces that connect them. It shows the typical picture where a common AMF orchestrates registration and slice selection, and an NF group such as SMF/UPF per slice can be provided (deployment is slice-design- and implementation-dependent).

flowchart LR
    UE(["UE
(presents Requested NSSAI)"]) -- "N1 (NAS)" --> AMF["AMF
(slice support / decides Allowed NSSAI)"]
    RAN["NG-RAN / gNB"] -- "N2 (NGAP): S-NSSAI" --> AMF
    UE -.RRC.- RAN
    AMF -- "N22 (Nnssf): NSSelection
(only when needed)" --> NSSF["NSSF
(slice selection assistance / NSSAIAvailability)"]
    AMF -. "NF discovery (concept)" .-> NRF["NRF
(slice-aware NF discovery)"]

    subgraph SliceA["Slice A (e.g., eMBB)"]
      SMFa["SMF"] --> UPFa["UPF"]
    end
    subgraph SliceB["Slice B (e.g., URLLC)"]
      SMFb["SMF"] --> UPFb["UPF"]
    end

    AMF -- "select per S-NSSAI" --> SMFa
    AMF -- "select per S-NSSAI" --> SMFb

    classDef core fill:#efe,stroke:#3a3,stroke-width:2px;
    class AMF,NSSF core;

The roles of each element are as follows.

• UE — presents the slices it wants to use as the Requested NSSAI (with the Configured NSSAI as groundwork).
• AMF — the command center of slice selection. It cross-checks the Requested NSSAI against the Subscribed S-NSSAI / Configured NSSAI and decides and holds the Allowed NSSAI. When it cannot resolve on its own, it queries the NSSF.
• NSSF (Network Slice Selection Function) — handles slice selection assistance when the AMF cannot decide on its own, and management of the NSSAI available in each TA (Tracking Area) (NSSAIAvailability). Since there is no individual NF page, see the NSSF row in the NF Dictionary.
• SMF / UPF — selected per S-NSSAI, they handle the PDU session / user-plane forwarding within that slice (chosen at PDU Session establishment).
• PCF — distributes the URSP (UE Route Selection Policy) to the UE, letting the UE side decide which app/traffic goes onto which S-NSSAI/DNN (details deferred to PCF/URSP).
• NRF (NF Repository Function) — discovers NFs corresponding to slices (NF Discovery, concept only; details out of scope).

For details on the interfaces, see the Interface Dictionary.

Network Function¶

Here are the roles of the main NFs involved in Network Slicing. Since the NSSF has no individual page, see the NSSF row in the NF Dictionary. The NG-RAN is on the radio access side and is not a core NF.

Interface / Protocol¶

Here are the main interfaces and protocols used in this context. We organize how slice information flows across which segments and in what form. Some of the IE names and operation names are version- and implementation-dependent and are to be confirmed.

For details on the protocols, see the Protocol Dictionary, and for the interface list, see the Interface Dictionary.

Procedure — Call Flow¶

This is the heart of this page. The flow of slice selection is shown as a Mermaid sequenceDiagram. The basis is TS 23.502 (registration / slice selection procedures), TS 23.501 §5.15 (Network Slicing; section number to be confirmed) / §6.2.14 (NSSF), TS 24.501 (NAS NSSAI), TS 29.531 (Nnssf), and TS 38.413 (NGAP S-NSSAI). Because slice selection in many cases happens as part of Initial Registration, here we focus on slice selection (for the full registration procedure, see registration).

sequenceDiagram
    autonumber
    participant UE
    participant RAN as NG-RAN / gNB
    participant AMF
    participant NSSF
    participant UDM
    participant SMF

    Note over UE,RAN: RRC connection establishment (radio side, outline)
    UE->>RAN: Registration Request (NAS: Requested NSSAI)
    Note right of RAN: TS 24.501. Includes the Requested NSSAI
    RAN->>AMF: Carry the NAS in an Initial UE Message (NGAP)
    Note right of RAN: Initial AMF selection (RAN outline)

    AMF->>UDM: Fetch subscriber data (Subscribed S-NSSAI)
    UDM-->>AMF: Subscribed S-NSSAI
    Note over AMF: Cross-check the Requested NSSAI against Subscribed / Configured

    opt When the AMF cannot resolve on its own (conditional)
        AMF->>NSSF: Nnssf_NSSelection (Requested NSSAI / TAI, etc.)
        NSSF-->>AMF: Allowed NSSAI / appropriate AMF info
        Note right of NSSF: N22 / TS 29.531 / TS 23.501 §6.2.14
    end

    opt When AMF reselection is needed (conditional)
        Note over AMF: Relocate to the appropriate AMF (AMF reselection)
    end

    AMF->>UE: Registration Accept (NAS: Allowed NSSAI)
    UE->>AMF: Registration Complete (NAS)
    Note over UE,AMF: Thereafter, slices can be used within the Allowed NSSAI

    Note over UE,SMF: [At PDU Session time] Subsequent in-slice NF selection (overview)
    UE->>AMF: PDU Session Establishment Request (S-NSSAI + DNN)
    Note right of AMF: Select the in-slice SMF by S-NSSAI+DNN
    AMF->>SMF: To the selected in-slice SMF (→ in-slice UPF selection)
    Note over AMF,SMF: For details, see pdu-session

Step-by-step explanation (numbers correspond to the diagram above)¶

1-2. UE→(R)AN→AMF: The UE sends a Registration Request carrying the Requested NSSAI (the set of slices it wants to use), and the gNB conveys it to the AMF in an Initial UE Message (NGAP) (the initial AMF selection is done by the RAN). 3-4. AMF↔UDM: The AMF fetches subscriber data and obtains the Subscribed S-NSSAI (the slices permitted by the subscription). The AMF cross-checks the Requested NSSAI against the Subscribed / Configured NSSAI. 5-6. (conditional) AMF↔NSSF: If the AMF cannot resolve the slice on its own, it queries the NSSF with Nnssf_NSSelection (N22) and obtains the Allowed NSSAI and (if needed) the appropriate AMF info (TS 29.531, TS 23.501 §6.2.14). 7. (conditional) AMF reselection: If the current AMF is not appropriate to accommodate the requested slices, it can be relocated (AMF reselection) to an appropriate AMF (condition- and configuration-dependent). 8-9. Registration accept: With AMF→UE Registration Accept, the Allowed NSSAI is notified. Thereafter, the UE can use multiple S-NSSAIs (slices) within this range. It completes with UE→AMF Registration Complete. 10-12. (At PDU Session time) In-slice NF selection: When the UE specifies S-NSSAI + DNN in the PDU Session Establishment Request, the AMF selects the SMF within that slice, and the SMF selects the UPF within that slice. For the detailed procedure, see PDU Session Establishment.

References: TS 23.501 §5.15 (Network Slicing; section number to be confirmed) / §6.2.14 (NSSF), TS 23.502 (the registration procedure involving slice selection), TS 24.501 (NAS NSSAI), TS 29.531 (Nnssf), TS 38.413 (NGAP S-NSSAI).

Signal Flow¶

We organize the main "information containers" involved in slice selection, by direction. Some of the IE names and operation names are version- and implementation-dependent and are to be confirmed.

State Machine¶

A slice is not a topic with an independent, heavy state machine. Here, we show with diagrams how the NSSAI gets confirmed from the UE's perspective, and the AMF's decision logic for slice selection (conceptual representations for understanding; the basis is TS 23.501 §5.15, section number to be confirmed).

First, the flow of NSSAI confirmation from the UE's perspective.

stateDiagram-v2
    [*] --> Configured: Configured NSSAI is set (not yet registered)
    Configured --> Requested: Present the Requested NSSAI at registration
    Requested --> Allowed: Obtain the Allowed NSSAI in the Registration Accept
    Allowed --> InUse: Establish a PDU session with an S-NSSAI within Allowed
    InUse --> Allowed: Session release (Allowed is retained)
    Allowed --> [*]: De-registration, etc.

• Configured — the Configured NSSAI is set in the UE, but it has not yet registered.
• Requested — the state where the Requested NSSAI has been presented at registration.
• Allowed — the state where the Allowed NSSAI has been received in the Registration Accept and the usable slices are confirmed.
• InUse — the state where a PDU session is set up using an S-NSSAI within Allowed and slices are actually in use.

Next, the decision logic (flowchart) for when the AMF selects a slice. The Allowed NSSAI is decided along this judgment.

flowchart TD
    A["Receive the Requested NSSAI"] --> B{"Can it be resolved by
cross-checking against Subscribed / Configured?"}
    B -- "Yes" --> C["The AMF decides the Allowed NSSAI"]
    B -- "No (cannot resolve on its own)" --> D["Query the NSSF with Nnssf_NSSelection"]
    D --> E{"Is the appropriate AMF the current AMF?"}
    E -- "Yes" --> C
    E -- "No" --> F["AMF reselection (relocate to the appropriate AMF)"]
    F --> C
    C --> G["Return the Allowed NSSAI in the Registration Accept"]

Packet Analysis (Wireshark)¶

Here are the focal points when analyzing Network Slicing with Wireshark. Slice information appears mainly in NAS (N1) and NGAP (N2).

Main display filters¶

Points to look at when decoding (main IEs)¶

• The Requested NSSAI in the NAS Registration Request — the set of slices the UE requests. Each S-NSSAI contains an SST (+ an optional SD) (IE name to be confirmed).
• The Allowed NSSAI in the NAS Registration Accept — the set of slices the network permitted. The UE uses slices within this range (IE name to be confirmed).
• The NGAP S-NSSAI IE — accompanying PDU Session Resource setup, etc., the S-NSSAI of the target slice is carried to the NG-RAN (IE name / storage position to be confirmed).

Configuration¶

Here are the structure-level essentials of the configuration for making Network Slicing work. Concrete values and vendor-specific items (Cisco, etc.) are implementation-dependent, and we do not write fictitious values here.

Configuration perspective for slice identification/support (AMF/NSSF side)¶

• Supported S-NSSAI (SST/SD) — the list of S-NSSAIs supported by the AMF and each TA. The SST uses standardized values corresponding to use-case categories (eMBB/URLLC/mMTC, etc.), but the specific values are to be confirmed against TS 23.501 §5.15 (section number to be confirmed; do not use fictitious values). The SD is assigned as needed.
• NSSAIAvailability — configured on the NSSF side as "which NSSAI can be used in which TA" (aligned with the AMF via N22).
• Configured NSSAI — the default set of S-NSSAIs configured on the UE side (or via provisioning).

Provisioning of subscriber slices (UDM/UDR)¶

• Subscribed S-NSSAI — register in the UDM/UDR the slices permitted per subscriber (SUPI) (may include a default-slice designation = to be confirmed).

Configuration perspective for per-slice NF deployment¶

• Per-slice SMF/UPF — whether to place a dedicated NF per slice or share them is implementation-dependent. Register each NF's supported S-NSSAIs in the NRF to make slice-aware NF discovery work.

Trouble Shooting¶

Here is the triage for representative slice-related troubles (in general terms). For details on Cause values, see the Cause Dictionary.

Comparison with EPC¶

Let's contrast them so that those experienced with 4G (EPC) can bridge over to 5G. 4G has no standardized "slice" concept like 5G's. As the nearest precursor concepts, there are service separation via DNN≒APN and DECOR/eDECOR (dedicated core networks).

Release differences¶

Here are the main topics related to Network Slicing. We mark uncertain items as to be confirmed and do not assert them.

• Rel-15 — The basics of Network Slicing (slice selection at registration and at PDU Session time via S-NSSAI (SST/SD) / NSSAI (Requested/Allowed/Configured/Subscribed) / NSSF (Nnssf, N22)) were established (the foundation of TS 23.501 §5.15; section number to be confirmed).
• NSAC (Network Slice Admission Control) — an extension that controls the upper limit of registered UEs / PDU sessions per slice (said to be Rel-16 or later, but the introduction Release and detailed operation are to be confirmed). Concept only; details to be confirmed.
• Rel-17 / Rel-18 (5G-Advanced) — slice-related extensions (slice selection, charging, interworking, etc.) continue (the concrete differences are to be confirmed).

3GPP Specification¶

FAQ¶

Summary¶

• Network Slicing is the mechanism for building multiple logically independent virtual networks (slices) on a common physical infrastructure and optimizing them per use case (eMBB/URLLC/mMTC).
• A slice is identified by an S-NSSAI (SST[+SD]). The SST is the use-case category (broad classification; standard values to be confirmed), and the SD is the finer classification within the same SST (optional).
• NSSAI is a set of S-NSSAIs, with four kinds: Requested (UE request) / Allowed (NW permission, returned in the Accept) / Configured (UE setting) / Subscribed (subscription).
• Slice selection has a two-stage structure. At registration, the UE's Requested NSSAI → the AMF cross-checks against Subscribed/Configured, queries the NSSF (Nnssf, N22) when needed → returns the Allowed NSSAI (with AMF reselection depending on conditions). At PDU Session time, the in-slice SMF/UPF are chosen by S-NSSAI+DNN.
• With URSP (distributed by the PCF), the UE decides which app/traffic goes onto which S-NSSAI/DNN.
• 4G has no standardized slice; DECOR/eDECOR (dedicated core) is the precursor concept (to be confirmed).
• The basis is TS 23.501 §5.15 (Network Slicing) / §6.2.14 (NSSF) / TS 23.502 / TS 24.501 / TS 29.531 (Nnssf) / TS 38.413 (S-NSSAI) (some of the section numbers, SST values, and IE names are to be confirmed).

Practice — comprehension check and exercises¶

Comprehension check¶

Exercises¶

Question: Reorder the following main steps of "slice selection at registration" into the correct order.

A. The AMF returns the Allowed NSSAI in the Registration Accept
B. The UE sends a Registration Request carrying the Requested NSSAI
C. (conditional) The AMF queries the NSSF with Nnssf_NSSelection
D. The AMF cross-checks the Requested NSSAI against Subscribed / Configured
E. (conditional) AMF reselection (relocate to the appropriate AMF)
F. The AMF fetches the Subscribed S-NSSAI from the UDM

Next Step¶

Here are the next steps to deepen your understanding.

• Direct upstream: Initial Registration (slice selection happens inside this procedure; the transport of Requested/Allowed NSSAI)
• Related procedure: PDU Session Establishment (the in-slice SMF/UPF are chosen by S-NSSAI+DNN)
• Related topic: QoS (each slice can have a different QoS/DNN)
• Related NFs: AMF (deciding/holding the Allowed NSSAI) ／ SMF (sessions per S-NSSAI) ／ UPF (in-slice forwarding) ／ PCF (UE-side route via URSP)
• NSSF: the NSSF row in the NF Dictionary (Nnssf: NSSelection / NSSAIAvailability, N22, TS 23.501 §6.2.14)
• Related interfaces: N1 / N2 / N4 / N7
• Dictionaries: Message Dictionary / Timer Dictionary / Cause Dictionary / Protocol Dictionary / NF Dictionary / Interface Dictionary