Ambient IoT in 3GPP Release 19 vs Release 20: Battery-Free Device Architecture for 2026 and Beyond

Almost everything written about Ambient IoT 3GPP work treats it as a battery story: tags that never need replacing, therefore trillions of them. That framing is wrong in a way that will cost engineering teams real money. A device that draws roughly a microwatt and stores no meaningful charge is not a low-power device — it is an intermittently powered one, and intermittent power is a computing problem long before it is a radio problem. 3GPP did not solve it by making the radio more efficient. It solved it by deleting most of the protocol stack, moving the transmitter off the device entirely, and redefining what a “session” means. Those three decisions propagate upward into your site plan, your identity model, your security posture and your application semantics.

What this covers: what Release 19 actually froze, what Release 20 is adding, the mechanisms behind each choice, and an honest boundary analysis against passive UHF RFID on one side and NB-IoT on the other.

Context and Background

3GPP has shipped low-power wide-area IoT before. NB-IoT and LTE-M, introduced in Release 13 and refined across every release since, brought cellular connectivity down to coin-cell and primary-battery budgets by trading throughput for coverage and adding sleep mechanisms such as PSM and eDRX. Those technologies work, they are deployed commercially, and they still assume a device that owns a battery, owns a transmitter, and can wake itself on a schedule. If you are choosing between them today, our LoRaWAN vs NB-IoT vs LTE-M comparison for industrial IoT covers that decision in detail.

Ambient IoT targets the tier below. 3GPP’s own framing is explicit: the new technology aims for complexity and power consumption “orders-of-magnitude lower” than existing 3GPP LPWA technologies, addressing use cases those technologies cannot fulfil, according to the Release 19 Ambient IoT technology page authored by the RAN1 A-IoT rapporteurs. That is not marketing hedging. It is a statement that the design point is discontinuous, not incremental.

The work arrived through an unusually long runway. SA1 studied use cases, traffic types, service requirements and KPIs in Release 18, captured in TR 22.840. In parallel, a RAN plenary-level feasibility study produced TR 38.848, which established deployment scenarios, topologies and design targets. Release 19 then ran a RAN working-group study on radio solutions, captured in TR 38.769, alongside architecture work in SA2 (TR 23.700-13) and security and privacy work in SA3 (TR 33.713). The RAN1 Release 19 work item followed, and the normative output now exists as a small, purpose-built specification family rather than as amendments to the NR specs: TS 38.191 for Ambient IoT device radio transmission and reception, TS 38.291 for the Ambient IoT physical layer, TS 38.391 for the Ambient IoT MAC protocol, and TS 38.195 for base-station and carrier-wave-node conformance testing.

That last document is the tell. 3GPP wrote a conformance specification for a carrier-wave node — a network element that is neither a base station nor a device, whose only job is to radiate an unmodulated tone. No other 3GPP radio technology has needed such a thing. It exists because in Ambient IoT the uplink transmitter is not on the device.

Outside 3GPP, the same design space is being worked by IEEE 802.11bp, which defines ambient power communication for energy-harvesting stations, and promoted by the Ambient IoT Alliance, launched on 19 February 2025 with founding members including Atmosic, Infineon, Intel, PepsiCo, Qualcomm, VusionGroup and Wiliot. Multiple standards are converging on the same physics from different directions, which matters for the fit analysis later in this post.

Ambient IoT Is an Intermittent Computing Problem Pushed into the RAN

Ambient IoT in 3GPP Release 19 standardises a battery-free “device 1” that harvests ambient energy, receives using a simple RF envelope detector, and transmits only by reflecting and modulating a carrier wave supplied by the network. Because the device cannot hold state or power across reads, 3GPP removed RRC, PDCP, SDAP, ARQ, mobility and access-stratum security from the stack entirely.

That deletion list is the whole story compressed into one sentence. Every protocol layer that 3GPP removed was removed for the same reason: it assumes continuity. RRC assumes a connection that survives between messages. PDCP assumes sequence numbers that survive. AS security assumes keys and counters that survive. ARQ assumes a retransmission buffer that survives. On a device whose energy store empties within a single exchange, nothing survives. So the engineering question is not “how do we make these layers cheaper?” but “what can a system do when the endpoint forgets everything between one read and the next?”

