4 Inside TS 24.501, the document at the centre

4.1 Why one document is worth this much attention

15623 change documents have been filed against 24.501 over the whole record ^[1]. Nothing else CT1 owns comes close. If you only ever open one thing the group produces, this is it.

It is also the document that shows what a stage 3 specification is like from the inside: not an explanation, but a very long list of exact obligations, with a machine at each end expected to meet them.

The layout is worth learning on its own, because the question you have and the clause that answers it are rarely in the same part of the book.

4.2 The spine

Clauses §1 to §3.1 are the front matter of any 3GPP document: what is covered, what it depends on, and what its words mean. The definitions clause alone runs to thousands of words, and the abbreviations sit beside it in §3.2.

Clause §4.1 is the overview — where the protocol sits and what its main functions are. The rest of clause 4 is a long series of separate topics, each a feature that had to be fitted into the same protocol later.

Then come the two halves that do the work:

• §5 holds the elementary procedures for mobility management, which the document shortens to 5GMM.

• §6 holds the elementary procedures for session management, 5GSM.

• §7 is what to do with a message that is short, unknown or wrong.

• §8 says what each message contains.

• §9 says how each of those contents is coded into bytes.

• §10 lists the timers.

Annexes A to F follow, and the last of them is the change history.

4.3 The two protocols

Mobility management is about the device: where it is, who it is, whether it may be here, and whether the network can reach it. Clause §5.1.2 sorts its procedures into three types by how they can be started.

Common procedures can always be started while the device is in 5GMM-CONNECTED mode, which means while a signalling connection exists: authentication, identification, security mode control and the rest.

The specific procedures include registration and de-registration, and only one UE-initiated specific procedure may run at a time for each access. The connection management procedures are service request, paging and notification §5.1.2.

Session management is about the data connection. Clause §6.1.2 sorts its own into three types — those tied to a PDU session, those tied to a transaction, and one common procedure.

Clause §6.1.1 then sets the condition that makes the ordering clear: nothing in session management may happen until mobility management has done its job.

4.4 The state machine

Behaviour in a protocol document is written as states. Clause §5.1.3.2.1 gives the main states a device can be in, and the picture that goes with them.

The six main states read almost as plain English. 5GMM-NULL means the service is switched off. 5GMM-DEREGISTERED means no context exists and the network does not know where the device is. 5GMM-REGISTERED means a context exists §5.1.3.2.1.

The other three are waiting rooms: REGISTERED-INITIATED after asking to register, DEREGISTERED-INITIATED after asking to leave, and SERVICE-REQUEST-INITIATED after asking for service, each of them waiting for the network to answer §5.1.3.2.1.

Underneath the main states sit substates, and this is where the document gets its reputation. 5GMM-DEREGISTERED alone is subdivided into named substates such as NORMAL-SERVICE, LIMITED-SERVICE, ATTEMPTING-REGISTRATION and PLMN-SEARCH, each with its own entry conditions §5.1.3.2.1.

4.5 Messages, bytes and clocks

Clause §8.1 describes what a message definition contains: the direction and use of the message, a table of the information elements in the order they appear, and the conditions under which the optional ones are included.

Clause 9 then takes each of those elements apart. The first octet of every message carries the extended protocol discriminator §9.2, and clause §9.11.1 explains the trick that keeps the protocol extensible: a receiver that meets an element it does not know can read its length and step over it.

Clause 10 lists the timers, and opens with a warning that is easy to miss and expensive to ignore.

4.6 When something goes wrong

Clause §7.1 governs bad data, and it does two jobs at once. It says how to recover from an error, and it defines how the protocol may be extended later without breaking the devices already in the field.

It also fixes an order. Clauses §7.1 to §7.8 are applied in order of precedence, so a message that fails an earlier check never reaches a later one §7.1.

4.7 The annexes

• Annex A and Annex B are the cause values: the numbered reasons a request is refused. Cause #3 is "Illegal UE", sent when an identity is not acceptable or the device fails the authentication check §A.1.

• Annex C says which parameters the device stores and where — on the USIM where the file for them exists, otherwise in the phone's own memory §C.1.

• Annex D is a protocol of its own: the UE policy delivery service, between the device and the policy control function §Annex D.

• Annex F is the change history, and it is the most useful page in the document for anyone trying to work out why a sentence reads the way it does §Annex F.

How a change reaches Annex F at all is How a change request becomes published text, and the room where it is agreed is How a CT1 meeting runs, in real numbers.