1 Who writes this document, and why

1.1 Why anybody writes a document like this

A phone bought in Seoul has to work on a network in Lisbon, on radio equipment made in Sweden, talking to a core network made in China, billing through software made in India.

Nobody owns that chain. No single company can fix it by shipping a better product. The only thing that makes it work is that everyone agreed, in writing and in advance, on where each piece stops and the next one starts.

That agreement is what a 3GPP specification is. TS 23.501 is the piece of it that says what functions a 5G core network is made of, what each one is responsible for, and how they are wired together.

1.2 Who 3GPP is

This section and the next one are background, and none of it comes from TS 23.501: it is how 3GPP describes itself in its own working procedures.

3GPP is the 3rd Generation Partnership Project, started in 1998 to write the specifications for third-generation mobile networks. It kept the name through 4G and 5G.

It is a partnership of seven regional standards bodies, called the Organizational Partners: ARIB and TTC in Japan, ATIS in the United States, CCSA in China, ETSI in Europe, TSDSI in India and TTA in Korea.

3GPP itself publishes no standard with legal force. Each partner republishes the text under its own label — the European version of this document is ETSI TS 123 501, the same words with a different cover.

The people in the room are employees of member companies: network operators, equipment makers, chip designers, test-house engineers, research institutes. Companies join through one of the seven partners. Decisions are made by consensus in meetings, not by a vote of nations.

1.3 Which group owns this document

Work is split across three Technical Specification Groups, each with its own working groups underneath:

• TSG SA — Service and System Aspects. What the system must do and how it is put together. SA1 writes requirements, SA2 writes architecture, SA3 security, SA4 media and codecs, SA5 management and charging, SA6 the application layer above the network.

• TSG CT — Core Network and Terminals. The actual messages. CT1 writes the signalling between a device and the core, CT3 and CT4 the protocols inside the core and towards outside networks.

• TSG RAN — Radio Access Network. Everything on the radio side. RAN1 the physical layer, RAN2 the radio protocols above it, RAN3 the interfaces between radio nodes and the core, RAN4 radio performance, RAN5 conformance testing.

TS 23.501 belongs to SA2. SA2 drafts it; the TSG SA plenary approves it. That plenary is the "TSG" the Foreword is talking about §Foreword, and every approval in the change history is stamped with its meeting number — SP#76, SP#79, SP#112 §Annex X.

1.4 What the number means

3GPP numbers are <series>.<number>, and the series alone tells you what kind of document you are holding.

Series	What lives there
21	Vocabulary and working methods
22	Service requirements — stage 1
23	System architecture — stage 2
24	Signalling between device and network — stage 3
26	Codecs and media
28	Management and orchestration
29	Protocols inside the core network — stage 3
32	Charging
33	Security
36	4G radio (E-UTRA)
38	5G radio (NR)

Two document types share the numbering. A TS, Technical Specification, is binding: it says what a conforming implementation does. A TR, Technical Report, is a study — it explores options and records conclusions, and nobody has to obey it.

TS 23.501 leans almost entirely on other binding text. Its reference list §2 has 224 entries, and they break down like this:

• 131 other 3GPP documents, of which only three are studies.

• 56 IETF request-for-comments documents and five IETF drafts still in progress.

• Three ITU-T recommendations.

• Seven entries marked "Void" — references deleted over the years. The numbers are never reused, so the ones after them do not shift.

• 22 from elsewhere: IEEE, the Broadband Forum, CableLabs, the Wi-Fi Alliance, GSMA, SMPTE, IEC and one ITU numbering bulletin.

1.5 Requirements, architecture, protocols

The three-stage split is older than 3GPP. It comes from two ITU-T recommendations that clause 1 names directly: I.130 describes the method, Q.65 defines what stage 2 is §1.

• Stage 1 says what the user gets, in the language of a service. For 5G that is mostly TS 22.261, written by SA1. It talks about latency targets and device densities, never about which box does what.

