School of Specs Ambient IoT — a tag with no batteryIn depth

Protocols, management and the layer above · chapter 10 of 14 · 6 minutes

10 SA5 and SA6 — running it, billing it, and building on top of it

The two smallest system groups in the area, the eleven specifications they touch, and the work item whose description has no objective to quote.

10.1 The two jobs nobody thinks about until later

A network feature is not finished when the protocol works. Somebody has to be able to run it — see how it is performing, configure it, keep a model of what exists — and somebody has to be able to bill for it.

That is SA5's job, and it covers both: telecom management on one side, charging on the other.

Above all of it sits a different question again: what does an application developer talk to, so that using Ambient IoT does not mean speaking core network protocols? That is SA6's job.

Both groups are small in this area, and both arrive late, for the same reason: there has to be something to manage, bill and build on.

10.2 SA5 — few documents, many documents touched

SA5 filed 36 Ambient IoT documents across 7 meetings and sent no letters at all SA5. Of the working groups that filed anything it is the smallest; below it sit the CT plenary at 31 CT and CT6 at nothing CT6.

It owns seven of the affected specifications, second only to CT4's nine SA5 CT4. Small output, wide reach — which is what management and charging work usually looks like.

10.2.1 Charging

AmbientIoT-CH, unique id 1070018, opened as SP-250369 at plenary SP-107, 15 documents, complete as of 2025-06-06 AmbientIoT-CH SP-250369.

It touches four charging specifications:

  • TS 32.240 TS 32.240 — charging architecture and principles. 3 change requests.
  • TS 32.254 TS 32.254 — charging through the exposure interfaces. 8 change requests.
  • TS 32.291 TS 32.291 — the 5G charging service, stage 3. 3 change requests.
  • TS 32.298 TS 32.298 — the parameters of a charging data record. 3 change requests.

Seventeen change requests in total, spread across the four documents that between them describe how anything in a 5G network gets paid for.

10.2.2 Management

AmbientIoT_Ph2-OAM, unique id 1110042, opened as SP-260311 at plenary SP-111, 15 documents, and running rather than finished AmbientIoT_Ph2-OAM SP-260311.

It touches three management specifications:

  • TS 28.540 TS 28.540 — the 5G network resource model, stage 1. No Ambient IoT documents against it yet.
  • TS 28.541 TS 28.541 — the same model, stages 2 and 3. One change request.
  • TS 28.552 TS 28.552 — the measurements a network reports about itself. 10 change requests.

10.2.3 The charging study that has not started

FS_AmbientIoT_Ph2_CH, unique id 1120102, opened as SP-260656 at plenary SP-112 FS_AmbientIoT_Ph2_CH SP-260656. It has filed nothing and stands at zero, against a target finish of 2026-12-12.

Of the ten studies in this area it is the only one that is not complete [2].

10.2.4 Why charging finished and management did not

The two SA5 items look alike — same group, 15 documents each — and their states are far apart. Charging is complete as of 2025-06-06; management is running with a target of 2027-03-03 AmbientIoT-CH AmbientIoT_Ph2-OAM.

The difference is the release. Charging was Rel-19 work, started once the architecture was settled and finished in a quarter. Management is Rel-20 phase 2 work, started in 2026 and running alongside an architecture that is itself still moving AmbientIoT_Ph2-ARC.

10.3 SA6 — the layer above

SA6 filed 247 documents across 6 meetings, sent no letters, and did not appear until 2025-08-17 — after the architecture was settled SA6.

Its study is FS_AmbientIoT_Ph2_APP, unique id 1080023, opened as SP-250870 at plenary SP-108 FS_AmbientIoT_Ph2_APP SP-250870, and its description says outright what it stands on:

That is the arrival order of this whole area in one sentence: requirements from SA1 and the requirements nobody designed against yet, architecture from SA2 and the specification that did not exist, and only then a layer that applications can use.

The study finished 2026-06-06 and stands complete; its report is TR 23.700-26 with 178 documents against it FS_AmbientIoT_Ph2_APP TR 23.700-26.

The normative work is AmbientIoT_Ph2-APP, unique id 1110048, opened as SP-260315 at plenary SP-111, 74 documents, running rather than finished AmbientIoT_Ph2-APP SP-260315.

SA6 owns four specifications in this area SA6:

  • TS 23.370 TS 23.370 — application enablement for Ambient IoT services. New for this work: 70 documents, no change requests yet.
  • TS 23.434 TS 23.434 — the service enabler architecture layer for verticals. Declared impacted; no Ambient IoT documents against it yet.
  • TS 23.436 TS 23.436 — application data analytics enablement. 4 change requests.
  • TR 23.700-26 TR 23.700-26 — the study report.

10.4 What SA6 is for, in one comparison

The difference between SA6 and the CT groups is worth being clear about, because both sound like "the interface".

CT1, CT3 and CT4 write what network functions say to each other and to a device — stage 3, inside the system CT1, CT3, CT4 and CT6 — one work item description, four groups. SA6 writes what an application outside the system talks to, so that using Ambient IoT does not require speaking core network protocols at all.

That is why its study says it works in "the application enabled layer" and takes both the requirements and the architecture as given [1]. It is a layer on top, not a piece of the middle.

10.5 Why these two chapters' worth of work is easy to miss

SA5 filed 36 documents and SA6 filed 247 SA5 SA6, against 10771 across the whole area [3]. It would be easy to read that as the work not mattering.

It is not what the numbers mean. Charging and management work is thin because it is derivative: once the architecture names a function and a procedure, adding a measurement or a charging record is a small, well-understood edit.

SA5's two work items carry 15 documents each and between them reach seven specifications AmbientIoT-CH AmbientIoT_Ph2-OAM.

The application layer is thin for a different reason: it started a year after everything else, and its main specification has not been through a correction cycle yet TS 23.370.

10.6 Where to read on

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

  • TS 23.370 TS 23.370 — the application enablement specification. Read this if you are writing software that uses Ambient IoT rather than building the network.

  • TR 23.700-26 TR 23.700-26 — the study behind it.

For charging, the entry point is TS 32.240 TS 32.240, the architecture and principles document that the other three sit under. For management, it is TS 28.541 TS 28.541, the resource model in full.

Where the numbers in this chapter come from

  1. what the application enablement study set out to do the first two sentences of section 4 of /var/www/whatthespec.net/data/data/wis/1080023/SP-250870_was_250582_New SID_on_Application_enabler_for_AIoT services_v6/SP-250870_was_250582_New SID_on_Application_enabler_for_AIoT services_v6.md, copied word for word, read 2026-08-04
  2. 10 of them are studies of the work items above, the ones whose acronym starts FS_, which is how 3GPP marks a feasibility study, read 2026-08-04
  3. 10771 Ambient IoT documents rows of `tdoc` in api.sqlite whose work item column names one of the 28 Ambient IoT work item acronyms, read 2026-08-04

Every source this course is built on

Check yourself

Answers appear when you pick one, with where they come from.

Q10.1 What are the three work items SA5 leads?

Q10.2 SA5 filed only 36 documents. How many specifications does it own in this area?

Q10.3 Why can this course not quote an objective for the phase 2 management work?

Q10.4 What is TS 23.370?

Q10.5 What does SA6's phase 2 study say it builds on?

This chapter was built from a source register generated 2026-08-04. A fresher build of the register may hold different numbers.