The Role of NSSF in 5G Network Slicing

Network slicing allows a single physical 5G infrastructure to support multiple logical networks, each tailored for a specific service type -- enhanced mobile broadband, ultra-reliable low-latency, massive IoT, or enterprise verticals. But slicing only works if the network can correctly select which slice a UE should connect to and route it to the right AMF and network resources. This is the job of the Network Slice Selection Function (NSSF).

The NSSF is defined in 3GPP TS 23.501 Section 6.2.16 and its service interface is specified in TS 29.531. It performs two critical functions: determining the Allowed NSSAI for a UE based on subscription, policy, and network availability, and triggering AMF reallocation when the initial AMF cannot serve the required slices.

NSSF Interaction Table

The NSSF interacts with several NFs during slice selection. The table below documents every interaction.

3GPP Reference: TS 29.531 defines the Nnssf_NSSelection service. TS 29.531 Section 6.1 specifies the service operations.

Understanding NSSAI Types

One of the most confusing aspects of 5G slicing is the multiple NSSAI variants. The table below clarifies each type, its source, and its role in slice selection.

Relationship flow: The UE sends Requested NSSAI (derived from Configured NSSAI) -> AMF checks against Subscribed S-NSSAI via UDM -> AMF queries NSSF -> NSSF returns Allowed NSSAI and Rejected S-NSSAI -> AMF delivers Allowed NSSAI to UE in Registration Accept.

Slice Selection Decision Flow

The following step-by-step procedure covers the NSSF-involved slice selection during UE registration per TS 23.502 Section 4.2.2.2.3.

Step 1 -- UE sends Registration Request:

The UE includes Requested NSSAI containing one or more S-NSSAI values. Each S-NSSAI has an SST (Slice/Service Type, 1 byte) and optionally an SD (Slice Differentiator, 3 bytes). For example: {SST=1, SD=0x000001} for eMBB with a specific tenant differentiator.

Step 2 -- Initial AMF receives request:

The gNB selects an initial AMF based on NSSAI information in the RRC setup (if available) or uses a default AMF. This initial AMF may not serve all requested slices.

Step 3 -- AMF queries NSSF:

The AMF invokes Nnssf_NSSelection_Get with:

• Requested NSSAI from the UE
• Subscribed S-NSSAI from UDM
• TAI (Tracking Area Identity) of the serving cell
• PLMN ID (for roaming scenarios)
• Slice info for Registration Type (initial vs mobility)

Step 4 -- NSSF evaluates:

The NSSF performs the following checks:

1. Validates Requested NSSAI against Subscribed S-NSSAI (subscription check)
2. Checks NSSAI availability in the current TAI (network availability)
3. Determines which S-NSSAIs the current AMF can serve
4. Identifies S-NSSAIs requiring a different AMF set

Step 5 -- NSSF returns result:

The response contains:

• Allowed NSSAI: S-NSSAIs the UE may use
• Rejected S-NSSAI list with cause values (e.g., not subscribed, not available in TA)
• Target AMF Set / AMF candidate list (if AMF reallocation needed)
• Mapping of S-NSSAI (for roaming)

Step 6 -- AMF reallocation (if needed):

If the NSSF indicates the current AMF cannot serve all Allowed NSSAIs, the AMF initiates reallocation to a target AMF in the correct AMF set. This involves N14 (AMF-to-AMF) context transfer.

AMF Reallocation Procedure

AMF reallocation occurs when the initial AMF (selected by gNB based on limited information) cannot serve all the slices the UE needs. This is defined in TS 23.502 Section 4.2.2.2.3.

Operator data -- SK Telecom: In their 2024 network slicing deployment report, SK Telecom documented that AMF reallocation occurred for approximately 3.2% of initial registrations in their multi-slice environment (eMBB + enterprise slices). The median reallocation latency added 45 ms to the registration procedure. To minimize this, they pre-configured gNBs with NSSAI-to-AMF mapping hints, reducing the reallocation rate to 0.8%. Operator data -- NTT DOCOMO: NTT DOCOMO reported in their 2024 slicing architecture paper that they deploy dedicated AMF sets per major slice group: AMF-Set-A for consumer eMBB (SST=1), AMF-Set-B for enterprise (SST=1 + specific SD), and AMF-Set-C for URLLC (SST=2). This AMF set partitioning aligns with the NSSF configuration to minimize reallocation events.

