Ambient IoT - Release 19

Every cellular device so far has had a battery, a power amplifier and an oscillator of its own. Even the smallest NB-IoT module needs them. Ambient IoT (A-IoT) removes all three. An A-IoT device harvests energy from its environment, for example from radio waves, and it answers by reflecting a carrier wave rather than generating its own signal. This is the principle of an RFID tag, now brought into 3GPP and run by a gNB.

Release 19 is the first release with A-IoT specifications. It adds a new radio interface that has almost nothing in common with the NR Uu interface. The interface has its own physical layer in TS 38.291 and its own MAC in TS 38.391, and no RRC, PDCP or RLC at all. It also adds a core network function, the AIOTF, and a set of NGAP procedures between the gNB and the core. This page goes through the architecture, the radio interface, the MAC procedures and the network procedures, in that order. The NGAP side is also listed in the NGAP page.

• What is Ambient IoT and why does 3GPP need it ?
• Architecture - readers, A-IoT Areas and the AIOTF
• Radio interface - R2D and D2R
• A-IoT MAC - paging, access and data transfer
• Inventory and command procedures over NG-C
• What Release 19 does not cover
• Reference

What is Ambient IoT and why does 3GPP need it ?

Why would a cellular standard want a device with no battery ? The target is a very large number of very cheap objects: parcels, pallets, tools, items in a warehouse or a shop. For those objects, a battery is a problem in itself. It costs more than the tag, it needs replacement, and it limits where the tag can be used. Passive RFID solved this long ago, but an RFID system is a separate network with its own readers, and its range is short.

A-IoT tries to reuse what operators already have. The reader function sits in a gNB, the radio spectrum is the operator's, and the device identity and the service are managed by the 5G core. The device side stays extremely simple. It wakes up when it has collected enough energy, listens for a message from the reader, and answers by backscattering. 38.300 describes the device link exactly that way: the device-to-reader transmission is based on backscattering on a carrier wave, and the carrier wave is a single-tone sinusoid.

So the device does not need a power amplifier or an accurate oscillator. The price is a very low data rate, a short range compared with NR, and a very limited set of procedures. A-IoT is meant for identification and short commands, not for data sessions.

• Batteryless: the device works only while it has enough harvested energy. 38.300 says that a device monitors the reader-to-device message as long as it has sufficient energy.
• Backscatter uplink: the device modulates a reflected carrier wave instead of transmitting its own signal.
• Two services: inventory, which finds and identifies devices, and command, which sends an instruction to one device and gets its response. Both are defined at service level in TS 23.369.
• Operator managed: the reader is a gNB, and the devices are known to the 5G core through the AIOTF.

Architecture - readers, A-IoT Areas and the AIOTF

Where does the reader sit, and how does the core network reach it ? In Release 19 the answer is fixed: the A-IoT reader is a gNB-reader, which means a reader function inside the gNB. One gNB can serve one or several readers, and each reader belongs to exactly one gNB. A gNB can support both NR and A-IoT, or A-IoT only. The NGAP IE A-IoT Support in NG SETUP REQUEST has the values aIoT-only and aIoT-and-NRUu for this.

On the core side, a new function manages the service, the AIOTF (Ambient IoT Function). The gNB reaches it in one of two ways. With direct connectivity, the gNB connects to the AIOTF itself. With indirect connectivity, the gNB connects to the AMF, and the AMF passes the A-IoT information through transparently. 38.300 calls whichever node the gNB talks to the A-IoT CN node. A deployment with both kinds of connectivity is not expected. Figure 1 shows the structure.

Figure 1. A-IoT architecture in Release 19. The readers are inside the gNB, the A-IoT Areas group readers for the core network, and the AIOTF is reached either directly or through the AMF.

The AIOTF does not address devices by cell. It asks for an operation in a requested service area, given as a list of A-IoT Areas, a list of readers, or both. An A-IoT Area is a group of readers, identified by an A-IoT Area ID built from the PLMN identity and an A-IoT Area Code. An area can include readers of different gNBs, and one reader can belong to several areas. All of these mappings are OAM configuration, both in the gNB and in the AIOTF.

