6 SA1 and the requirements nobody designed against yet

6.1 The group that goes first

Before anybody argues about radios or network functions, one group writes down what the system has to do for the person using it. In 3GPP that is SA1, and its output is called stage 1.

Stage 1 does not name a single box. It says things must be possible. The architecture group then has to make them possible, and the protocol groups have to carry the messages that do it.

Ambient IoT started in SA1, in March 2022, and everything else in this course happened downstream of what it wrote.

6.2 What a stage 1 document does and does not do

Three stages divide 3GPP's work, and knowing which one you are holding saves a great deal of confusion:

• Stage 1 says what the system must do, in the language of a service. No boxes, no messages.

• Stage 2 says what the system is made of and how the pieces interact. Boxes and arrows, no bytes.

• Stage 3 says exactly what goes on the wire. Fields, encodings, error cases.

SA1's normative work is titled "Stage 1 of Ambient power-enabled Internet of Things" and does exactly the first of those AmbientIoT. It is the reason every later group could argue about how without reopening whether.

6.3 What SA1 asked for

The founding study is FS_AmbientIoT, unique id 950004, approved as SP-220085 at plenary SP-95-e and sent in by SA WG1 FS_AmbientIoT SP-220085.

Its objective is deliberately open about where the energy comes from:

And its problem statement is the one every later document traces back to — the three uncovered cases, quoted in full in A tag with no battery, and the gap it was meant to fill ^[2].

The study ran from 2022-03-10 to 2023-05-28 and stands complete. Its report is TR 22.840, with 497 documents filed against it FS_AmbientIoT TR 22.840.

6.4 What SA1 then wrote

A study report binds nobody, so SA1 followed it with normative work: AmbientIoT, unique id 1020030, approved as SP-231403 at plenary SP-102 AmbientIoT SP-231403. It stands complete, finished 2023-12-12.

There is a second row under the same short name, unique id 1020055 AmbientIoT. It is one of the thirteen umbrella and sibling rows among the register's 37 items, kept separate rather than folded into their neighbours ^[3].

The output is TS 22.369, service requirements for Ambient power-enabled IoT — a specification that did not exist before this area of work TS 22.369. It carries 18 documents and 17 change requests, which for a requirements specification is a normal life: written once, then corrected.

SA1 also changed TS 22.261, the service requirements of the whole 5G system, with 9 change requests TS 22.261. That is how a new capability is admitted into the system's own list of what it does.

6.5 SA1 alone

SA1 filed the area's first document on 2022-04-29 SA1 ^[4]. The next groups to arrive — SA2 and RAN1 — did not file until January and February 2024 SA2 RAN1.

Until then, the only Ambient IoT work happening anywhere was requirements, plus the RAN plenary's feasibility study, which began filing in December 2022 RAN FS_Ambient_IoT_RAN.

The document counts show the same shape from the other side. The area saw 220 documents in 2022 ^[5] and 414 in 2023 ^[6], against 3384 in 2024 ^[7].

6.6 What SA1 owns now

Three specifications sit with SA1 in this area SA1:

• TS 22.369 TS 22.369 — the new requirements specification.

• TS 22.261 TS 22.261 — the 5G system's own requirements, amended.

• TR 22.840 TR 22.840 — the study report, published once and closed.

Its 529 documents were filed across 14 meetings, and it sent 10 letters to other groups across the whole area, against SA2's 139 SA1 SA2.

That is a group that stated its case and then let others get on with it.

6.7 Who SA1 handed to

Two later study descriptions name SA1 as their starting point, and they are the clearest evidence in this whole record of how stage 1 output is used.

The architecture study says it studies architecture support "based on the services requirements defined in 3GPP SA1" ^[8].

The application enablement study, three years later, works "based on the services requirements defined in SA1 and architecture and functions defined in SA2 of Rel-19" ^[9].

Read together, those two sentences are the dependency chain of the whole area: SA1, then SA2, then everybody else. It is also why SA1 could leave in May 2025 while eleven other groups were still working SA1.

6.8 The one thing this school cannot show you

TS 22.369 is the document the architecture specification says it complies with: the scope of TS 23.369 names the requirements in TS 22.369 as what it satisfies ^[10].

It would be useful to quote TS 22.369's own scope beside that. This school cannot: the parsed copy on this machine starts at clause 2, so the specification has no scope clause here to quote TS 22.369.

That is a gap in the data, not in the document. The published specification has a scope like any other, and reading it is a hop-off point rather than something this course can do for you.

6.9 Where this leads

Stage 1 is a promise about what must be possible. Turning it into boxes and interfaces is stage 2, and that is SA2's job.

SA2 and the specification that did not exist produced a specification that had not existed before and now carries more change requests than anything else in the area.

The security side, which read the same requirements and asked what could go wrong, is SA3, and why a device with no battery is a hard security problem.

6.10 Where to read on

Two documents, and this school carries the text of neither:

• TR 22.840 TR 22.840 — the study report. Use cases first, then the requirements they imply. If you want to know why anybody thought this was worth doing, this is the document.

• TS 22.369 TS 22.369 — the binding requirements. Short, and the one every other specification in the area has to satisfy.

Both have their own information page on 3gpp.org, whose address the register carries.