HiCellTek HiCellTek
← Home

What This Page Covers

NSSAI validation confirms that a private 5G deployment correctly grants slices to authorized devices and enforces isolation between slices. It requires decoding 5GS NAS messages — specifically Registration Request/Accept (NSSAI grant) and PDU Session Establishment Request/Reject (DNN-slice binding) — and verifying the results against the UDM subscription configuration.

Private 5G: NSSAI Slicing Validation

Network slicing is the defining feature of 5G SA. In a private 5G deployment — whether a factory floor, campus, or port — the promise of slicing (dedicated performance for specific devices and applications) must be verified before acceptance. NSSAI validation is the structured test that confirms the 5G core is correctly enforcing your slice architecture.

What can go wrong without validation
  • Enterprise automation devices share bandwidth with general-purpose eMBB traffic
  • URLLC slice is not granted — cause #62 "No network slices available"
  • DNN provisioned for wrong slice — cause #72 on every PDU session attempt
  • Non-enterprise devices can access the automation slice (no isolation)
  • Slice priority is configured but not enforced under load
What NSSAI validation confirms
  • Allowed NSSAI in Registration Accept matches the device's subscription
  • DNN-to-slice binding in UDM is correctly configured for each subscriber group
  • Unauthorized devices receive correct rejection cause codes
  • PDU sessions are established on the correct slice with expected 5QI
  • Slice isolation is enforced at the UDM level under all test conditions

NSSAI Negotiation: Layer by Layer

The slice a device ultimately uses is negotiated across four NSSAI parameters. Validation must verify each layer independently.

NSSAI Type Direction NAS Message What to Verify
Requested NSSAI UE → AMF Registration Request Device is requesting the correct S-NSSAIs (SST + SD match device config)
Allowed NSSAI AMF → UE Registration Accept 5GC granted all subscribed slices; unauthorized slices are absent
S-NSSAI in PDU Req. UE → SMF PDU Session Est. Request Device requests PDU session on the granted slice with correct DNN
Accepted S-NSSAI SMF → UE PDU Session Est. Accept Session confirmed on the correct slice; 5QI matches slice SLA

NSSAI Validation Test Procedure

T1
Positive Registration Test — Enterprise Device

Insert a USIM provisioned for the enterprise slice (e.g., URLLC SST=2, SD=0x000001). Verify: (1) Registration Request includes Requested NSSAI with SST=2 and correct SD, (2) Registration Accept includes Allowed NSSAI with SST=2, (3) PDU Session Establishment succeeds with S-NSSAI SST=2 and enterprise DNN. All three confirmations are required for a passing T1.

T2
Negative Isolation Test — Non-Enterprise Device

Insert a USIM provisioned for eMBB only (SST=1). Attempt a PDU Session Establishment with S-NSSAI SST=2 (URLLC). Expected result: PDU Session Establishment Reject with 5GSM cause #72 (DNN not supported or not subscribed in the slice), or the Requested NSSAI SST=2 is absent from the Allowed NSSAI in the Registration Accept (cause #62 per S-NSSAI). Either confirms slice isolation is enforced.

T3
DNN Binding Verification

With the enterprise USIM, attempt PDU Session Establishment with the correct S-NSSAI (SST=2) but an incorrect DNN (e.g., "internet" instead of "factory.local"). Expected result: PDU Session Establishment Reject with cause #72. Then retry with the correct DNN and confirm PDU Session Establishment Accept. This isolates the DNN-to-slice binding in the UDM.

T4
5QI Verification on Accepted Session

After PDU Session Establishment Accept, decode the QoS rules IE in the accept message. Confirm the 5QI assigned to the default QoS flow matches the slice SLA: URLLC flows should carry 5QI 80–85 (delay budget 5–10 ms), not 5QI 9 (eMBB best-effort). A wrong 5QI confirms a QoS misconfiguration at the SMF despite correct slice granting.

T5
Slice Re-registration After Coverage Loss

Simulate a coverage interruption (move device out of coverage, then return). After re-registration, confirm: (1) the Allowed NSSAI is correctly restored in the new Registration Accept, (2) a new PDU Session Establishment succeeds on the enterprise slice without manual intervention. This validates the slice state machine under mobility conditions.

