2 Architecture and protocol — what stage 2 and stage 3 mean

2.1 The same thing, written twice

Someone has to say that a phone registers with the network before it can use it. Someone else has to say that the phone sends a message called REGISTRATION REQUEST, that the network answers with REGISTRATION ACCEPT or REGISTRATION REJECT, and that the phone gives up after fifteen seconds.

Those are two different documents, written by two different groups, and both of them are current. The first is called a stage 2 document, the second a stage 3 document, and 3GPP prints the word in the title so you can tell them apart at a glance.

TS 24.501 is a stage 3 document, and its full title ends with those words TS 24.501. So do a great many of the group's other titles: TS 24.301, TS 24.229 and TS 24.554 all end the same way.

2.2 What the architecture document is for

You do not have to take the split on trust. TS 24.501's own reference list names TS 23.501 and gives its title as "System Architecture for the 5G System; Stage 2", with TS 23.502 beside it as "Procedures for the 5G System; Stage 2" §2.

It does not restate either of them; it points at them. Clause §4.1 uses the first to say where the protocol sits, naming the reference point between the phone and the AMF.

Two things are worth taking from that. The protocol document borrows its map from elsewhere — "N1" is a name the architecture gave to a line on a diagram.

And it builds the pieces, not the whole run: what CT1 writes are elementary procedures, and the sequences those pieces are assembled into are somebody else's page.

A stage 3 document that referenced nothing would be a document that had invented its own world. This one leans on a long list of others, and prints that list before it prints a single procedure.

2.3 What the second description buys you

An architecture document can say "the phone tries again". A protocol document has to say how many times, after how long, and what changes on the last attempt. That is why the stage 3 document is the longer one.

Take the moment a phone asks to register. The timer table gives T3510 a value of 15 s, says it runs in the state 5GMM-REGISTERED-INITIATED, starts on transmission of the REGISTRATION REQUEST message, and stops when REGISTRATION ACCEPT or REGISTRATION REJECT arrives §10.2.

The same table carries a default of 12 minutes for T3502 and a default of 54 minutes for T3512, and longer values again for a phone reaching the network through a satellite §10.2.

None of that is architecture. All of it is the difference between two devices working together and two devices sulking at each other.

Rejections are treated the same way. There is no field for "sorry": there is a numbered cause, and the meaning of each number is written down. Cause #3 is "Illegal UE", sent when an identity is not acceptable to the network or the device fails the authentication check §A.1.

2.4 Telling one from the other at a glance

You do not have to read a 3GPP document to know which kind it is. Four things give a stage 3 document away, and TS 24.501 has all four.

• The title says so. "Stage 3" is printed at the end of it TS 24.501.

• Message names in capitals. REGISTRATION REQUEST, REGISTRATION ACCEPT, REGISTRATION REJECT are the names of actual messages, and the timer table starts and stops on them §10.2.

• Numbered refusals. Rejections carry a cause number with a written meaning, not a description §A.1.

• A change history at the back. Every approved edit is one row with its own number §Annex F.

An architecture document has none of those, because none of them is a decision about the shape of the system. They are decisions about the shape of a byte.

2.5 How the two sides stay in step

If two groups describe one system, they have to talk. CT1 does that in writing, with a document type of its own: a liaison statement is a letter from one working group to another — a question, an answer, or a warning that something has changed.

In the twelve months to August 2026 CT1 sent 108 such letters ^[1] and received 135 ^[2]. Where they went, when they went to one group only:

Direction	Busiest partner	Letters
Out	RAN2	44 [3]
Out	SA2	19 [4]
In	SA2	39 [5]
In	RAN2	15 [6]

The register carries only the four busiest partners in each direction, so this is the top of the list and not the whole of it. What the letters said is not in the data at all — only that they were sent.

2.6 The seam inside the document

The split between "what the system does" and "what is sent" also runs inside TS 24.501, because the document carries two protocols side by side: mobility management and session management.

Clause §4.2 is the rule for how the two behave when they overlap. A session management message is piggybacked inside a mobility management transport message, both procedures run in parallel, and the success of the outer one does not depend on the success of the inner one.

That is a sentence no architecture document would ever need to write, and exactly the sort of sentence a stage 3 document exists for. What the rest of TS 24.501 looks like is Inside TS 24.501, the document at the centre; what else CT1 owns is What the group owns, and what it actually works on.