24 Networks that are not for everybody

24.1 Why a network would refuse the public

A factory, a hospital, a port and a mine all want the same thing: coverage inside their own walls that they control. Their machines must work when the public network is congested, their data should not leave the site, and nobody wants a consumer subscription for every robot arm.

3GPP's answer is the Non-Public Network — a 5G system deployed for non-public use. It comes in exactly two shapes §5.30.1:

• a Stand-alone Non-Public Network (SNPN), run by its own operator and not relying on any function provided by a public network; or

• a Public Network Integrated NPN (PNI-NPN), which is a private network built with the help of a public one.

An NPN and a public network may still share the radio equipment; that is network sharing §5.18, covered in Relays, satellites, femtos and shared networks.

24.2 The name a stand-alone network carries

An SNPN is identified by a PLMN ID together with a NID, the Network identifier §5.30.2.1. The PLMN ID is the same kind of number a public operator uses — see Every name the system uses — but here it is not required to be unique.

The mobile country code 999, assigned by the ITU, exists for exactly this purpose.

The NID comes from one of two assignment models:

• Self-assignment — the network picks its own at deployment time, from a separate numbering space. Two sites may end up with the same one.

• Coordinated assignment — either the NID alone is globally unique, or the NID and PLMN ID together are.

A second identifier, the GIN (Group ID for Network Selection), names a group of SNPNs rather than one, so a device can be told "any network carrying this group name will serve you". It has the same two assignment models.

An optional human-readable name exists purely so a person can pick from a list §5.30.2.1.

A cell that gives access to SNPNs broadcasts one or more PLMN IDs and the list of NIDs under each — twelve NIDs in total, on an NG-RAN node, which is the 5G radio network.

Optionally it adds the readable names, the supported GINs, whether outside credentials are accepted, and whether it will entertain devices never told to look for it §5.30.2.2.

24.3 How a device decides which one it may use

A device that supports this has an SNPN access mode. Switched on, it selects and registers with SNPNs and does no normal public-network selection at all; switched off, it ignores SNPNs entirely §5.30.2.4.1.

For each SNPN it subscribes to, it is configured with the PLMN ID and NID, a SUPI (the permanent subscriber identity the core uses inside) and credentials, optionally an N3IWF address, and the scheme used to conceal that SUPI.

If it can use somebody else's credentials, it also holds three ordered preference lists: one the user controls, and two the credentials holder controls — one of SNPNs and one of GINs §5.30.2.3.

Automatic selection works down a fixed order §5.30.2.4.2:

• the SNPN it was last registered with, or an equivalent one;

• the subscribed SNPN, the one it holds a SUPI and credentials for;

• then, if it supports outside credentials, only networks broadcasting that they accept them: the user's list, the holder's SNPN list, the holder's GIN list, and last any network advertising that it accepts devices never configured for it.

Refusal is where the two NID models earn their keep. If a device registers in an SNPN with a self-assigned NID and has no subscription there, the AMF rejects it with a cause that stops it picking that network again temporarily.

With a coordinated NID the bar is permanent — the identifier is unique, so the answer will not change somewhere else §5.30.2.5.

In this mode the device only camps on cells broadcasting both the PLMN ID and the NID of the selected SNPN or one of its equivalents §5.30.2.6. Moving between two SNPNs is a fresh registration, not a handover; only within a list of equivalent SNPNs can it move without selecting again §5.30.2.11.

Several familiar features are simply absent from an SNPN: interworking with 4G (Living next to 4G), roaming, handover to or from a public network, the small-device optimisations of Small devices, small messages, and Closed Access Groups §5.30.2.0.

24.4 Credentials that belong to somebody else

A machine builder wants its devices to work in every customer's private network without a separate subscription per site.

So an SNPN may authenticate a device against a Credentials Holder outside itself; the sessions still terminate in the SNPN's own SMF, the function that sets up a session and steers its traffic §5.30.2.9.1. Two arrangements exist:

• The holder runs an AAA server — an ordinary authentication server. The SNPN's UDM decides from the subscriber identity that this is the case, the AUSF hands the EAP exchange to the NSSAAF (the function that relays authentication to outside servers), and the AAA server acts as the EAP server.

  Only name-based identities work here §5.30.2.9.2.

