TS 24.501, the document it is known by · chapter 4 of 14 · 7 minutes
4 TS 24.501 — two protocols living in one document
What the NAS specification covers, the two sublayers inside it, and the rule that makes one of them depend on the other.
4.1 The problem it exists to solve
A device that has just been switched on knows nothing useful. It does not know whether this network will accept it, what identity it should use, whether the messages it is about to send can be read by anybody listening, or what services it will be allowed once it is in.
The network knows just as little. It has an incoming message from a radio it has never heard from before, and it has to decide whether this is a subscriber, an impostor, or the same subscriber returning from a different country.
TS 24.501 is the agreed script for that conversation, and for everything that follows it while the device stays attached. Over the whole record it has drawn 15623 change documents from CT1 [1], more than any other specification the group owns.
4.2 What the document covers
The scope is unusually direct. It says the document specifies the non-access stratum procedures used by two protocols: mobility management between the device and the AMF, and session management between the device and the SMF, for both 3GPP access and non-3GPP access §1.
It adds a third thing that is easy to miss — the procedures for the UE policy delivery service between the device and the PCF, again over both kinds of access §1. Those live in an annex rather than in the main clauses.
And it says who is bound by it: the device, the AMF, the SMF and the PCF §1. Nothing else in the network has to obey this document.
4.3 Where the NAS sits
The document places itself in one sentence:
Three things are packed in there.
"Highest stratum of the control plane" means everything below it — the radio, the transport between base station and core — carries NAS messages without reading them.
"Between the UE and the AMF" means the base station is not a party to the conversation. It relays.
"For both 3GPP and non-3GPP access" means the same protocol runs whether the device came in over a mobile radio or over Wi-Fi. The document says its clauses are common to both unless a clause states otherwise §1, which is a rule worth remembering while reading.
The connection this all runs on has a name and a careful definition: the N1 NAS signalling connection, which the document calls the concatenation of an access stratum connection and an NG connection via the N2 reference point §3.1.
4.4 The main functions
The overview lists what the protocols are for §4.1:
-
Mobility of the device, including the common procedures that support it: authentication, identification, generic configuration update and security mode control.
-
Session management, to establish and maintain data connectivity between the device and a data network.
-
A transport service, so other things can travel inside NAS messages — short messages, positioning protocols, location services, policy containers and parameter updates.
That third one is worth pausing on. A large part of what NAS carries is not about NAS at all: it is other protocols hitching a ride because the device already has a secured signalling path to the core.
4.5 The two sublayers, and which one is in charge
The mobility half is called 5GMM, short for 5GS mobility management §3.2. Its own summary of itself is short: it supports identification, security and mobility of the device, plus generic message transport, and it provides connection management services to the other sublayer §5.1.1.
The session half is 5GSM, 5GS session management §3.2. It handles PDU sessions in the device and in the SMF, with the AMF passing the messages through §6.1.1.
The relationship between them is not symmetric, and this is the single most load-bearing rule in the document:
Mobility management first, always. A device cannot ask for a connection before the network has agreed that it is a device it recognises and the two sides have started protecting their messages.
4.6 Piggybacking, and the trap in it
Because session management messages have to reach the SMF and the device only talks to the AMF, a session management message travels inside a mobility management transport message §4.2. The document calls this piggybacking.
When it happens, the device, the AMF and the SMF run the mobility procedure and the session procedure in parallel §4.2. And then comes the sentence that catches people out:
So a registration can be accepted while the session request that rode along inside it is rejected. Two outcomes, one exchange of messages.
The reverse rule also holds and is easy to forget. During mobility management procedures the device and the AMF suspend sending session management messages altogether §4.2.
There are two named exceptions: when the mobility procedure is itself carrying a piggybacked session message, and one specific service-request case §4.2.
4.7 How old and how big
The change history at the back of the document records every version it has ever had, and its first row is dated 2017-10 with the version numbered 0.0.0 and the comment "Draft skeleton provided by the rapporteur" §Annex F. The version this course reads is 20.0.0, dated 2026-06 in the same table.
Between those two rows is the whole life of the document, one line per approved change. How that machinery works is From a document number to a published version.
What that history produced is not a document anybody holds in their head.
The registration procedure alone fills a dozen subclauses §5.5.1.1, and much of their length is not the ordinary case at all but the parts headed "Abnormal cases in the UE" and "Abnormal cases on the network side", which nearly every procedure in the document carries.
Nobody reads it front to back, and the document does not expect them to. It expects a reader who has a question, knows which clause answers it, and knows which other clause that answer depends on. Building that skill is the whole point of Finding your way around TS 24.501.
4.8 Where this meets the rest of the course
The document's internal layout, and how to move around it, is Finding your way around TS 24.501. The procedures themselves are Getting on the network, and getting a connection through it, and what the messages look like on the wire is What a NAS message looks like on the wire.
Why the document keeps pointing at other documents, and whose they are, is The neighbours — and how little the record says about them.
Where the numbers in this chapter come from
- 15623 CT1 documents change 24.501 (Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3), over the whole record rows in the pygppe document database, table tdoc where meeting starts with 'C1-' and crspec='24.501'; rank 1 of the whole group, read 2026-08-04
Check yourself
Answers appear when you pick one, with where they come from.
Q4.1 What are the two protocols defined inside TS 24.501?
5GS mobility management runs between the device and the AMF; 5GS session management runs between the device and the SMF. Both live in the same document and both are called NAS. §1
Q4.2 If a session management message is piggybacked on a mobility management message and the session part fails, what happens to the mobility part?
The document says in as many words that the success of the 5GMM procedure is not dependent on the success of the piggybacked 5GSM procedure. The two run in parallel. §4.2
Q4.3 When may a device start a session management procedure?
Session management procedures can be performed only if a 5GMM context has been established and the AMF has started the secure exchange of NAS messages. Mobility management comes first, always. §6.1.1
Q4.4 What is an N1 NAS signalling connection made of?
The definition calls it the concatenation of an access stratum connection and an NG connection via the N2 reference point. The NAS does not have a link of its own; it borrows two. §3.1
Q4.5 Besides mobility and session management, what third thing does the scope of TS 24.501 say the document specifies?
The scope names it explicitly, for both 3GPP and non-3GPP access, and the procedures for it sit in an annex rather than in the main clauses. §1
This chapter was written against TS 24.501 version 20.0.0, and built from a source register generated 2026-08-04. A newer version of the document may say something else.