2 What an Ambient IoT system is made of

2.1 Why the tag is the smallest part of it

A tag with no battery decides nothing and reaches nobody. Everything it does is done to it.

So the architecture document gives the system four jobs and builds the parts that carry them out: identify a device, take an inventory, move application data to and from one, disable one for good §4.1. That takes nine parts, of which the tag is only the first §4.5.1.

Two are missing. The UDR is left off for clarity and the document says so §4.2.2.1; the carrier-wave node, because it is not a core function.

2.2 The parts that did not exist before

The AIoT device is the tag: an IoT device powered by energy harvesting, with limited energy storage §3.1. It speaks AIoT NAS, a signalling language of its own, to one core function, and the AIoT radio to a nearby reader §4.5.1.

The AIOTF, the Ambient IoT Function, is that core function, and every exchange is run from it: it terminates AIoT NAS, triggers the base station to carry out an operation, selects that base station and optionally the readers, allocates the Correlation ID that ties a request together, and reports results §4.5.3.

The ADM, AIoT Data Management, is the store: the tag's profile, its credentials, and which application may do what §4.5.9.

The carrier-wave node is the odd one out. The cheapest tag never transmits; it reflects a plain tone, and this node sends it. Its radio requirements are in TS 38.194, and no clause of the architecture document mentions it — equipment, not a core function.

2.3 The 5G parts given a new job

NG-RAN is 3GPP's name for the base station, and here one that supports Ambient IoT — which the document lets it do and nothing else §4.2.1. The radio itself belongs to TS 38.300.

The AMF — the function that keeps track of where a device is — relays §4.5.7. The NEF is the front door for an application outside the operator, and authorises the untrusted ones §4.5.4; the AIOTF authorises a trusted one §4.5.3.

The NRF is the directory core functions find each other in, and it learns two new function types §4.5.6. The UDR, the general subscriber store, may hold what the ADM manages §4.5.8. The AF is the application doing the asking §4.5.5.

2.4 Two ways to build a reader

• The reader lives in the base station. The AIOTF reaches it straight over its own reference point, AIOT2, or through an AMF §4.2.2.1.

• A phone is the reader. The tag talks to the phone, the phone to the base station, and base station and AIOTF are always joined by an AMF §4.2.3.

A phone has to be allowed to do it: its subscription carries the permission, the AMF weighs that against what the phone can do and tells the base station §5.14. The bit it says it with is in TS 24.501.

2.5 What was deliberately not built

There is no user plane. Application data sits on top of AIoT NAS, and the base station carries those messages through without looking §4.6.2.2. A read or a write names an offset and a length in the tag's memory, and no network function tries to interpret what it carries.

No PDU session, no quality-of-service settings, no SMF, no UPF, no policy function and no charging function appears anywhere in it. The study behind it found a PDU session with quality flows unsuitable for devices this constrained TR 23.700-13.

2.6 Where this goes next

Knowing the parts is not knowing the order they speak in: that is the inventory §6.2.2.1 and command §6.2.3.1 procedures, and How a tag is actually read, from the request to the answer walks through both. What the exchange protects, and what it does not, is What the security protects, and what it leaves open on purpose.