• The holder runs its own AUSF and UDM, and may itself be an SNPN or a public operator. Its UDM supplies the subscription data to the SNPN, and network slicing — including per-slice authentication — can be carried over too §5.30.2.9.3.

24.5 A device that arrives with no credentials at all

A brand-new sensor out of its box has no subscription for the network it is about to join. Onboarding solves that: the device joins an Onboarding Network for the sole purpose of being given the credentials of the network it actually wants, the SO-SNPN §5.30.2.10.1.

The names in that picture:

Short name	What it is
ON-SNPN	the network that lets the device in to be provisioned
SO-SNPN	the network the device is being provisioned for
DCS	the server holding the device's factory-fitted default credentials
PVS	the provisioning server that hands over the real credentials

The device holds Default UE credentials and optionally hints about which onboarding networks to try. It registers with the registration type set to "SNPN Onboarding", offering an identity derived from those credentials, and sends no requested slice at all — it has not been told any §5.30.2.10.2.

The AMF treats that registration specially. It authenticates against the DCS (or a local AUSF when the DCS stays out of it), applies its own onboarding configuration to restrict what the device may do, and never touches a UDM.

The resulting session is restricted: the SMF may install rules in the UPF blocking anything not going to the provisioning server or a DNS server §5.30.2.10.4.

The device then talks to the PVS, gets its credentials, and should deregister. If it does not, a timer in the AMF throws it out §5.30.2.10.2.

24.6 The other shape: private inside public

A PNI-NPN is made available through a public network, usually as a dedicated data network name or one or more network slices, and the device must hold a subscription for that public network §5.30.3.1.