Figure 1: The Release 19 Ambient IoT reference architecture — deployment scenario 1 with topology 1, where an indoor base station acts as reader and a separate carrier-wave node supplies the uplink tone.

The diagram shows five distinct planes that most block diagrams of “battery-free IoT” collapse into two. An application or application function issues a request to the Ambient IoT Function (AIOTF), a new core network function introduced for this feature. The AIOTF can reach the RAN directly or indirectly via the AMF, and it terminates the NAS protocol with the device. The base station acts as the reader, sending reader-to-device (R2D) traffic in downlink spectrum. A carrier-wave node — which may or may not be co-located with the reader — radiates an unmodulated tone in uplink spectrum. The device reflects that tone back, modulated with its data, as device-to-reader (D2R) traffic, also in uplink spectrum. Release 19 scopes this to FR1 licensed FDD spectrum, with the R2D link in the downlink band and both the D2R link and the carrier wave in the uplink band.

The device-1 contract Release 19 actually froze

Release 19’s normative objective is narrow and precisely specified. The device is characterised on 3GPP’s own technology page as having approximately 1 µW peak power consumption, some energy storage, an RF envelope-detector receiver, an initial sampling frequency offset of up to 105 ppm, and neither R2D nor D2R amplification. Its D2R transmission is backscattered on a carrier wave provided externally.

Read that 105 ppm figure carefully, because it is the parameter that shapes the physical layer. A sampling-frequency offset of 105 parts per million is enormous by cellular standards, where a conventional NR UE is held to a carrier-frequency accuracy orders of magnitude tighter than that. That tolerance is not sloppiness, it is a cost decision: it permits components with wide manufacturing tolerances and wide variation across temperature, which is what gets the bill of materials down to the point where tagging individual items is conceivable. But a receiver that cannot trust its own clock to better than one part in ten thousand cannot decode OFDM, cannot maintain a frame timing grid, and cannot be assigned a periodic occasion. Everything downstream follows.

So R2D uses square-wave on-off keying with Manchester line coding. Manchester coding guarantees a signal transition in every symbol, which gives the device’s receiver a continuous stream of edges to re-time against the base station’s high-quality clock. 3GPP’s rapporteurs make the consequence explicit: this removes any need for absolute synchronisation between reader and device. The device never holds a timebase — it borrows one, symbol by symbol, from the incident waveform. That is intermittent computing expressed as line coding.

The reader still generates R2D from an OFDM transmitter, purely so the waveform can be co-generated conveniently alongside normal NR traffic. From the device’s side it is just amplitude. And there is no channel coding at all in R2D, because forward-error-correction decoding is processing load the device cannot afford. D2R goes the other way: it uses the LTE convolutional code, because the decoding burden lands on the base station, which has power to spare. That asymmetry — no coding toward the device, real coding away from it — is a clean illustration of how an intermittent endpoint forces every cost onto the infrastructure side.

Why the carrier wave is a separate node, and why that is a site-planning problem

A backscatter device does not generate a radio signal; it changes how much of an incident signal it reflects. Power consumption is therefore dominated by the receiver front end and the digital logic, not by a power amplifier. Remove the transmitter and you remove the single largest energy draw in a conventional radio. That is where the orders-of-magnitude reduction comes from.

The bill is not waived, though — it is moved. Someone has to radiate the carrier. 3GPP’s TSDSI-authored technology article distinguishes the two topologies cleanly: in monostatic operation, the reader node serving a device also provides the carrier wave; in bistatic operation, the carrier-wave source is a different node from the reader. Monostatic is simpler to deploy and harder to build, because the reader must receive a faint reflected signal while simultaneously transmitting a strong tone in the same band — a self-interference problem that RAN4 studied explicitly under the heading of carrier-wave interference cancellation feasibility. Bistatic splits the problem across two boxes and buys link budget, but it turns a single-radio deployment into a two-radio deployment whose geometry you must now plan.

