6 Getting on the network, and getting a connection through it

6.1 Why registration is the hard part

Everything a network does for a subscriber depends on one earlier decision: whether this device is allowed on at all, and as whom. Get that wrong and either the network leaks service to somebody who has not paid, or a legitimate subscriber is stranded in a foreign country with a phone that will not connect.

Registration is where that decision is made, and it is the busiest procedure in the specification. It is also the only one whose direction is fixed:

The network never asks a device to register. It can ask it to re-register by de-registering it with the right indication §5.5.2.1, but the request itself always comes from the device.

6.2 The kinds of registration

The device says which kind it is doing in a field of the request, and there are four values for the initial case alone §5.5.1.2.1:

• "initial registration" — the ordinary one.

• "emergency registration" — for a device that needs to make an emergency call and may not be entitled to anything else.

• "SNPN onboarding registration" — for a device joining a stand-alone non-public network with no subscription yet, to fetch one.

• "disaster roaming initial registration" — for a device whose own network has failed and which is being taken in by another.

The second kind of registration, mobility and periodic update §5.5.1.3.1, covers two different jobs under one name: telling the network the device has moved somewhere new, and telling it nothing has changed but the device is still there.

Periodic registration is done over 3GPP access only §5.5.1.3.1. There is no periodic update over Wi-Fi, because that access does not have the same problem of a device silently vanishing.

6.3 The counter and the timers

A device that keeps being rejected must not keep asking, or a single misconfigured subscription becomes a signalling storm. The mechanism is a registration attempt counter, incremented on each failure §5.5.1.1.

What matters in practice is when it is reset, because that is what lets a device recover. The document resets it when the device is powered on, when a USIM is inserted, when a registration succeeds, when a new network is selected, and on a long list of specific rejection causes §5.5.1.1.

The timers around it are in clause 10, whose own opening warns that its tables are a brief summary and that clauses 4 to 6 are the definitive description §10.1. Four of them shape registration §10.2:

Timer	Value	What it does
T3510	15s, with other values in some modes	Guards a registration in flight
T3511	10s	Waits before retrying after a failure
T3502	Default 12 min	Spaces out attempts once the counter reaches 5
T3512	Default 54 min	Triggers the periodic registration update

Those values carry notes and alternatives in the document — over a satellite radio cell T3510 is 27 seconds rather than 15, and in WB-N1/CE mode it is 85 seconds §10.2. Never quote a timer value from a summary without checking the notes attached to its row.

6.4 What identity travels

A device has several identities and uses different ones at different moments.

The permanent one is the SUPI, and it is not sent in the clear. What travels is the SUCI, which the identification procedure calls a privacy preserving identifier containing the concealed SUPI §5.4.3.1.

The same clause lists the other things the network may ask for: the IMEI, the IMEISV, an EUI-64 or a MAC address, all of them formats of the equipment identifier.

Once a device is known, it gets a temporary identity instead: the 5G-GUTI. Its purpose is stated plainly — identity confidentiality, so that an intruder cannot identify or locate a user §5.3.3. A shortened form, the 5G-S-TMSI, is used in paging and service request, where radio efficiency matters.

The network is required to hand out a fresh one at specific moments: during a successful initial registration, during a successful mobility registration update, and after a service request that answered a page §5.3.3. Reassigning the temporary identity regularly is the whole point of having one.

6.5 The common procedures that hang off registration

Registration rarely happens alone. The network can start any of the common procedures in the middle of it, and two of them almost always run.

Primary authentication and key agreement proves the two sides are who they claim and produces the keys everything else uses §5.4.1.1. Two methods are defined — an EAP based one and a 5G AKA based one — and the device and the AMF shall both support both §5.4.1.1. Neither side may implement only one.

Security mode control takes a security context into use and starts the protection of NAS signalling with the agreed keys and algorithms §5.4.2.1. It is also the procedure used later to change algorithms on a context already in use.

Identification is the network asking for a specific identity when it cannot work out who it is talking to §5.4.3.1.

De-registration is the other end of the same story, and unlike registration it can be started from either side §5.5.2.1.

The device does it when it is switched off or when the USIM is removed; the network does it to tell a device it is no longer registered, or to tell it to register again. When it completes, the PDU sessions over the affected access are released locally §5.5.2.1.

6.6 Sessions: the second half of the document

Once registered, a device has permission but no connectivity. Getting that is session management, and its unit is the PDU session.

The document's own framing of what a session is contains the sentence that explains most of the design:

A session is an agreement, not a pipe. The pipe can be taken down while the device is idle and brought back later by a service request, and from the application's point of view nothing happened.

Five session types exist §6.2.2: IPv4, IPv6, IPv4v6, Ethernet and Unstructured. For the Ethernet type the core network allocates neither a MAC address nor an IP address to the device.

6.7 The six session procedures

The session management clause names exactly six ways a session can change §6.2.3, and most of them come in pairs — one version the device asks for, one the network imposes:

Started by the device	Started by the network
PDU session establishment §6.4.1.1	PDU session authentication and authorization §6.3.1.1
PDU session modification §6.4.2.1	PDU session modification §6.3.2.1
PDU session release §6.4.3.1	PDU session release §6.3.3.1

Establishment is the one with the most jobs. Besides creating a new session, it is how an existing session is handed over between 3GPP and non-3GPP access, how a connection is transferred in from the previous generation of core network, and how a multi-access session is set up §6.4.1.1.

Authentication and authorization is the odd one out, because the party doing the authenticating is not the network at all — it is the data network at the far end, using EAP, with the SMF passing messages through §6.3.1.1.

It can run during establishment or later, and it cannot be applied to an emergency session.

Network-requested modification carries a long list of jobs: renegotiating header compression, updating traffic-steering rules, changing multicast membership, giving the device new DNS or edge configuration, or reporting the result of an authorization §6.3.2.1.

Network-requested release is the simplest clause in the document — one sentence §6.3.3.1.

6.8 How a request is matched to its answer

Several session procedures can be in flight at once, so each needs a label. That label is the procedure transaction identity, and the rules for it are four lines long and worth knowing by heart §6.2.1:

P1. Whoever starts a transaction-related procedure puts a valid identity in the request or command message.

P2. Whoever answers copies the identity it received into the response.

P3. If a command is sent because a request arrived, it carries the request's identity.

P4. If a command is not the result of a request, its identity field is set to "no procedure transaction identity assigned".

Rule P4 is the one to remember: a message from the network with no transaction identity is not malformed. It means the network started this on its own.

6.9 Where this meets the rest of the course

What these messages look like octet by octet, and what happens when one arrives broken, is What a NAS message looks like on the wire. Where the procedures came from, and how a correction to one of them becomes published text, is From a document number to a published version.