• Stage 2 says what the system is made of and how the pieces interact. That is this document, plus TS 23.502 for the procedures and TS 23.503 for policy and charging — the scope names both as companions §1. Stage 2 draws boxes, arrows, states and parameters. It does not define one byte on the wire.

• Stage 3 turns stage 2 into messages with fields, encodings and error codes. TS 24.501 for what a device sends to the core, TS 29.500 and its neighbours for what core functions send each other.

1.6 Releases, and how a feature gets into one

Everything cannot change at once, because equipment has to be built. So 3GPP freezes the feature set at intervals and calls each snapshot a release.

A release is a promise about scope: after the freeze date, no new features go in, only corrections. Vendors and operators can then agree to build "Rel-17" and know what that means.

Once the document is under change control, its first digit is the release. The change history shows exactly that §Annex X:

Release	First version	Date	Meeting
Rel-15	15.0.0	12-2017	SP#78
Rel-16	16.0.0	2019-03	SP#83
Rel-17	17.0.0	2021-03	SP#91E
Rel-18	18.0.0	2022-12	SP#98E
Rel-19	19.0.0	2024-06	SP#104
Rel-20	20.0.0	2025-12	SP#110

Rel-15 was the first 5G release, approved at SP#78 in December 2017. Rel-18 onwards is marketed as 5G-Advanced; the specifications themselves never use that word.

A feature reaches this document along a fixed road:

• S1. Somebody proposes a study. It becomes a Technical Report, usually in the 23.7xx range, which lists key issues and candidate solutions.

• S2. If the study concludes something worth building, a work item is agreed. That is the licence to touch binding text.

• S3. Under that work item, change requests are written against TS 23.501, TS 23.502 and whatever else the feature touches.

• S4. Once the architecture is settled, CT and RAN write the stage 3 that carries it.

The version number itself is defined in the Foreword, and the first four lines of the change history are that rule in action: 1.0.0 in June 2017 presented for information, 2.0.0 and 2.0.1 in December 2017 presented for approval, then 15.0.0 the same month once the plenary had approved it.

1.7 How the document changes after it is published

The plenary meets about four times a year, in March, June, September and December. Nothing changes between meetings. A version of a 3GPP specification is always the state of the text at the end of one meeting.

Between meetings, the working group argues over change requests. A change request is a small patch: the clauses it touches, the old text, the new text, a reason, and the release it applies to. It gets a number that is unique within the specification.

Change requests are gathered into a TDoc — a temporary document with a number like SP-260441 — and that pack is what the plenary actually votes on. That is why dozens of change-history lines share one TDoc number.

Each line of the change history §Annex X carries seven fields:

Field	What it holds
Date	Month the meeting ended
Meeting	Plenary that approved it, for example SP#112
TDoc	The pack the change travelled in
CR	The change request number, unique in this specification
Rev	How many times it was redrafted before it passed
Cat	The kind of change
New version	The version that first contains it

The Cat letter is the kind of change: F a correction, A the same correction copied into another release, B a new feature, C a change to an existing feature, D an editorial fix. Across the whole history F leads with 1867 lines, then B with 653.

The whole record is 2871 lines, 2861 of them carrying a change request number, spread over 642 TDocs and 37 plenary meetings from SP#76 in June 2017 to SP#112 in June 2026.

In those nine years the document has had 50 versions. The busiest single meeting was SP#84 in June 2019, which pushed 182 changes into version 16.1.0.

The first real change request, CR 0002 at SP#79 in March 2018, was titled "Using NRF for UPF discovery" — a matter How one function finds another still turns on today.

An "E" on a meeting number, as in SP#91E, marks a meeting held electronically. They run from SP#87E in March 2020 to SP#98E in December 2022, which is a pandemic visible in a change log.

1.8 Where this leads

You now know who wrote the document, which group owns it, what its number means and how it moves.

Next comes the shape of the document itself — its clause numbering, its conventions, and the four words that decide whether a sentence is binding — in How to read a 3GPP specification. After that, the architecture proper starts with The shape of the 5G core.