5QI Reference for Private 5G Slices

Source: 3GPP TS 23.501 §5.7.4, Table 5.7.4-1

5QI Resource Type Packet Delay Budget Typical Use in Private 5G
5 GBR 100 ms IMS signaling (VoNR registration bearer)
9 Non-GBR 300 ms Default eMBB internet PDU session
80 Non-GBR 10 ms Automation, URLLC control channel
82 GBR 10 ms Discrete automation (IEC 61850, PROFINET over 5G)
83 GBR 10 ms Electricity distribution (power grid telemetry)

How HiCellTek Validates NSSAI in the Field

5GS NAS Decoder — Real-Time NSSAI

Decode Registration Request, Registration Accept, PDU Session Establishment Request, and PDU Session Establishment Accept/Reject in real time. Display Requested NSSAI vs. Allowed NSSAI side by side. Flag any S-NSSAI present in the request but absent from the Accept.

5GSM Cause Decoder

When a PDU Session Establishment Reject is received, display the 5GSM cause IE with its decimal value, hex value, and human-readable name. Cause #72 (DNN not in slice) and cause #67 (insufficient resources) are the most common in private 5G acceptance scenarios.

QoS Flow Verification

After PDU Session Establishment Accept, decode the QoS Rules IE and Mapped EPS Bearer Contexts to extract the 5QI of each QoS flow. Verify against the slice SLA: a URLLC session receiving 5QI 9 (best-effort) instead of 5QI 80 (low-latency) is a misconfiguration that NSSAI validation alone would not catch.

Test Report Export

Export the complete NSSAI validation test log as QMDL or CSV with timestamps, NAS message decoded content, and pass/fail status for each test case. Provides the structured evidence required for private 5G acceptance sign-off.

Frequently Asked Questions

What is NSSAI validation in a private 5G network?

NSSAI (Network Slice Selection Assistance Information) validation confirms that the 5G core network is correctly granting the requested network slices to authorized UEs, and rejecting unauthorized requests with the appropriate 5GMM cause code. In a private 5G deployment, NSSAI validation verifies that enterprise devices receive the Allowed NSSAI matching their subscription, that dedicated slices (e.g., URLLC SST=2 for automation) are available only to provisioned devices, and that the DNN-to-slice binding in the UDM matches the device configuration.

Which 5GS NAS messages are decoded during NSSAI validation?

NSSAI validation requires decoding: (1) Registration Request — read the Requested NSSAI to confirm what slices the device is requesting, (2) Registration Accept — read the Allowed NSSAI to confirm which slices the 5GC granted, (3) PDU Session Establishment Request — verify the S-NSSAI and DNN parameters, (4) PDU Session Establishment Accept or Reject — confirm the session is established or identify the 5GSM cause code (#72 for DNN mismatch, #67 for resource exhaustion). All four messages are captured via DIAG log code 0xB821.

How do you test slice isolation in a private 5G deployment?

Slice isolation testing verifies that a device provisioned for slice A (e.g., eMBB SST=1) cannot access slice B (e.g., URLLC SST=2). The test procedure: (1) Insert a SIM provisioned for eMBB only, (2) Attempt a PDU Session Establishment Request with S-NSSAI SST=2, (3) Verify the 5GC returns a PDU Session Establishment Reject with 5GSM cause #72 (DNN not supported or not subscribed in the slice). A rejected session confirms slice isolation is enforced at the UDM subscription level.

What is the typical NSSAI validation test sequence for private 5G acceptance?

A complete NSSAI validation for private 5G acceptance covers: (1) Positive test — enterprise device with correct NSSAI provisions receives Registration Accept with matching Allowed NSSAI, (2) Negative test — non-enterprise device receives Registration Accept with default eMBB slice only or Registration Reject cause #62 if no slice is granted, (3) DNN binding test — confirm PDU Session Establishment succeeds for the enterprise DNN on the enterprise slice and fails with cause #72 for an unauthorized DNN, (4) Slice failover — verify UE behavior when the primary slice is temporarily unavailable.