How the work gets done · chapter 13 of 16 · 7 minutes
13 Where RAN meets the groups that write the rest of 3GPP
What actually crosses the boundary between the radio and everything else — parameters, sealed messages, one letter at a time — and what this course cannot tell you about the other side.
Built from §4.2 §7.6 §9.2.2.1 §9.4 §12.1 §13.1 §15.3.1.3 §A.1
13.1 Two ways a boundary can be crossed
There are only two, and confusing them causes most of the misunderstanding about how 3GPP fits together.
The technical boundary is drawn in the specifications: what the radio network is told, what it is not told, and what it carries without reading. That one is written down in TS 38.300 and is settled.
The organisational boundary is drawn between groups of people: who may change which document, and how one group asks another for something. That one is not in any specification, and its whole visible form is a letter.
13.2 What TS 38.300 hands over, and where
The functional split clause is the cleanest statement of the technical boundary. It lists what the base station hosts, then lists what the AMF, the UPF and the SMF host — each time with a pointer to TS 23.501 §4.2.
Read that as the document saying: these functions exist, this is roughly what they do, and somebody else specifies them.
Four things then cross the boundary in the running system, and only four.
A profile per traffic stream. The core network gives the radio network a QoS profile for each flow: an identifier, a priority, and for a guaranteed flow the bit rates, loss rate and notification control §12.1. That profile is the whole of what the radio network is told about the traffic's purpose.
A key. The base station key is derived by the AMF from the core key and handed down; the radio keys are then derived from it §13.1. The radio network never sees the anchor key.
Sealed messages. Core-network signalling travels through the radio network in transparent containers §7.6. The radio network carries them in order and does not read them.
Hints. Roaming and access restrictions §9.4 and Core Network Assistance Information §9.2.2.1 are the core network telling the radio network things it could not work out for itself: which areas are forbidden, how long the device's sleep cycle is, whether it is worth sending the device to the inactive state.
13.3 Where the two sides shake hands
The interface does not exist until the two ends agree it does.
Once transport connectivity is up, the radio node and the AMF exchange configuration over NGAP in the NG Setup procedure §15.3.1.3: the radio node gives its list of supported tracking areas, the AMF gives its network identity, and only when that succeeds is the control interface operational.
The same clause carries a detail that matters in a live network: the two may agree at NG Setup that device contexts existing beforehand are not affected, and if either side does not agree to keep them, they are all removed §15.3.1.3.
That is the technical boundary at its most concrete — two nodes, owned by different groups' specifications, negotiating whether the past still counts.
13.4 The organisational crossing: one letter at a time
A group that needs something from another group writes a liaison statement. 20742 outgoing letters carry a RAN document number [1].
The mechanism is deliberately weak. A liaison statement asks, informs or answers. It cannot change the other group's document, cannot bind the other group, and gets whatever priority the receiving group's agenda gives it.
R2-2602996 is a good one to look at. It is a draft reply, tabled at 3GPPRAN2#134, and its title names its origin: a question that arrived from SA5, about how pairing identifiers are handled for two-sided machine-learning models.
R1-2603888 is RAN1's draft reply on the same subject, tabled in the same week at RAN1#125. One question from outside RAN, two RAN groups answering it separately.
13.5 The documents on the other side of the line
TS 38.300 points across the boundary constantly, and the numbers it points at are a useful map of who else is involved.
| Where it points | For what |
|---|---|
| TS 23.501 | what the AMF, UPF and SMF do; the system architecture §4.2 |
| TS 23.502 | the core-network procedures behind a connection setup §A.1 |
| TS 33.501 | the security principles the radio keys hang from §13.1 |
| TS 24.501 | the device's own conversation with the core §13.1 |
| TS 22.261 | the requirements behind unified access control §7.4 |
None of those is RAN's, and this course's register holds none of them. To find out who owns any of them, open the specification's information page, which is addressed by its number with the dots removed [2], and read the group off it.
13.6 The negative space
What does not cross is as designed as what does.
The radio network is not told what application a flow belongs to, what the subscriber pays, what policy produced the profile, or what is inside a core-network message. It gets an identifier, a priority and a set of bit rates §12.1, and a sealed envelope it must not open §7.6.
It is also not told the anchor key. The key it holds is derived for it and bound to a cell and a frequency at every handover, precisely so that a base station cannot work backwards §13.1.
That restraint is what lets the two halves be specified by different groups at different speeds. A change to a policy rule on the core side is invisible to RAN as long as the profile it produces has the same shape.
13.7 Work that arrives from outside
Some RAN work exists only because something outside RAN needs it. RP-260923, approved at RAN#112, opens conformance work on the gateway device function for mission critical communication — a service whose own specifications are not RAN's.
The pattern is worth recognising: the feature is defined elsewhere, and RAN's share is the radio behaviour and the test cases that prove it. On an agenda that shows up as a work item whose deliverables are all in one group.
13.8 What this course cannot tell you
The register behind this course was built from RAN's rows alone. It counts RAN documents, RAN meetings and RAN work items and nothing else.
So this course cannot tell you how large the other technical specification groups are, how fast they work, how their meetings are arranged, or whether any comparison you have heard is true. Nothing here measures them, and a comparison drawn from a one-sided register would be worthless.
It also cannot tell you what any group decided or why. A document's status says approved, revised, noted, withdrawn or not pursued and stops there — see What the record does not tell you.
Where to look instead: each group has its own folder on the 3GPP file server — RAN's own is linked from RAN — and each meeting has a portal page addressed by its meeting number [3]. The same addresses work for groups this course knows nothing about.
13.9 Where this meets the rest of the course
The technical boundary in full, clause by clause, is Where the radio network meets the core. The document types named here — liaison statements, work item descriptions, status reports — are How a radio feature travels from a question to a rule.
Why two RAN groups can answer the same letter in the same week, and what that costs a question that has to leave the building, is The meeting rhythm — plenary, working-group week and bis.
Where the numbers in this chapter come from
- 20742 RAN meeting documents of type 'LS out' rows in the pygppe meeting-document table /var/www/whatthespec.net/data/database/api/api.sqlite where tdoctype='LS out' and the number starts with a RAN prefix, read 2026-08-04
- address of one specification's information page read from /var/www/whatthespec.net/pygppe/site/3gpp/spec_details.php (info_url), 2026-08-04
- address of one meeting's portal page meeting_base_url in /var/www/whatthespec.net/pygppe/libs/pygpp/pygpp_globals.py, 2026-08-04
Check yourself
Answers appear when you pick one, with where they come from.
Q13.1 What is the mechanism for one 3GPP group to ask another a question?
20742 outgoing liaison statements carry a RAN document number. It is a letter from one group to another, tabled as a numbered document. 20742 RAN meeting documents of type 'LS out'
Q13.2 R2-2602996 is a draft reply. Who was it replying to?
Its title is "Reply LS on SA5 LS with questions on pairing ID handling for two-sided models" — a question that arrived from outside RAN entirely. R2-2602996
Q13.3 Who decides which QoS treatment a traffic stream gets?
The profile — the identifier, the priority, and the bit rates for a guaranteed flow — is provided by the 5GC to the NG-RAN, which uses it to decide the treatment on the radio interface. §12.1
Q13.4 What does the NG Setup procedure exchange?
Once the transport is up, the two nodes exchange application-level configuration over NGAP — supported tracking areas from the radio side, network identity from the AMF side — and only then is the interface operational. §15.3.1.3
Q13.5 What does this course's register hold about the other 3GPP groups?
The register was built from RAN's rows alone. Nothing in this course measures another group, so no comparison with them can be made here. 1059 active RAN specifications
This chapter was written against TS 38.300 version 19.3.0, and built from a source register generated 2026-08-04. A newer version of the document may say something else.