4 The radio side and the architecture side

4.1 Two halves of one problem

Take the battery out of a device and two quite different questions open at once.

The radio question is whether a thing that peaks at about a microwatt can be talked to over the air at all — how it is reached, how it answers, and what it costs the network to do so. ^[6]

The architecture question is what the rest of the network has to become for that device to exist in it: which function holds its data, who is allowed to ask after it, how the area it lives in is named. ^[7]

3GPP ran those two down separate tracks, and the document counts show both tracks being heavy at the same time.

4.2 The radio side

The radio work opened with a feasibility study, FS_Ambient_IoT_RAN, unique id 970078, approved as RP-232404 at plenary RP-101 and sourced from Huawei, HiSilicon. Its report is TR 38.848. FS_Ambient_IoT_RAN RP-232404 TR 38.848

Once that came back, RAN1 ran the study that designed the thing: FS_Ambient_IoT_solutions, unique id 1020085, approved as RP-240826 at plenary RP-103 and sourced from CMCC. FS_Ambient_IoT_solutions RP-240826

That single study carries 2357 documents — more than any other item in the whole area, study or specification work alike. FS_Ambient_IoT_solutions Its report is TR 38.769, and the ~1 µW target quoted in What Ambient IoT is meant to be is that report's own scope. TR 38.769 ^[6]

The normative radio work that followed is Ambient_IoT_Solutions-Core, unique id 1061084, approved as RP-252105. Ambient_IoT_Solutions-Core RP-252105

Four radio groups came out of it with documents of their own:

• RAN1 owns TS 38.291, the physical layer — the bits on the air. TS 38.291

• RAN2 owns TS 38.391, the medium access control protocol, and TS 38.300, the overall description of the NR radio network. TS 38.391 TS 38.300

• RAN4 leads the performance part and owns three radio specifications: TS 38.191 for the device, TS 38.194 for the base station and the carrier-wave node, and TS 38.195 for how the two are tested. Ambient_IoT_Solutions-Perf TS 38.191 TS 38.194 TS 38.195

• RAN3 leads no Ambient IoT work item at all, yet owns five of the affected specifications, including TS 38.413 — the protocol between the radio network and the core — with 77 change requests. RAN3 TS 38.413

4.3 The architecture side

SA2's study is confusingly also called FS_AmbientIoT — a different unique id, 1020071, and a different job. It was approved as SP-240969 at plenary SP-104. FS_AmbientIoT SP-240969

That sentence sets the order of the whole area: requirements first, from SA1, then architecture built to meet them. Its report is TR 23.700-13, against which 746 documents were filed. TR 23.700-13

The normative work is AmbientIoT-ARC, unique id 1070010, approved as SP-250377. AmbientIoT-ARC SP-250377

Its output is TS 23.369, which carries 816 documents and 524 change requests — the busiest specification in the area by a distance. TS 23.369

Two long-standing 5G documents had to give way for it: TS 23.501, the architecture of the 5G system itself, with 14 change requests, and TS 23.502, the procedures of that system, with 26. TS 23.501 TS 23.502

4.4 Where the protocol groups pick it up

Stage 2 says how the system is put together; stage 3 says what actually goes on the wire. Three CT groups do that here, under one shared work item description, CP-252196, approved at plenary CP-109 and sourced from CT1. CP-252196

CT1 owns TS 24.369, the signalling a device exchanges with the network; CT3 owns TS 29.569, the services the Ambient IoT network function offers; CT4 owns TS 29.369, the service that stores and serves device data. TS 24.369 TS 29.569 TS 29.369

Security and the application layer run alongside. SA3's normative work is AmbientIoT-SEC, producing TS 33.369 AmbientIoT-SEC TS 33.369, and SA6 carries the application enablement side and owns TS 23.370. SA6 TS 23.370

4.5 What the register will not explain

The quotations above use the documents' own names — AIOTF, AIoT RAN, Device 1, Topology 1, Topology 2. The source register carries those names exactly as written and explains none of them. ^[8]

Anybody who needs to know what they mean has to open the specification that defines them, and that is the honest end of what this chapter can say.

4.6 Where to read this yourself

Radio: TR 38.848 for the feasibility question, TR 38.769 for the reasoning, then TS 38.291, TS 38.391 and TS 38.300 for what was specified. TR 38.848 TR 38.769 TS 38.291 TS 38.391 TS 38.300

Architecture: TR 23.700-13 for the study, TS 23.369 for the result. TR 23.700-13 TS 23.369

Protocols: TS 24.369, TS 29.569 and TS 29.369. TS 24.369 TS 29.569 TS 29.369

The School of Specs holds none of those texts. Every number above is a pointer at 3gpp.org, not a summary of what the document says inside.