This is the part that surprises network teams. With Wi-Fi or NB-IoT you plan coverage: one transmitter, a path-loss model, a signal-strength contour. With bistatic Ambient IoT you are planning an illumination field and a reception field separately, and a tag is only readable where the two overlap adequately. Move a pallet two metres and it may sit in carrier shadow while remaining in perfect reader coverage. The design target discussion in TR 38.848 gives a sense of the scale involved — as summarised in the survey “Challenges and Advances in Ambient IoT within 3GPP”, the study examined device 1 at around 1 µW and a device 2 class at a few hundred µW, with maximum-distance targets in the region of 10–15 m and 15–50 m respectively. Treat those as study-phase design targets, not product specifications; the point is the order of magnitude. You are planning at room scale, not at cell scale.

What the protocol stack deleted, and what replaced it

3GPP’s rapporteurs list the removals in both directions. At layer 1, neither R2D nor D2R has scrambling, interleaving, MIMO, separate control channels, or L1 HARQ, and the signal designs avoid complex numbers entirely — the device works in real arithmetic on square waves. At layers 2 and 3, the vast majority of the conventional stack is gone: no RRC, no PDCP, no SDAP, no ARQ, no mobility, no access-stratum security.

One concept survives: paging. The network indicates the beginning of an inventory process, and devices respond. The access scheme is network-triggered throughout — a device only ever speaks after the reader has spoken. This is why the supported traffic types are device-terminated (DT) and device-originated-device-terminated-triggered (DO-DTT), while device-originated autonomous (DO-A) traffic is explicitly not supported in Release 19, because autonomous active transmission in D2R is not supported.

That single exclusion is the most consequential fact in the entire specification for application architects, and it is routinely glossed over in vendor material. A Release 19 Ambient IoT device cannot tell you that something happened. It can only answer when asked. Every event-driven pattern you would naturally reach for — threshold alarms, tamper detection, cold-chain excursion alerts — has to be re-expressed as a polling problem, where the latency floor is set by how often you can afford to run an inventory round, not by the sensor.

Multiplexing follows the same asymmetry. R2D supports TDMA only: the reader can vary the R2D data rate by modulating the OOK square wave faster or slower, but frequency-division multiplexing is impossible because the device’s envelope detector is wideband and cannot select a subchannel. D2R can do FDMA, and the mechanism is elegant — the line code effectively repeats an information bit at a faster rate, producing a higher-frequency square wave, so devices can be separated by their repetition rate. That gives the reader the parallelism it needs for what the 3GPP rapporteurs describe as an inventory procedure with hundreds of devices to read in a few seconds.

Release 19 vs Release 20: What Is Frozen and What Is Coming

Release 19’s RAN1 functional freeze landed in June 2025, with RAN2, RAN3 and RAN4 following in September 2025, per the TSG RAN chair’s Release 19 status article. The Ambient IoT work item that met those dates was deliberately minimal in scope: two representative use cases from TR 38.848 — indoor inventory (rUC1) and indoor command (rUC4) — under deployment scenario 1 with topology 1, abbreviated D1T1, meaning both the device and the base-station reader are indoors and the device communicates directly and bidirectionally with the base station.

Figure 2: The intermittent-execution loop. A device charges, crosses a threshold, wakes, decodes, responds, and browns out — losing all volatile state on every cycle. Only non-volatile identity survives.

Figure 2 is the mechanism that dictates everything in the two tables below. The device harvests until stored energy crosses a wake threshold, powers its logic and envelope detector, decodes an R2D command, matches a mask or reads non-volatile memory, backscatters a response, and then browns out. Volatile state is lost on every cycle. Non-volatile memory holds the identifier and perhaps a small counter. Any protocol that needs the device to remember something between two brownouts must either write it to non-volatile memory — which costs energy and endurance — or not exist.

The Release 19 scope was set so that this loop is the only loop. Release 20 widens it along three axes that were studied but not standardised in Release 19.

