5 RAN2, RAN3, RAN4 and RAN5 — protocols, interfaces, performance, tests

5.1 Four jobs the physical layer does not do

RAN1 decides what goes on the air. That leaves four jobs, and 3GPP gives each one to a different group:

• RAN2 writes the protocols that sit above the air — how a message is framed, when a device may speak, what the overall radio network looks like.

• RAN3 writes the interfaces between radio nodes and between the radio network and the core.

• RAN4 writes the radio performance requirements — the numbers a transmitter and a receiver must actually meet.

• RAN5 writes the conformance tests that decide whether a real device does.

Each of them filed in its own right: 996 documents from RAN2, 805 from RAN3, 737 from RAN4 and 58 from RAN5 RAN2 RAN3 RAN4 RAN5.

5.2 RAN2 — the protocol above the air

RAN2 filed 996 documents across 14 meetings and sent 38 letters to other groups, the joint second-highest in the area RAN2.

It leads no Ambient IoT work item of its own. What it owns is two specifications, and the difference between them is worth understanding:

• TS 38.391, the Ambient IoT medium access control protocol — a new document, written for this work, with 36 documents and 28 change requests against it TS 38.391.

• TS 38.300, the overall description of the NR radio network — an existing document, one of the most-read in 3GPP, which took 58 Ambient IoT change requests TS 38.300.

TS 38.300 matters beyond RAN2, because the architecture specification points at it by name: the device types, traffic types, use cases and connectivity topologies that TS 23.369 complies with are the ones defined in TS 38.300 ^[1].

5.3 RAN3 — the interfaces

RAN3 is the clearest example in this area of a group doing heavy work while leading nothing. It filed 805 documents across 15 meetings, sent 30 letters, and leads not one work item RAN3.

What it has instead is five specifications, all of them existing documents that had to be taught about a new kind of device:

Spec	What it is for in general	Ambient IoT change requests
TS 38.413 TS 38.413	the protocol between the radio network and the core	77
TS 38.410 TS 38.410	general principles of that same interface	13
TS 38.401 TS 38.401	how the radio network is built	9
TS 38.412 TS 38.412	how signalling is carried to the core	7
TS 38.423 TS 38.423	the protocol between two radio network nodes	6

RAN3 also filed the newest Ambient IoT document in this whole record, on 2026-07-30 RAN3 ^[2].

5.3.1 Why interfaces need changing at all

It is worth asking why five interface specifications had to move for a device that never talks to any of them directly.

The answer is that everything a radio network learns has to be told to the core network, and the language it uses is fixed. A new kind of device means new things to say: what it is, where it was seen, what it answered. None of that can be said in a protocol that has no words for it.

That is why the heaviest single existing-document change in the radio area is TS 38.413, the protocol between the radio network and the core, at 77 change requests TS 38.413 — and why the same pattern repeats on the core side in CT1, CT3, CT4 and CT6 — one work item description, four groups.

5.4 RAN4 — the numbers a radio must meet

RAN4 leads the performance half of both RAN work items: Ambient_IoT_Solutions-Perf, unique id 1062084, complete as of 2026-03-03, and its phase 2 sibling Ambient_IoT_Solutions_Ph2-Perf, unique id 1082086 Ambient_IoT_Solutions-Perf Ambient_IoT_Solutions_Ph2-Perf.

It owns three new specifications, and the split between them is the usual RAN4 pattern — one for each end of the link, and one for testing the network end:

• TS 38.191 TS 38.191 — what the device's radio must transmit and receive. 98 documents, 59 change requests.

• TS 38.194 TS 38.194 — the same for the base station and the carrier-wave node. 69 documents, 39 change requests.

• TS 38.195 TS 38.195 — how those two are tested for conformance. 32 documents, 5 change requests.

The carrier-wave node having its own specification is worth pausing on. It exists because of the design in RAN1 and the radio problem: a device that reflects rather than transmits needs somebody else to provide the wave, and whoever provides it has performance requirements of its own ^[3].

5.5 RAN5 — the tests

RAN5 is the newest arrival in the area, and by some distance the smallest: 58 documents across two meetings, first filed 2026-01-30 RAN5.

That is not a sign of neglect. Conformance testing cannot start until there is settled text to test against, and RAN5's work item — Ambient_IoT_Solutions_plus_CT1_SA3-ConTest, unique id 1100036 — opened as RP-253381 at plenary RP-110 Ambient_IoT_Solutions_plus_CT1_SA3-ConTest RP-253381.

Its name says which three groups' output it tests: the RAN solutions work, plus CT1's and SA3's parts. It owns two specifications, both still early:

• TS 38.591-1 TS 38.591-1 — device conformance, the shared test environment. 17 documents, no change requests yet.

• TS 38.591-2 TS 38.591-2 — device conformance, radio transmission and reception. 10 documents, no change requests yet.

Zero change requests against both is exactly what you expect from a document still being drafted: there is nothing published to correct.

5.6 What this tells you about reading the area

The four groups in this chapter divide by layer and by end of the link, and that division is the fastest way to find the right document:

• What goes on the air — RAN1, TS 38.291.
• How the conversation is framed — RAN2, TS 38.391 and TS 38.300.
• What the network says to itself about it — RAN3, TS 38.413 and friends.
• What the radios must physically achieve — RAN4, TS 38.191 and TS 38.194.
• Whether a real product does — RAN5, TS 38.591-1 and TS 38.591-2.

5.7 Where to read on

Eleven specifications are named in this chapter and this school carries the text of none of them.

Each has a register entry with its catalogue title, its owning group, its counts and a link to its information page on 3gpp.org TS 38.391 TS 38.413 TS 38.191 TS 38.591-2.

If you read one, read TS 38.300 TS 38.300: it is the document the architecture specification defers to for what a device type and a topology actually are, and it will make SA2 and the specification that did not exist considerably easier.