• gNB-reader only: in this release the reader is always part of a gNB. Other reader types are not specified.
• NG-C carries everything: A-IoT information between the gNB and the core uses the normal NG-C protocol stack. There is no A-IoT user plane.
• No Xn and no split gNB: gNBs do not exchange A-IoT information, and the CU/DU split is not supported for A-IoT.
• Area based addressing: the core works with A-IoT Areas and Reader IDs, never with NR cells.

Radio interface - R2D and D2R

What does the air interface look like, given that the device has almost no hardware ? The two directions are very different. In R2D (reader to device), the gNB has all the power and complexity it needs, but the receiver is an envelope detector in a tag. In D2R (device to reader), the device can only change how it reflects a carrier wave. So 3GPP designed each direction around the weak end. The AS protocol stack has only two layers, A-IoT MAC and A-IoT physical layer, and there is no split between control plane and user plane.

The R2D design is the more interesting one for an NR engineer. The gNB transmits OOK, simple on and off keying that an envelope detector can receive, but it builds the OOK out of DFT-s-OFDM symbols. For in-band operation, an R2D transmission starts aligned with an NR OFDM symbol. So an A-IoT reader can share a carrier with NR, and the OOK signal fits into the NR resource grid. Inside each OFDM symbol, the signal is divided into chips, and the data is line encoded on them. The subcarrier spacing and the number of resource blocks are defined in TS 38.291, which this page does not quote. The carrier wave for D2R is not described as a device function. My understanding is that the reader side provides it in Release 19, but I have not confirmed this in TS 38.291.

The device has no accurate clock, so every R2D transmission carries its own timing. The R-TAS (R2D timing acquisition signal) comes immediately before the PRDCH. Its start indicator part (SIP) tells the device that a transmission begins. Its clock acquisition part (CAP) tells the device the number of chips per OFDM symbol and the chip duration. The device therefore learns the clock from each message, instead of keeping one.

• OOK inside OFDM: the R2D signal is OOK for the device, and OFDM for the gNB and for coexistence with NR.
• Timing in every message: R-TAS gives both the start and the chip clock, because the device cannot keep time between messages.
• Small frequency shift: the D2R modulation results in a small frequency shift from the carrier wave, which lets the reader separate the backscattered signal from the carrier.
• Optional coding: D2R channel coding may be omitted, and block repetition provides robustness instead.
• Carrier wave source: 38.300 describes the carrier wave as a single-tone sinusoid but does not say in this clause which node transmits it. This page does not verify it against TS 38.291.

A-IoT MAC - paging, access and data transfer

How does a reader talk to one device among hundreds in front of it ? The device has no context, no connection and no identity known to the RAN in advance. So every exchange starts from paging, then an access procedure to sort out the devices, then one data transfer. The A-IoT MAC in TS 38.391 handles all three, as well as padding, D2R segmentation and failure detection.

A-IoT paging is transmitted on PRDCH. It can address one device, a group or all devices. It carries zero or one paging identifier, which is a permanent device identifier, a temporary identifier or filtering information from TS 23.369. With no identifier, the paging message addresses all devices. The paging message also carries the configuration for the access that follows, and it says whether the device uses contention-based random access (CBRA) or contention-free access (CFA). Figure 2 shows the CBRA case.

Figure 2. A-IoT CBRA. The random ID plays the role of the RACH preamble and the contention resolution identity at once. With CFA, the paging message already gives the dedicated resource and the device sends its data directly.

• Access occasions: the paging message configures the occasions, and the device picks one at random. Access Trigger messages mark the start of each occasion. The first set of MSG1 resources is indicated by the paging message itself.
• Contention resolution: it succeeds when MSG2 carries the same random ID as MSG1, and the same frequency index if one is present. Otherwise the device waits for a paging message with the same transaction ID and tries again.
• CFA: the paging message gives a dedicated resource, the device sends its data in it, and it does not monitor Access Trigger messages.
• AS ID: the reader addresses a device by its AS ID after access. MSG2 can assign one, or tell the device to reuse its random ID. A device keeps at most one AS ID, and loses it when it runs out of energy, receives a NACK, or receives certain new paging messages.
• Segmentation: D2R data, except an inventory response, can be segmented to fit the scheduled TB size. R2D data is never segmented.

