5 Finding your way around TS 24.501

5.1 Why the layout is worth learning before the content

TS 24.501 is not written to be read front to back. It is written so that any question about the protocol has exactly one place to be answered, and the price of that is that answering a single practical question means visiting four or five clauses in order.

Learn the layout and the document becomes usable in minutes. Skip it and every lookup turns into a search.

5.2 The map

Where	What it holds
§1	Scope: what the document covers and who it binds
§2	Every document this one leans on, with full titles
§3.1	Definitions — read this before arguing about a word
§3.2	Abbreviations
§4	General: the cross-cutting subjects, feature by feature
§5	Mobility management procedures, one per subclause
§6	Session management procedures, one per subclause
§7	What to do with data that is unknown, unforeseen or wrong
§8	Every message, with the list of fields it carries
§9	How those fields are coded, down to the bit
§10	Every timer, with its value, start, stop and expiry behaviour
§Annex A	Cause values for mobility management
§Annex B	Cause values for session management
§Annex C	What the device has to keep in non-volatile storage
§Annex D	The UE policy delivery service
§Annex E	Void
§Annex F	The change history: every version, every approved change

An annex marked "Void" is not an error. Numbering in 3GPP documents is never reused, so when material is removed the heading stays and the content becomes the single word "Void" §Annex E. The same happens to clauses inside the body.

5.3 Clause 4 is not an introduction

The most common mistake in navigating this document is treating clause 4 as front matter. It is not. It is where every subject that cuts across both protocols is defined, and much of it is normative.

Security, unified access control, network slicing, interworking with the previous generation of core network, non-terrestrial access, minimization of service interruption, non-public networks — each is a subclause of clause 4, and the procedures in clauses 5 and 6 assume you have read them.

The overview at the front of it also states the layer this all inherits: the NAS for 5GS follows the layer-3 protocol architecture model of TS 24.007 §4.1, which is another of CT1's own documents TS 24.007.

5.4 Three kinds of mobility management procedure

The document sorts its mobility procedures by how they can be started, not by who starts them §5.1.2.

Common procedures can always be initiated when the device is in connected mode. Network-initiated ones are NAS transport, primary authentication and key agreement, security mode control, generic configuration update, identification, and network slice-specific authentication. The device initiates NAS transport. Either side can send a status message to report an error.

Specific procedures are the heavyweight ones: registration, de-registration, the eCall inactivity procedure, and the authentication procedure for proximity service relays. The constraint on them is strict:

Connection management procedures are service request, started by the device to move from idle to connected or to get user-plane resources back; paging, started by the network; and notification, which the network uses to reach a device over one access about something on the other §5.1.2.

Session management has its own three-way split §6.1.2: procedures related to a PDU session, transaction-related procedures started by the device, and one common procedure — the status message.

5.5 The state machines everything is written against

Every rule in the document is phrased as "in state X, on receiving Y, do Z", so the states are not background. They are the vocabulary.

The device has six main states §5.1.3.2.1:

• 5GMM-NULL — 5G services are disabled; no mobility management function runs at all.

• 5GMM-DEREGISTERED — no context exists, the location is unknown to the network, and the device is therefore unreachable. To get out of it, the device starts an initial registration.

• 5GMM-REGISTERED-INITIATED — a registration has been sent and the answer has not come back.

• 5GMM-REGISTERED — a context exists; one or more PDU sessions may exist too.

• 5GMM-DEREGISTERED-INITIATED — a de-registration has been sent and the answer has not come back.

• 5GMM-SERVICE-REQUEST-INITIATED — a service request has been sent and the answer has not come back.

Two of those, DEREGISTERED and REGISTERED, are further split into substates that carry the real detail §5.1.3.2.1.

The eight under DEREGISTERED are NORMAL-SERVICE, LIMITED-SERVICE, ATTEMPTING-REGISTRATION, PLMN-SEARCH, NO-SUPI, NO-CELL-AVAILABLE, eCALL-INACTIVE and INITIAL-REGISTRATION-NEEDED.

The network side is deliberately simpler, with four states §5.1.3.2.3: DEREGISTERED, COMMON-PROCEDURE-INITIATED, REGISTERED and DEREGISTERED-INITIATED.

The network does not need a separate state per outstanding procedure because it is the one waiting on the device, not the other way round.

Alongside the state there is a second, smaller variable: the 5GS update status, which is stored in non-volatile memory and survives a power cycle §5.1.3.2.2.

It has three values — 5U1 UPDATED, 5U2 NOT UPDATED, 5U3 ROAMING NOT ALLOWED — and it is what lets a device that has just been switched on know whether its last attempt worked.

Session management has its own, much smaller set: PDU SESSION INACTIVE, ACTIVE PENDING, ACTIVE, INACTIVE PENDING and MODIFICATION PENDING, plus two states for a procedure transaction §6.1.3.2.2 §6.1.3.2.4. There is one of these per PDU session, not one per device.

5.6 The error-handling clause, and why its order matters

Clause 7 exists because two implementations will always disagree about something eventually, and the protocol has to survive that without either side locking up.

It also does a second job, stated openly: as well as recovering from errors, it defines the compatibility mechanism that lets the protocol be extended later §7.1. A device that meets a field it has never heard of has to do something predictable with it, or no future Release could ever add one.

The clause has a property that is easy to miss and changes the answer to almost every question about it:

So a message that is too short is dealt with under the length rule and never reaches the rules about unknown message types. Working out what a receiver does with a broken message means walking the subclauses in order and stopping at the first that applies.

5.7 The reading path, in practice

Take a real question: a device sent a registration request and got a rejection with cause #3.

S1. Find the procedure — the registration procedure, in clause 5.

S2. Find the branch — "not accepted by the network", the subclause that handles rejections.

S3. Look up the cause value in §A.1, which says cause #3 means "Illegal UE" and is sent when an identity is not acceptable or the device failed the authentication check.

S4. Look up the message in clause 8 if you need to know what else was in it.

S5. Look up any timer the procedure started in §10.1, which warns that its own tables are a brief summary and that clauses 4 to 6 are the definitive description.

Five stops. That path is the same for every question this document can answer, and the next two chapters walk it for the procedures themselves Getting on the network, and getting a connection through it and for the messages What a NAS message looks like on the wire.