Dimension	Release 19 (normative)	Release 20 (direction)
Device class	Device 1 — backscatter only, no amplification, ~1 µW peak	Device 2a with reflection amplifier; device 2b with internally generated active transmission
Topology	Topology 1 — device communicates directly with the BS reader	Topology 2 — an intermediate UE acts as reader, relaying to the BS, under network control
Scenario	Deployment scenario 1 — device and BS reader both indoors	Additional scenarios studied in TR 38.848
Spectrum	FR1 licensed FDD; R2D in DL band, D2R and CW in UL band	Expected to build on the same FR1 FDD baseline
Traffic types	DT and DO-DTT; DO-A not supported	Active D2R transmission opens the door to autonomous traffic for device 2b
Receiver	RF envelope detector	Zero-IF / IF receivers characterised in the study as offering better link performance

The 3GPP technology page states the direction plainly: the study generated a reference architecture for device 1, more advanced devices were also studied — adding a reflection amplifier (2a) and very low-cost active devices (2b) — and standardisation of some of those concepts is targeted for Release 20. On topology, it is more cautious: topology 2, where intermediate UEs function as readers relaying to a base station, is not included in Release 19, and its potential incorporation in Release 20 could expand the application scope. Treat topology 2 as an intention, not a commitment.

The release-level timing is published on 3GPP’s Release 20 page. Release 20 is the final “5G-Advanced only” release, with an 18-month roadmap: Stage 1 service requirements froze in June 2025; Stage 2 system architecture has a two-tier timeline with 80% completion anticipated by June 2026 and a final freeze in September 2026; Stage 3 protocol details target March 2027, with the ASN.1/OpenAPI freeze in June 2027. Those are release-level milestones, not feature-level guarantees for Ambient IoT specifically — 3GPP’s March 2026 work plan reported 126 work items and 74 study items for 5G-Advanced in Release 20, and individual features can and do slip within that envelope. Do not build a procurement plan on a per-feature date that 3GPP has not published.

Why device 2a and 2b are a different engineering problem, not a bigger one

It is tempting to read the device ladder as a performance dial. It is not. Each rung changes the failure model.

Device 1 has no amplifier anywhere. Its reflected signal is attenuated on both the incident and the return path, so path loss is effectively squared relative to a one-way link. That is the fundamental reason the range targets sit at room scale.

Device 2a inserts a reflection amplifier: the device still does not generate a carrier, but it amplifies what it reflects. That buys return-path gain at the cost of an active component that must be powered during the response — which means the device now needs enough stored energy to hold an amplifier biased for the duration of a backscatter burst, not merely enough to switch an impedance. The energy store stops being a decoupling capacitor and starts being a budget you must size against burst length.

Device 2b generates its own signal. At that point the device is a very low-cost active radio with an energy-harvesting front end, and the carrier-wave node is no longer required for its uplink. It gains the possibility of autonomous transmission, and with it the entire set of problems Release 19 avoided: when does it transmit, how does it avoid colliding with devices it cannot hear, how does it know the network is listening. 3GPP’s own framing is that active D2R transmission with internally generated signals can provide superior coverage performance, and that Zero-IF/IF receivers exhibit better link performance than RF envelope detectors — while remaining orders of magnitude below LPWA power levels.

The practical consequence for anyone specifying hardware in 2026: a device-1 deployment and a device-2b deployment are not the same product with a different radio. They have different site plans (carrier-wave node required or not), different application patterns (polled only, or possibly event-driven), and different security envelopes. Plan them as separate programmes.

Walking the Read Path: Inventory, Identity and Security Under Intermittency

The clearest way to see what Ambient IoT really imposes is to trace a single inventory round end to end and ask, at each step, what state exists and where it lives.

Figure 3: An inventory round. The application asks the AIOTF for devices matching an identifier mask; the reader triggers, the carrier-wave node illuminates, and matched devices contend for slots using slotted ALOHA.