One detail shows how far A-IoT goes to keep the device simple. A device can answer with a D2R Upper Layer Data Transfer that carries no data, and an indication says why. Either the upper layer response is not ready yet, or the device ignored the message. In the first case, the reader can come back later with a follow-up R2D message to schedule another D2R transmission. The device therefore never has to buffer a request and decide when to send. Compare this with the NR random access in the RACH page, where the UE drives the timing.

Inventory and command procedures over NG-C

The radio procedures above only run when the core network asks for them. A-IoT has no device-initiated traffic in Release 19. Every exchange is either an inventory, which finds devices and reports their identities, or a command, which sends something to one device that an inventory has already found. Both are NGAP procedures between the A-IoT CN node and the gNB, defined in 38.413 clause 8.20.

An inventory starts with INVENTORY REQUEST. It identifies the session by a Correlation ID and the AIOTF Identifier. It says which devices are targeted, a single device, a group or all. It also gives the requested service area, inventory assistance information such as the expected D2R message size, and security information. If a command will follow, a follow-on command indicator is included. The gNB answers with INVENTORY RESPONSE, runs paging, access and data transfer, and sends one or more INVENTORY REPORT messages with the A-IoT NAS PDUs that carry the device IDs.

A command always addresses one device. If the inventory request had the follow-on indicator, each report gives a RAN A-IoT device NGAP ID per inventoried device. The CN node then sends COMMAND REQUEST with that ID and the A-IoT NAS PDU for the device, and the gNB returns the device's NAS PDU in COMMAND RESPONSE. When all commands of the session are done, or when there is no follow-on command at all, the CN node releases the session with AIOT SESSION RELEASE COMMAND.

• NAS end to end: the device identity and the command content travel as A-IoT NAS PDUs. The gNB only carries them.
• Correlation ID: one ID ties together the inventory, its reports, the commands and the release of one session.
• Location by reader: the gNB reports device location at Reader ID granularity in the inventory report. There is no finer positioning in this release.
• NG setup: a gNB announces A-IoT support in NG SETUP REQUEST, and the AIOTF identifier and name can appear in NG SETUP RESPONSE. The listings are in the NGAP page.

What Release 19 does not cover

Release 19 A-IoT is a first step, and the specification states several of its limits openly. They matter when reading product claims, because a feature that sounds natural for a tag system may simply not exist yet in 3GPP. The phrase "in this release" or "in this version of the specification" appears throughout 38.300 clause 16.23, and each occurrence marks such a limit.

• Reader type: only the gNB-reader. A reader in a UE or a separate reader node is not part of this release.
• No inter-gNB support: no A-IoT signalling over Xn, so there is no coordination between readers of different gNBs on the radio side.
• No split gNB: a gNB with a CU/DU split cannot be an A-IoT gNB in this release.
• Parallel requests: a device is not expected to handle parallel service requests from overlapping readers. The network has to avoid them by implementation.
• Network-initiated only: every exchange starts with an inventory or command request from the core. The device never starts one itself.
• Coarse location: device location is known only at reader level.
• Security scope: the security specification, TS 33.369, is titled for isolated private networks. The title suggests that the Release 19 security framework targets that deployment. This page has not checked the content of TS 33.369.

The overall Release 19 content is summarised in the Release 19 page.

Reference

• 3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 16.23, Support of Ambient IoT
• 3GPP TS 38.291 : Ambient IoT Physical Layer
• 3GPP TS 38.391 : Ambient IoT Medium Access Control Protocol specification
• 3GPP TS 38.413 V19.4.0 : NG-RAN; NG Application Protocol (NGAP). Clause 8.20 and clause 9.2.19, A-IoT procedures and messages
• 3GPP TS 23.369 : Architecture support for Ambient power-enabled Internet of Things
• 3GPP TS 33.369 : Security aspects of Ambient Internet of Things (AIoT) services for isolated private networks
• NGAP, RACH, Release 19 (ShareTechnote)