6 One network behaving like several

6.1 Why one network has to behave like several

An operator sells one thing to a phone company, another to a factory, another to a fleet of parking sensors. The three want different delays, different reliability, different amounts of the network, and one of them wants its own authentication on top of the operator's.

Network slicing is how one physical network delivers all three without three physical networks. A slice instance is a set of core control plane and user plane functions, plus at least one access network to reach them §5.15.1.

Slices may differ in the features they support, or be identical in features and differ only in who they are for — the same service type, a different customer §5.15.1.

6.2 Naming a slice

A slice is identified by an S-NSSAI, and an S-NSSAI is two fields §5.15.2.1:

• SST, the slice/service type: what kind of behaviour is expected.

• SD, the slice differentiator: optional, and there to tell apart several slices of the same type.

Seven SST values are standardised, so roaming can work without a private agreement about names: enhanced mobile broadband, ultra-reliable low latency, massive IoT, vehicle-to-everything, high-performance machine type, high data rate and low latency, and guaranteed bit rate streaming §5.15.2.2.

No network has to support all seven, and the same service can be carried on a different SST §5.15.2.2.

A collection of S-NSSAIs is an NSSAI, and which collection it is matters §5.15.2.1:

Name	What it holds
Configured NSSAI	what the device has been given for a network
Requested NSSAI	what the device asks for at registration
Allowed NSSAI	what the network grants for this registration

At most eight S-NSSAIs travel in a Requested or Allowed NSSAI. The subscription may hold more — the UDM sends the AMF at most sixteen Subscribed S-NSSAIs, of which at least one is marked default §5.15.2.1 §5.15.3.

6.3 How a device ends up on the right slices

The device sends its Requested NSSAI at registration. The first AMF it reaches usually asks the NSSF — the function that picks slices — which slices should serve it, and that answer can send the registration to a different AMF §5.15.1.

The network checks the request against the subscription. If the device asked for nothing usable, the slice marked default is what it gets §5.15.3. The registration that carries all this is Knowing who you are and where you are.

One thing surprises people: the AMF is common. Whatever the number of slices serving a device, the AMF instance serving it logically belongs to each of them §5.15.1. Slicing splits the session side of the core, not the mobility side.

Some slices need their own authentication on top of the operator's. That is NSSAA — Network Slice-Specific Authentication and Authorization — driven by the subscription, and a device that does not support it simply has those slices rejected §5.15.10.

6.4 Keeping a slice from being swamped

Two mechanisms are worth knowing by name.

NSAC — Network Slice Admission Control — is a function configured with the maximum number of registered devices and the maximum number of sessions allowed per slice, and it monitors and controls both §5.15.11.0.

UE-Slice-MBR is a rate limit per device per slice, held in the subscription and passed by the AMF to the radio network together with the Allowed NSSAI §5.15.13.

6.5 The rules, and who pays

Policy is among the two dozen shortest clauses in the document and one of the most important to place correctly. It is a single sentence, and it says the framework for 5G policy and charging control is defined in TS 23.503 §5.14.

This document says who holds policy — the PCF — and who enforces it. What a rule contains is next door.

Charging is nearly as short. The core reports resource usage to a CHF, with the SMF, the AMF, the SMSF and the NEF each having their own charging document, and the UPF collecting the usage the SMF asks it for over N4 §5.12.1.

That division is the pattern of the whole specification, and worth getting used to: TS 23.501 names the responsibility and the interface, and hands the content to whichever document owns it.

6.6 What this document settles about security

The security clause is short, because the security architecture is TS 33.501. What it does list is what the system has to provide §5.10.1:

• mutual authentication between the device and the network;

• generating and distributing the security context;

• confidentiality and integrity, for user data and for signalling;

• hiding the user's identity;

• support for lawful interception.

The identity hiding is the one visible in every trace: the permanent subscriber identity travels concealed, and the UDM is what un-conceals it.

The piece that this document does settle in detail is what a session's user plane protection has to be. The SMF works out a User Plane Security Enforcement setting at establishment, from the subscription and from local configuration, and gives it to the radio network §5.10.3.

It has two switches, integrity and confidentiality, each with three values:

• Required — it shall apply to all the traffic on the session.

• Preferred — it should apply.

• Not Needed — it shall not apply.

Once decided at establishment, it holds for the life of the session, and it applies over 3GPP access only §5.10.3.

6.7 Where to look next

Slicing in full — configuration, selection, roaming, admission control, replacement — is §5.15. Charging is §5.12 and policy is the one sentence at §5.14. Security aspects are §5.10, and the user plane enforcement detail is §5.10.3.

The in-depth course of this track has a chapter on slicing and one on policy and charging, and says clause by clause what this document settles about security and what it does not.