Figure 3 traces the request from application to device and back. The application issues an inventory request carrying an identifier mask. The AIOTF, which manages the services relating to triggering RAN operations and the transfer of information between an application and the RAN or device, instructs the reader. The reader requests carrier wave and issues a trigger to the population, including the mask and the contention parameters. Matched devices reply in randomly chosen slots. The reader resolves collisions, addresses individual devices, collects identifiers or stored information, and returns an aggregated result.

Identity is structured, and that is the feature

Each Ambient IoT device is allocated a globally unique permanent device identifier, and 3GPP’s design gives that identifier internal structure: it has several parts which can correspond to, for example, a PLMN ID, an information type ID, and an electronic product code (EPC). The core network can then indicate different matching masks to address subsets of the population, and only the matched devices respond.

This is a much bigger deal than it sounds. In a conventional IoT system, filtering happens after data arrives — you read everything and query it. Here, filtering happens in the air, before any energy is spent. If a warehouse holds 40,000 tagged items and you need the 600 belonging to one product class, masking means 39,400 devices never respond, never contend for a slot, and never consume a round’s worth of airtime. Given that the scarce resources are round duration and collision probability, not bandwidth, mask design becomes a first-class performance decision — and it is determined by how you structured your identifier space at manufacture, which is a decision you cannot revisit in the field.

The deeper architectural point is that the identifier structure is where 3GPP’s telecom identity model and the supply-chain world’s product-coding model meet. A field corresponding to an EPC inside a 3GPP permanent device identifier is a deliberate bridge to the GS1 ecosystem. Teams that already run item-level coding should treat identifier-space design as a joint exercise between their network architects and whoever owns their product-coding scheme, because the mask granularity you get is exactly the granularity you encoded.

Contention is slotted ALOHA, with all that implies

D2R access is based on slotted ALOHA — a long-established protocol providing simple randomisation and back-off among multiple addressed nodes contending in the time domain — with a contention-free mode available when a particular device is targeted. This is the same family of anti-collision mechanism that passive RFID has used for two decades, and it comes with the same well-understood behaviour: throughput rises with offered load up to a point and then collapses, and the operating point depends on how well the reader’s slot-count parameter matches the actual population size.

Here is where intermittency bites in a way pure RFID does not experience. In an Ambient IoT population, a device may be unavailable at the moment it is addressed — not because of collision or path loss, but because its energy store has not yet recharged from the previous round. The reader’s model of “how many devices are out there” and the reader’s model of “how many can answer right now” diverge, and the divergence depends on the harvesting environment. This is an active research area; the arXiv preprint “Fast Inventory for 3GPP Ambient IoT Considering Device Unavailability due to Energy Harvesting” is a good entry point for the modelling, and the existence of that literature should tell you that “how long does a full read take” does not have a single answer you can put in a requirements document.

The practical guidance is uncomfortable but honest: design your application so that a single inventory round returning a subset is normal, not exceptional. Reads are statistical. Build convergence over several rounds into the business logic rather than treating a partial read as an error condition.

Security has to be redesigned, not scaled down

Access-stratum security does not exist in Release 19 Ambient IoT. The NAS protocol terminates at the AIOTF, so whatever protection exists lives above the radio. SA3’s study, TR 33.713, covered privacy, authentication, authorisation, integrity, confidentiality and anti-replay with the stated intent of reaching a security level comparable to existing 3GPP features, acknowledging that device capabilities vary with constraints and deployment scenario.

Reason from first principles about why this is hard, and be sceptical of anyone who claims it is solved. Conventional cryptographic handshakes assume the endpoint can perform several round trips, maintain a session state across them, and hold a monotonic counter to defeat replay. An intermittently powered device may brown out mid-handshake, and on wake it has no memory of where it was. Anti-replay in particular requires persistent, monotonic state — and every write to non-volatile memory costs energy the device may not have and endurance cycles it cannot spend freely. Infineon’s Embedded World 2026 session on Ambient IoT security stated the constraint directly: limits on power storage capacity and uncertain power availability make it difficult to engage in conventional cryptographic exchange protocols.

