What the system does · chapter 17 of 27 · 15 minutes
17 One network, many networks
How one physical 5G network is cut into named slices, how a device asks for the ones it wants, and what the network does when it asks for one it may not have.
Built from §5.15
17.1 Why one network has to look like several
An operator owns one radio network and one core. It has to serve a phone streaming video, a factory arm that must never see a late packet, and a million water meters that wake up once a day.
Those three want different things from the same equipment — different priorities, different functions, different behaviour under load, and often a different customer paying the bill.
A network slice is the answer, and it comes in two halves. The working set of machinery is a Network Slice instance: core control-plane and user-plane functions plus at least one way in — the radio network, or one of the gateways for Wi-Fi, trusted wireless or cable §5.15.1.
The name is the S-NSSAI, and the two are not tied one to one. An instance may carry several S-NSSAIs, and one S-NSSAI may have several instances behind it, in the same tracking area or in different ones §5.15.2.1.
Two slices may differ because they support different features. They may also be identical in features and exist only to keep two groups of devices apart, for instance one slice per business customer §5.15.1.
17.2 The name of a slice
A slice is identified by an S-NSSAI. It has two parts §5.15.2.1:
-
The SST, the Slice/Service type, saying what kind of behaviour is expected.
-
The SD, the Slice Differentiator, optional, telling apart several slices that share one SST.
An S-NSSAI has a standard value when it is an SST from the standardised list and nothing else. Anything else — SST plus SD, or a non-standardised SST alone — is a non-standard value, and it means something only inside the one network it belongs to §5.15.2.1.
Seven SST values are standardised §5.15.2.2:
| SST | Name | Meant for |
|---|---|---|
| 1 | eMBB | Enhanced mobile broadband |
| 2 | URLLC | Ultra-reliable low latency |
| 3 | MIoT | Massive numbers of small devices |
| 4 | V2X | Vehicle communication |
| 5 | HMTC | High-performance machine communication |
| 6 | HDLLC | High data rate and low latency |
| 7 | GBRSS | Guaranteed bit rate streaming |
An NSSAI is simply a list of S-NSSAIs. Which list, and who wrote it, is the whole of the next section.
17.3 Four lists, and where each one comes from
| List | Written by | What it means |
|---|---|---|
| Configured NSSAI | the serving network, or the home network as a default | the slices this device may ask for in this network |
| Requested NSSAI | the device | the slices it wants right now |
| Allowed NSSAI | the serving network | the slices it may actually use here and now |
| Rejected S-NSSAIs | the serving network | what it may not have, and for how long |
There is at most one Configured NSSAI per network. A device may also hold a Default Configured NSSAI from its home network, used only where it has no Configured NSSAI for the network it is standing in §5.15.4.1.1.
Behind these sits the subscription. The UDM (the subscriber database) sends at most sixteen Subscribed S-NSSAIs to the AMF (the function that keeps track of where a device is and whether it is reachable), and at least one of them must be marked as default §5.15.3.
At most eight S-NSSAIs fit in the Allowed NSSAI or the Requested NSSAI on the wire. That number, not the subscription, is the real ceiling on how many slices a device uses at once §5.15.2.1.
Two more lists appear later: the Pending NSSAI, for slices whose own authentication is still running, and the Partially Allowed NSSAI, for slices that hold in only part of the area the device is registered in.
The Requested NSSAI is drawn from the Configured NSSAI, the Allowed NSSAI, or both. A device must never put in a slice the network has currently rejected, nor one sitting in its Pending NSSAI §5.15.5.2.1.
17.4 Registering: what the AMF and the NSSF do between them
The device puts the Requested NSSAI in the registration message §5.15.5.2.1. Whether it also goes to the radio network is the network's choice, and on 3GPP access the default is not to send it there at all — it travels that way only in one of the access-stratum modes of §5.15.9.
Where the radio network does get the list, it uses it to pick the AMF. If it cannot pick one from the list, or was never given one, the request goes to a default AMF, which then sorts it out.
From there the specification lays out three steps, and it labels them itself:
-
(A) The AMF may decide alone, if it is configured to. It checks the requested slices against the subscription, checks they are available in the device's current tracking area, and if it can serve them all it stays the serving AMF.
-
(B) Otherwise it asks the NSSF (the function that picks slices). The AMF hands over the Requested NSSAI, the mapping to home-network values, the subscribed slices, any Allowed NSSAI for the other access, and the device's tracking area.
-
(C) The serving AMF works out a Registration Area in which every slice of the Allowed NSSAI is available in every tracking area, and returns that Allowed NSSAI to the device.
The NSSF does more than filter. It picks which slice instance serves the device, and decides the target AMF Set or a list of candidate AMFs.
It may also return NSI IDs (the identifier of one particular slice instance) and the NRFs to use for finding functions inside the slice, and it may hand back a Configured NSSAI to reconfigure the device §5.15.5.2.1.
If the answer names a different AMF, the first AMF reroutes the registration — through the radio network, or straight to the target AMF. When the NSSF returned candidate AMFs rather than a set, only the direct path is allowed §5.15.5.2.3.
17.5 Asking for a slice you may not have
This is the case worth being able to explain. Four different things can happen, and only one of them is a plain refusal.
-
Quietly dropped. A requested slice that comes back neither allowed nor rejected is not refused. The device may ask for it again next time §5.15.4.1.1.
-
Rejected, with a scope. The network returns the S-NSSAI with a cause and one of three lifetimes: rejected for the whole network, rejected for the current Registration Area, or rejected partially in the Registration Area with the list of tracking areas where it does not hold §5.15.4.1.1.
-
Replaced by the defaults. If none of the requested slices are permitted, the AMF or NSSF builds the Allowed NSSAI from the subscribed slices marked as default instead §5.15.5.2.1.
-
Registration refused. Only when no slice at all can be given and no default could be added does the AMF reject the registration, listing every rejected S-NSSAI with its cause §5.15.5.2.1.
While it stays registered, the device must not re-ask for a rejected slice until the rejection lapses — until it is deleted, until the device leaves the Registration Area, or until it enters a tracking area outside the listed ones §5.15.4.1.1.
17.6 Tying a session to a slice
A PDU session (the connection to a data network, see The connection to a data network) belongs to exactly one slice per network. Two slices never share one, though both may run sessions to the same data network name §5.15.1.
The device picks the S-NSSAI for a new session from its Allowed NSSAI, guided by the slice selection policy inside its URSP rules, which map applications to home-network slice values §5.15.5.3.
The AMF then queries an NRF to find an SMF (the function that runs sessions) using the S-NSSAI, the data network name and, if it has one, the NSI ID — the pattern described in How one function finds another.
Once the session exists, the core tells the radio network which S-NSSAI it belongs to, so radio resources can be handled per slice §5.15.5.3. A session may not be moved to another access type unless its S-NSSAI is in the Allowed NSSAI of that access §5.15.5.3.
17.7 Slices that are not everywhere, and not always
Support is defined per tracking area. A slice is supported in a tracking area when the access network there is configured for the S-NSSAI, and counted as available only when it is available in every cell of that area §5.15.8.
Where a slice's Area of Service does not line up with tracking-area borders, the operator either redraws the areas or configures zero resources in the cells that are meant to be outside it §5.15.18.1.
The AMF learns what each tracking area supports when access nodes set up their N2 connection (the link between a radio node and the core), and one or all of the AMFs in a set keep the NSSF updated §5.15.8.
Rather than shrink the Registration Area to fit, the AMF may put such a slice in the Partially Allowed NSSAI, with the list of tracking areas where it works.
The device stays registered for that slice across the whole area, but may only start a session, or activate user-plane resources, inside that list §5.15.17.
Time works the same way. A slice can carry a validity time — for an event, a periodic activation, or a planned shutdown. When it lapses, the device drops it from its Allowed NSSAI and locally releases its sessions; if it will never come back, it drops it from the Configured NSSAI too §5.15.16.
17.8 Which slices may be used together
Eight is the wire limit, but a subscription can narrow it further. Each subscribed S-NSSAI may carry NSSRG information — a group tag — and every slice in one Allowed NSSAI must share at least one group §5.15.12.1.
All the default slices carry the same groups, so a device can always hold them together. A device that understands the feature is given the group tags with its Configured NSSAI and filters its own requests; one that does not is simply given a shorter Configured NSSAI §5.15.12.2.
A subscription may also cap throughput per slice, a UE-Slice-MBR the AMF passes to the radio network alongside the Allowed NSSAI, on 3GPP access only. The radio network enforces it, as described in What the network promises §5.15.13.
17.9 Proving you may use a slice
Some slices need a second authentication of their own, beyond the one that proved the subscriber's identity.
This is NSSAA, and it runs against a Network Slice-Specific AAA server using EAP (a carrier that can hold many different authentication methods) §5.15.10.
The device says in its registration whether it supports the feature. If it does not, slices needing NSSAA are rejected for that network outright §5.15.10.
If every requested slice is pending, the registration is accepted with an "NSSAA to be performed" indicator and no Allowed NSSAI. The device is registered but must wait, using nothing except emergency services, until an Allowed NSSAI arrives §5.15.5.2.1.
The result is remembered while the device stays registered, so it is not repeated at every mobility update. The AAA server may revoke it later, at which point the AMF hands out a new Allowed NSSAI and releases the sessions on that slice §5.15.10.
17.10 Counting devices and counting sessions
A slice can be sold with a headcount. The NSACF (the function that counts how many devices and sessions a slice already carries) holds, per S-NSSAI, a maximum number of registered devices and a maximum number of PDU sessions, plus which access types they apply to §5.15.11.0.
The AMF asks about devices, whenever a registration status changes; the anchor SMF asks about sessions, at establishment and release. The NSACF keeps the list of device identities so a second registration is not counted twice §5.15.11.1.1 §5.15.11.2.1.
Refusing a session may come with a back-off timer and the cause "Maximum number of PDU Sessions per S-NSSAI reached". A device that gets one must not retry on that access until it expires §5.15.11.0.
Emergency and priority traffic may be exempted: the AMF and SMF either ignore the answer or skip the check, in which case the device is not counted at all §5.15.11.0.
Three deployment shapes exist for more than one service area — independent NSACFs per area, one central NSACF for the whole network, or a hierarchy where a primary NSACF hands out quota to the others §5.15.11.0.
17.11 Roaming
Standard S-NSSAI values carry across unchanged. Non-standard ones do not: the visited network's NSSF maps subscribed home values onto its own, according to the agreement between the two operators, and does not tell the home network which values it chose §5.15.6.
The visited NSSF works out the Allowed NSSAI without contacting the home network at all. What the device gets back is visited-network values, plus the mapping to its home values so its URSP rules still match §5.15.6.
At session establishment the device sends both: the home value its application policy named, and the visited value from the Allowed NSSAI that maps to it §5.15.6.
Headcounts also need an agreement. One of three modes applies: the visited network admits alone, it admits with quota fetched from the home network, or the home network admits §5.15.11.3.0 §5.15.11.3.2.
The visited AMF and SMF learn which mode applies from subscription data. The wider roaming picture is in Being served by somebody else's network.
17.12 When a slice goes away
If a slice becomes congested or unavailable, the network can move devices onto an Alternative S-NSSAI for the time being.
The trigger comes from the NSSF, the PCF (the function that hands out the network's policy rules) or the management system, and it is recommended to configure only one of the three §5.15.19.
The device is told the mapping from the old S-NSSAI to the alternative one and associates both with the session. Application matching and session establishment stay on the original value — the alternative is carried alongside it §5.15.19.
The SMF works the same way round: it fetches subscription data and registers the session under the replaced S-NSSAI, but hands the Alternative S-NSSAI to the radio network, the user plane and the device §5.15.19.
When the original comes back, the AMF reverses the mapping and the sessions are either kept on the same anchor or torn down for re-establishment, depending on the session continuity mode §5.15.19.
17.13 Where this meets the rest of the system
Slice names are one of the identifier families in Every name the system uses, and the registration procedure that carries them is in Registration, reachability and paging.
The rules that map an application to a slice live in URSP, described in Rules, and paying for them. The extra authentication in this chapter sits beside the subscriber authentication in Who you are and who may listen.
One last privacy control belongs here: the network decides whether the device may name slices in the radio-level connection setup at all. There are four modes, and on 3GPP access the default is the silent one — no NSSAI in the access stratum unless the home network says it is allowed §5.15.9.
Check yourself
Answers appear when you pick one, with where they come from.
Q17.1 How many S-NSSAIs may the Allowed NSSAI carry in signalling between the device and the network?
At most eight in the Allowed NSSAI and in the Requested NSSAI. The UDM sends the AMF up to sixteen, but only eight fit in the messages. §5.15.2.1
Q17.2 What is the Slice Differentiator, the SD part of an S-NSSAI, for?
The SD is optional extra information that separates several slices of the same SST — for example one per business customer. §5.15.2.1
Q17.3 A device asks for slices, none of them are in its subscription, and it has default subscribed slices. What does the network do?
When no requested S-NSSAI is permitted, the AMF or NSSF builds the Allowed NSSAI from the S-NSSAIs marked as default in the subscription. §5.15.5.2.1
Q17.4 A slice needs its own authentication and it has not finished yet. Where does that S-NSSAI sit meanwhile?
S-NSSAIs under an ongoing slice-specific authentication go in the Pending NSSAI and are removed from the Allowed NSSAI; the device must not ask for them again while they are pending. §5.15.5.2.1
Q17.5 Who keeps the count of PDU sessions in a slice, and who asks it?
The NSACF holds the maximum per S-NSSAI and tracks the current number; the anchor SMF triggers the check at session establishment and release. §5.15.11.2.1
Q17.6 While a slice is replaced by an Alternative S-NSSAI, which value does the device use to match an application to a session?
Application-to-session matching by URSP and session establishment stay on the replaced S-NSSAI; the Alternative one is carried alongside it. §5.15.19
This chapter was written against TS 23.501 version 20.2.0, verified 2026-08-04. A newer version of the document may say something else.