The slicing machinery is unchanged — see One network, many networks — and §D.2 lists what the two parties must agree: where the slice runs, that the subscription carries it, and that URSP rules (the rules in the phone that decide which connection an app's traffic uses) steer the device to it.

Slicing alone cannot stop a device from trying where it is not welcome, so Closed Access Groups (CAG) add access control at the cell. A CAG Identifier is unique within a PLMN ID; a CAG cell broadcasts up to twelve of them, plus an optional readable name §5.30.3.2.

The device's subscription carries an Allowed CAG list, optionally with time windows per entry, and optionally a flag saying the device may use CAG cells and nothing else. This lives in the Mobility Restrictions and is updated by the home network §5.30.3.3.

Checks happen in three places §5.30.3.4:

• The AMF, when the device goes from idle to connected: it refuses and releases the connection if the cell's identifiers are not in the list, or if the device is CAG-only and the cell is not a CAG cell.

• The NG-RAN, on an RRC Resume, on the same grounds using the list it received from the AMF — including when it received no list at all.

• The NG-RAN again, on handover: neither source nor target will move a device into a cell its list does not cover.

Emergency calls are the exception. They work in CAG cells whether the device is normally or emergency registered, and a device may camp on one in limited service state to make a call §5.30.3.5.

24.7 Using a private and a public network at once

A worker on a factory floor needs the factory network for the machines and the public network for a phone call. Both work at the same time, and the trick is the same in either direction: one network's user plane is used as if it were untrusted Wi-Fi.

The device registers normally with the first network, gets IP connectivity, finds an N3IWF (the gateway 5G uses for untrusted non-3GPP access — see Radio, Wi-Fi, cable — every way in) in the second, and registers again through the tunnel §5.30.2.7 §5.30.2.8.

The network being reached is the overlay, the one carrying the tunnel is the underlay §D.1.

Quality of service across that boundary is not automatic. The overlay's N3IWF puts each of its QoS flows (What the network promises) in a separate IPsec child security association and marks it with a DSCP value — the priority marking IP routers read.

The underlay detects the marking and the N3IWF address and raises a matching flow of its own. What each marking buys is a business agreement, not a protocol §5.30.2.7 §D.7.1.

A device holding both connections applies SNPN access mode per interface, so it can be in that mode on the radio and not on the tunnel. Which network it uses for what is left to the device §D.4.

24.8 Services that only exist here, and only now

A stadium wants to hand a video feed to whoever is inside, for the length of the match. That is a Localized Service: one provided in a limited area, or bounded in time, or both, offered over an SNPN or a PNI-NPN §N.1.

The mechanism is the preference lists from earlier, each entry carrying validity information — time periods, optionally locations — and optionally location assistance information saying where to look.

The credentials holder builds those lists from what the service provider tells it and pushes them out with the steering-of-roaming procedure §N.6.

Once registered, the device is pointed at the service by URSP rules, which can carry the same time and location criteria, and the service may be tied to a local data network §N.4.

The interesting problem is the end. When the match finishes, every device in the stadium moves elsewhere within minutes — a signalling storm at the far end.

The cures all spread it out: a different validity end time per device, set a little longer than the service runs, and an AMF that paces its deregistrations §N.5.

24.9 A private group of devices that talk to each other

Everything so far was about who may use a network. 5G LAN-type service is about who may talk to whom inside one: a 5G Virtual Network group is a set of devices using private communication among themselves §5.29.1.

A group is described by §5.29.2:

• Two identities. An External Group ID, which the application function outside uses, and an Internal Group ID that the UDM maps it to.

• Membership, by GPSI — the outward-facing identity of each device.

• Group data: session type, DNN, S-NSSAI (the identifier of one network slice), application descriptor, secondary authentication details, a maximum data rate for the whole group, and a user plane security policy.

Groups are set up by administration or managed live by an application function through the NEF — see Computing close by, and opening the door. The DNN, the S-NSSAI and the security policy cannot be changed after the group is created.

A device reaches the group through one IP or Ethernet PDU session, and one DNN and S-NSSAI combination maps to one group and nothing else.

There is no group-specific authentication: authenticating for the DNN and slice is authenticating for the group §5.29.3.

Traffic between members is switched in one of three ways §5.29.4:

• Local switch — one UPF anchors several sessions of the same group and forwards between them itself. The SMF prefers this and tries to put as many sessions as possible on one anchor.

• N19 — a shared tunnel between the anchor UPFs of one group, used when the sessions land on different anchors.

• N6 — out to the data network and back, the ordinary path.

The anchor decides unicast, broadcast or multicast from each packet's destination address §5.29.3. Where the packets actually go covers what a UPF anchor is; §5.8.2.13 is the user plane view of the same feature.

24.10 The network in your pocket

The last shape is the smallest. A Personal IoT Network (PIN) is the watch, earbuds and sensors around one person, given a way to reach the 5G network and each other §5.44.1.

Three roles, and only one of them is special to 5G:

• PINE — a device in the network. It may be a UE or a plain non-3GPP device.

• PEGC — the gateway. It is a UE, it holds PIN subscription data (a dedicated DNN and S-NSSAI per PIN), and it registers with the network. All indirect and PIN-to-data-network traffic passes through it, management traffic included.

• PEMC — the management element. It has no PIN subscription data at all and behaves as an ordinary UE when it is a 3GPP device; it may also be a plain non-3GPP one.

Devices talk three ways: direct between PINEs, which 3GPP does not specify; indirect, through the gateway; and PIN-DN, through the gateway out to a data network §5.44.1. An application function for PIN may sit outside and reach the core through the NEF.

Inside 5G the PIN ID appears in exactly one place: as a traffic descriptor in a URSP rule sent to the gateway, so it knows which session that PIN's traffic belongs on §5.44.2 §5.44.4.

One PIN is served by one session in the gateway; one session may carry several PINs when they need not be kept apart §5.44.3.1.

When a PIN has several gateways they are grouped using the 5G VN group machinery of the previous section, with a dedicated SMF set — but with one difference: N19 forwarding is not used for PIN. Traffic goes out over N6 or is locally switched by the UPF §P.2.

Two pieces recognise that half the path is not 3GPP's. N3QAI tells the gateway what quality each flow expects, so it can reserve what it needs on the Wi-Fi or Bluetooth behind it §5.44.3.3.

And the gateway may report the delay on that hop, which the SMF folds into the delay budget it signals to the radio network §5.44.3.4.