There is also a privacy dimension unique to this tier. A population of tags that answers any correctly formed trigger is a population that can be inventoried by anyone with a reader, which is precisely the unlinkability problem that has dogged passive RFID since the beginning. Masking makes it worse in one respect — a structured identifier leaks classification information even to an observer who cannot resolve an individual device. If you are deploying into a consumer-facing context, treat identifier-space design as a privacy decision as much as a performance one.

Where Ambient IoT Does Not Fit

This section exists because the honest boundary is narrower than the marketing. Ambient IoT does not replace passive UHF RFID and does not replace NB-IoT. It sits between them, and the gap it occupies is real but specific.

Figure 4: A fit test. Reader proximity, the need for licensed spectrum and operator-managed identity, and the need for autonomous reporting are the three questions that decide the technology.

Figure 4 encodes three questions in the order they actually discriminate. If a handheld or fixed portal reader is operationally acceptable, passive UHF RFID is almost always the cheaper and more mature answer. If it is not, the next question is whether you need licensed spectrum and operator-managed identity — the things RFID cannot give you. And if you do, the last question is whether the application needs autonomous reports or actuation, because Release 19 Ambient IoT cannot provide either.

Against passive UHF RFID (EPC Gen2 / ISO/IEC 18000-63)

Passive UHF RFID is a mature, globally deployed technology. The GS1 EPC Gen2 air interface, harmonised internationally as ISO/IEC 18000-63 and updated to Gen2v3 in 2024, already does battery-free item-level identification at scale with a slotted-ALOHA anti-collision algorithm, standard memory banks, and a supply chain of tags costing a few cents. The GS1 Gen2 standard reference is the primary source. If you are choosing today for a portal-read or handheld-read workflow in a retail or logistics setting, RFID wins on cost, on tooling, on installed base, and on the fact that it exists commercially right now.

What Ambient IoT offers that RFID does not is integration into the cellular system: licensed spectrum with managed interference, an operator-grade identity and authorisation model terminating in the core network, reuse of base stations as readers rather than a dedicated reader fleet, and a path to devices that are more than passive reflectors. What it does not offer is a cost or maturity advantage. Anyone telling you Ambient IoT will be cheaper than a Gen2 inlay is making a claim with no public evidence behind it.

Two structural differences matter more than the feature comparison. First, RFID readers are yours — you deploy them, you control their density, you place them exactly where the read must happen. Ambient IoT readers are base stations, which sit where radio planning put them, not where your process needs a read point. Second, RFID is unlicensed and therefore deployable by anyone, anywhere, today; Ambient IoT in Release 19 is specified for FR1 licensed FDD spectrum, which means it is an operator-mediated service in most jurisdictions. That is a commercial and regulatory dependency, not a technical one, and it is the dependency most likely to determine timelines.

Against NB-IoT and LTE-M

At the other boundary, the comparison is about what the device can do, not how long it lasts. An NB-IoT device owns a transmitter and a battery, so it can wake on a timer, sample a sensor, decide something happened, and initiate an uplink. It can hold a security context, run a full authentication, accept a firmware update, and be addressed at any time. It can operate outdoors over kilometres.

A Release 19 Ambient IoT device can do none of those things. It cannot initiate. It cannot reliably hold state across reads. It has no access-stratum security. It has no firmware-update path worth the name — flashing new code into a device that browns out unpredictably, with no ARQ and no reliable session, is not a problem anyone has demonstrated a clean answer to, and you should assume a Release 19 device is functionally immutable once deployed. It works at room scale indoors.

So the patterns that fit are the ones that reduce to condition at the moment of read: presence, absence, count, location-by-reader-association, and simple stored or sampled state returned on demand. The patterns that do not fit are periodic telemetry at a rate the application chooses, alarm-on-threshold, closed-loop actuation, and anything requiring a field-updatable endpoint. If your requirement contains the word “alert”, Release 19 Ambient IoT is the wrong tier — and if your requirement contains “deterministic”, you are in an entirely different part of the design space covered in our TSN vs 5G URLLC deterministic networking comparison.