Worked Example -- Enterprise Slice Selection

Scenario: A manufacturing company (ACME Corp) has a private enterprise slice on Operator X's 5G SA network. The slice is identified as S-NSSAI = {SST=1, SD=0x00ACME} (SD = 0x00AC4E in hex). UE Configuration:

• Configured NSSAI in USIM: [{SST=1}, {SST=1, SD=0x00AC4E}]
• The first S-NSSAI is for general consumer eMBB
• The second is the ACME enterprise slice

Registration at ACME factory site (TAI = 0x0001):

1. UE sends Requested NSSAI = [{SST=1}, {SST=1, SD=0x00AC4E}]
2. gNB selects AMF-1 (default AMF set)
3. AMF-1 retrieves Subscribed S-NSSAI from UDM: [{SST=1}, {SST=1, SD=0x00AC4E}] -- both subscribed
4. AMF-1 queries NSSF:

- Requested: [{SST=1}, {SST=1, SD=0x00AC4E}]

- TAI: 0x0001 (factory area)

- Current AMF set: Set-A (consumer)

1. NSSF checks:

- SST=1: available in TAI 0x0001, AMF-1 can serve -> Allowed

- SST=1, SD=0x00AC4E: available in TAI 0x0001, but requires AMF-Set-B (enterprise)

1. NSSF response:

- Allowed NSSAI: [{SST=1}, {SST=1, SD=0x00AC4E}]

- Target AMF set: AMF-Set-B (can serve both consumer and enterprise)

1. AMF-1 queries NRF for AMF in Set-B serving TAI 0x0001
2. NRF returns AMF-2 (enterprise-capable AMF)
3. AMF-1 redirects to AMF-2 via N14
4. AMF-2 completes registration, UE receives Allowed NSSAI with both slices

PDU Session for factory application:

• UE requests PDU session: DNN = "acme-factory", S-NSSAI = {SST=1, SD=0x00AC4E}
• AMF-2 selects SMF serving the enterprise slice
• SMF selects UPF-Edge at factory site
• Traffic is isolated in the enterprise slice end-to-end

Worked Example -- Roaming Slice Mapping

Scenario: A subscriber from Operator A (home) roams to Operator B (visited). The home network slice SST=1, SD=0x000001 does not exist in the visited network. The NSSF must map it.

1. UE sends Requested NSSAI = [{SST=1, SD=0x000001}] to visited AMF
2. Visited AMF queries visited NSSF
3. Visited NSSF checks inter-PLMN agreement:

- Home S-NSSAI {SST=1, SD=0x000001} maps to Visited S-NSSAI {SST=1, SD=0x000099}

1. NSSF returns:

- Allowed NSSAI: [{SST=1, SD=0x000099}] (visited network S-NSSAI)

- Mapping: Home {SST=1, SD=0x000001} <-> Visited {SST=1, SD=0x000099}

1. The UE uses the visited S-NSSAI for PDU sessions in the roamed network
2. When the UE returns home, it reverts to the home S-NSSAI

This mapping is configured in the NSSF based on bilateral roaming agreements. 3GPP TS 23.501 Section 5.15.5.2 defines the NSSAI mapping procedures.

NSSF Configuration and Deployment Considerations

3GPP Reference: TS 23.501 Section 5.15 specifies the complete network slicing framework. TS 24.501 Section 9.11.3.37 defines the NSSAI information element encoding in NAS messages.

Summary

The NSSF is the decision engine that makes network slicing operational. It evaluates UE requests against subscription data, network availability, and AMF capabilities to determine which slices a UE can access. When the initial AMF cannot serve all needed slices, the NSSF triggers reallocation to the correct AMF set. For enterprise deployments, the NSSF is the gatekeeping function that ensures tenant isolation from the moment of registration.

Key Takeaway: Without the NSSF, network slicing is just a concept. The NSSF translates slice requests into concrete network resource assignments by determining Allowed NSSAI, triggering AMF reallocation, and handling roaming slice mapping. Every operator deploying network slicing must carefully configure NSSF policies, AMF set mappings, and per-TAI slice availability.