2 What the group produces, and what one of its documents looks like

2.1 What a specification is, and how many CT1 has

A specification here is one numbered document 3GPP publishes. Two kinds matter: a TS, a technical specification, tells you what to build; a TR, a technical report, studies a question and binds nobody.

237 specifications are listed against CT1 ^[1] and 229 of them are still active ^[2] — 199 technical specifications ^[3] and 30 technical reports ^[4], all counted on 2026-08-04.

175 of those 229 live in one number series ^[5], so a CT1 document number usually starts with 24.

A Release is a numbered edition of the whole 3GPP system, and a document gets a new version for each Release it is carried into.

154 of the active CT1 specifications have reached Rel-19 ^[6] and only 31 have reached Rel-20 ^[7], the edition still filling up.

2.2 One you can open: TS 24.501

TS 24.501 carries the protocol between your phone and the core of a 5G network, and no CT1 document has drawn more paper: 15623 CT1 documents propose changes to it over the whole record ^[8], most of them change requests and the rest proposals to a draft or papers for discussion.

NAS, the non-access stratum, is the signalling that travels between the phone and the core network itself rather than to the radio mast.

It is the highest layer of the control plane between the phone — the UE, or user equipment — and the AMF, the function that keeps track of where a device is and whether it is reachable §4.1.

Mobility management is the traffic that gets a phone registered and keeps it reachable. Session management is the traffic that builds and tears down its data connections, through the SMF, the session management function.

The document also carries the delivery of policy to the phone from the PCF, the policy control function §1.

2.3 The four things a protocol document has to settle

The procedures. Mobility management fills one whole part of the document §5 and session management the next §6. Each procedure is written as a small machine: who may start it, in which state, and what the other end has to do. Registration, for instance, is always started by the phone and never by the network §5.5.1.1.

The messages. The next part defines each message: its direction, its use, and a table of the information elements it carries, each with a presence requirement of mandatory, conditional or optional, a format, and a length in octets §8.1. An information element — IE for short — is one named field inside a message.

REGISTRATION REQUEST, the message a phone sends to register itself, goes from the UE to the AMF and opens with mandatory fields before a long tail of optional ones §8.2.6.1.

The bytes. Then comes the layout of those fields. Every message opens with an extended protocol discriminator and a security header type; a plain message carries a message type and its information elements after that, while a security protected message wraps a plain one behind a message authentication code and a sequence number §9.1.1.

What happens when it goes wrong. Unknown, unforeseen and erroneous data has a part of its own, and it says plainly that these rules are not only for errors: they are the mechanism that lets the protocol be extended later without breaking the phones already in the field §7.1.

The timers are listed at the end, with a warning that the list is a summary and the procedures themselves are the definitive text §10.1.