The honest third answer

There is a category of deployment where neither answer is right and the correct decision is mains power or wiring. If a sensor needs to report every thirty seconds, forever, in a fixed location where power already exists, harvesting is an unnecessary constraint. The energy-autonomy story is compelling precisely where wiring is impossible or maintenance is prohibitive — inside sealed assets, across large mobile populations, in places where a battery change means taking a machine out of service. Outside that envelope, battery-free is an aesthetic preference with an engineering cost.

Trade-offs, Gotchas, and What Goes Wrong

Carrier-wave geometry is the failure mode nobody plans for. In bistatic deployments a device must sit in adequate illumination and adequate reader reception. Read failures will cluster spatially in ways that look random to an application team and obvious to anyone holding a floor plan. Instrument read success by physical location from day one, not by device ID.

Self-interference limits monostatic deployments. A reader transmitting a strong tone while receiving a faint reflection in the same band is a hard analogue problem, which is why RAN4 studied carrier-wave interference cancellation feasibility explicitly. Assume monostatic performance is worse than bistatic until a vendor shows you measurements on their hardware.

Coexistence is feasible but not free. RAN4 evaluated coexistence between Ambient IoT and NR across 36 interference cases, focusing on outdoor macro base stations with an indoor Ambient IoT system, and concluded coexistence is feasible — with the caveat that in some cases interference is negligible while in others it is observed and mitigation mechanisms are required. “Feasible with mitigation” is a very different planning input from “no interaction”.

Partial reads are normal, not broken. Between slotted-ALOHA collisions and devices that have not recharged, a single round will miss devices. Applications that treat a missing tag as “item gone” will generate false negatives continuously. Require N consistent rounds before acting on absence.

Masks are set at manufacture. The filtering granularity available in the field is exactly what you encoded in the identifier structure. Get this wrong and you cannot fix it without re-tagging.

There is no firmware path. Treat Release 19 devices as fixed-function. Any logic that might change belongs in the reader or the core, never in the tag.

Do not assume commercial availability. As of this writing there is no public claim of Ambient IoT operating commercially on a public network, and the technology’s dependence on licensed FR1 FDD spectrum means availability will be operator-gated. Pilot work is proceeding; deployment is a different milestone.

Anti-replay needs persistent state that the device may not be able to keep. Any security design that assumes a monotonic counter survives brownout needs to be checked against the energy cost of a non-volatile write.

Practical Recommendations

If you are evaluating Ambient IoT in 2026, the most valuable thing you can do is separate what is specified from what is anticipated. Release 19 froze a single device class in a single topology in a single scenario. Everything else — device 2a, device 2b, topology 2 with UE readers — is Release 20 direction, and Release 20’s Stage 3 protocol work does not target completion until March 2027. Plan pilots against device 1 semantics and treat anything richer as future optionality.

Second, start the application-architecture work now, because it is independent of silicon availability. The question “can our process be expressed as network-triggered reads returning condition-at-read?” can be answered today with a whiteboard, and the answer determines whether you should be in this market at all.

A working checklist:

• Classify your use case honestly. Write down whether the device must ever initiate. If yes, stop — Release 19 does not support device-originated autonomous traffic.
• Map read points against radio reality. Mark where a read must physically happen, then check whether a base station and a carrier-wave source can both illuminate that spot. If your read points are process-defined and your readers are radio-planned, expect a mismatch.
• Design the identifier space with your product-coding owner. Mask granularity is fixed at manufacture and determines inventory-round efficiency.
• Benchmark against RFID first. If a portal or handheld reader is acceptable, price the Gen2 solution and use it as the floor any Ambient IoT business case must beat.
• Budget for statistical reads. Specify convergence over multiple rounds rather than a single-round completeness target.
• Ask vendors for carrier-wave topology explicitly. Monostatic versus bistatic changes your site plan, your device count per reader, and your cabling.
• Track the specification family, not the press releases. TS 38.191, TS 38.291, TS 38.391 and TS 38.195 are where the contract lives; TR 23.700-13 and TR 33.713 tell you what architecture and security actually considered.
• Do not commit to Release 20 features in a contract until 3GPP publishes a feature-level completion date.

Frequently Asked Questions

What is Ambient IoT in 3GPP terms?

Ambient IoT is a 3GPP device class for battery-free or minimally energy-buffered devices powered by harvesting ambient energy, targeting complexity and power consumption orders of magnitude below NB-IoT and LTE-M. Release 19 standardises “device 1”, which consumes roughly 1 µW at peak, receives using an RF envelope detector, and transmits only by backscattering an externally supplied carrier wave. It is specified for FR1 licensed FDD spectrum with an indoor base station acting as reader.

What is the difference between Ambient IoT device 1, 2a and 2b?

Device 1 is purely backscatter with no amplification anywhere, and it is what Release 19 standardises. Device 2a adds a reflection amplifier, so it still reflects rather than generates a carrier but boosts the return path, requiring stored energy to bias an active component. Device 2b generates its own signal internally, which removes the carrier-wave dependency and opens the possibility of autonomous transmission. 3GPP studied 2a and 2b in Release 19 and targets standardising some of those concepts in Release 20.

Does Ambient IoT replace RFID?

No, and 3GPP does not claim it does. Passive UHF RFID under EPC Gen2 and ISO/IEC 18000-63 remains cheaper, more mature and deployable today without an operator, and it is the right answer whenever a handheld or portal reader is operationally acceptable. Ambient IoT adds licensed spectrum, managed interference, an operator-grade identity model terminating in the core network, and reuse of base stations as readers. They address overlapping use cases from different infrastructure assumptions.

Can an Ambient IoT device send an alert on its own?

Not in Release 19. The supported traffic types are device-terminated and device-originated-device-terminated-triggered, both of which require the network to speak first. Device-originated autonomous traffic is explicitly not supported because active device-to-reader transmission is not supported for device 1. Practically, this means threshold alarms and tamper alerts must be re-expressed as polling problems, with latency set by inventory-round frequency rather than by the sensor.

When will Release 20 Ambient IoT be finished?

3GPP has not published a feature-level completion date for Ambient IoT in Release 20. The release-level milestones on 3GPP’s Release 20 page show Stage 1 frozen in June 2025, Stage 2 targeting a final freeze in September 2026, Stage 3 targeting March 2027, and the ASN.1/OpenAPI freeze in June 2027. Individual features can move inside that envelope, so treat those dates as the outer frame rather than as an Ambient IoT roadmap.

Why does Ambient IoT need a separate carrier-wave node?

Because a backscatter device does not generate a signal — it reflects one. Something must radiate the tone the device modulates. In monostatic operation the reader supplies it, which creates a hard self-interference problem since the reader transmits and receives simultaneously in the same band. In bistatic operation a separate node supplies it, which improves link budget but turns coverage planning into the overlap of an illumination field and a reception field. 3GPP wrote a dedicated conformance specification, TS 38.195, covering base station and carrier-wave node testing.

Further Reading

• LoRaWAN vs NB-IoT vs LTE-M for industrial IoT in 2026 — the battery-powered LPWA tier that Ambient IoT sits beneath, with the coverage and power trade-offs spelled out.
• TSN vs 5G URLLC: deterministic networking compared — the opposite end of the industrial connectivity spectrum, where latency guarantees rather than energy autonomy dominate.
• LoRaWAN protocol: complete technical guide — a deep dive into class-based device behaviour, useful for contrasting with Ambient IoT’s network-triggered-only model.
• Zigbee protocol: complete guide — mesh-based short-range networking, the other architectural answer to dense indoor device populations.
• 3GPP: Release 19 Ambient IoT — the primary source for the device-1 contract, the protocol-stack deletions, the AIOTF architecture and the identifier structure.
• GS1 EPC Gen2 UHF RFID standard — the incumbent passive-tag air interface any Ambient IoT business case has to be measured against.

By Riju — about