Pith. sign in

REVIEW 2 major objections 5 minor 1 cited by

3GPP Network Architecture Enhancement for Ambient IoT Service

T0 review · 2 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Pith's one-line read 3GPP is adding a new 5G core function, AIOTF, to serve battery-free Ambient IoT devices.

desk verdict A solid, traceable status report on 3GPP A-IoT architecture work, not a research contribution; the only original elements are the option comparison and a few qualitative preferences. read the letter →

arxiv 2501.08990 v1 pith:D3YQOXKS submitted 2025-01-15 cs.NI

classification cs.NI
keywords AmbientIoTEnergyharvestingbackscattering3GPP5GcoreAIOTFnetworkarchitectureRelease19
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper reports that 3GPP is standardizing Ambient IoT (A-IoT), a class of battery-free or ultra-low-power devices that harvest energy from their surroundings and communicate mainly by backscattering, as part of 5G Release 19 and 20. Its central claim is that serving these devices without SIM cards, normal registration, or conventional UE protocol stacks requires a new core-network function called AIOTF, a dedicated A-IoT-specific NAS layer, and a reader-centric architecture. The authors document the agreed device types, the two communication topologies (base station as reader or UE as reader), the alternative ways AIOTF can connect to readers, and the open security problems. A sympathetic reader would care because if this architecture is adopted, 3GPP networks could economically connect millions of cheap, battery-free sensors for warehouse inventory, indoor monitoring, and similar applications.

What carries the argument

The central mechanism is the AIOTF, a new network function in the 5G Core that brokers between A-IoT applications and A-IoT readers and terminates the A-IoT NAS layer. Around it sit three supporting pieces: the A-IoT-specific Access Stratum protocol that replaces the normal NR AS stack at the device, the reader selection logic (location-based static mapping or dynamic candidate lists refined by the gNB), and a security model that confines authentication, integrity, confidentiality, and anti-replay protection to the AIOTF-to-device NAS connection. This end-to-end security design makes the protection measures independent of which topology is used.

What would settle it

Run the proposed AIoT NAS security handshake (authentication, integrity, anti-replay primitives) on a device type 1 backscatter tag with 1 µW peak power in a 5G test network: if the tag cannot complete the crypto within its energy storage and timing limits, or if an impersonator can answer using only the statically provisioned identifier, the architecture's security premise collapses.

Watch

Extended reading notes

Core claim

The central claim is that 3GPP will enhance the 5G core with a new network function, the AIOTF, to handle A-IoT devices that cannot execute conventional UE procedures. The AIOTF exposes service-based APIs to applications, selects and authorizes A-IoT readers, assists the RAN with radio resource allocation, and terminates a new A-IoT-specific NAS protocol that runs end-to-end between the core and the device. Device identity is a two-part global identifier (type plus device ID) rather than a UICC-based subscription; registration is replaced by statically provisioned device information or an external AAA server. The paper presents two reader topologies and four architecture options, and concludes that the indirect option for topology 1 and the control-plane option for topology 2 are the most suitable for unified deployments. Security is established at the AIoT NAS layer so that it is topology-agnostic, with the trust base at the endpoints, although the paper flags the lack of UICC-based authentication as an area needing further work.

Load-bearing premise

The architecture assumes that A-IoT devices can be identified and authenticated without a UICC or the usual UE registration, using statically provisioned device information or an external AAA server; the paper itself states this needs further study, and if it fails, the AIoT NAS security and the procedures in Sections V.D-F would not be viable.

Editorial extensions

If this is right

  • Release 19 will specify the indoor scenario with the base station as reader and the lowest-capability backscatter device, while Release 20 is planned for the UE-reader topology and more capable device types.
  • Applications will be able to request inventory and command services through a service-based API exposed by the AIOTF, with the core aggregating device responses before returning them.
  • A-IoT devices will not register, will have no RRC states, and will not support handover, so tracking, paging, and roaming mechanisms must be redesigned from scratch.
  • Security for A-IoT will be carried by the AIoT NAS layer, making it topology-agnostic, but it depends on solving device authentication without UICCs, either through provisioned identifiers or an external AAA server.
  • UE readers in topology 2 will need explicit authorization through enhanced subscription data, and the reader UE's own UICC authentication will be reused to prevent impersonation.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If this architecture becomes normative, the marginal cost of connecting a sensor to a cellular network could fall far below today's NB-IoT and RedCap devices, potentially letting 3GPP compete with passive RFID for item-level tracking, but that is an extrapolation from the paper, not one of its claims.
  • The security caveats suggest the first commercial deployments will be closed, operator-managed environments (single warehouse, one service provider) rather than open networks, because the paper leaves the device-authentication question unresolved.
  • A concrete test: verify whether a device type 1 tag with 1 µW peak power can actually execute the AIoT NAS security primitives within its energy budget; the paper does not quantify this, so its claim of matching existing 3GPP security levels is still an open engineering question.
  • Interoperability between topologies depends on choosing a unified AIOTF interface; the greenfield direct option for topology 1 could fragment the architecture if deployed instead of the brownfield indirect option.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. This paper surveys 3GPP Release 18 and Release 19 work on Ambient IoT (A-IoT), with a focus on network architecture. It describes the two deployment scenarios, three device types, two communication topologies, and the proposed AIOTF core network function, including four architecture options for the two topologies. It also reviews device identification and subscription management, reader authorization and selection, radio resource allocation, an end-to-end service flow, and security aspects at a new A-IoT-specific NAS layer, and closes with a list of future standardization challenges. The paper is a descriptive survey grounded in public 3GPP technical reports and work item descriptions.

Significance. The paper provides a timely and useful consolidation of ongoing 3GPP discussions on A-IoT architecture. Its main strength is traceability: the claims are tied to TR 22.840, TR 38.848, TR 23.700-13, TR 38.769, and TR 33.713, and the figures (especially Fig. 2-4 and Fig. 6) give a clear overview of architecture options and the service flow. The authors are careful in several places to mark items as still under study. The principal weakness is that some security-related statements in Section VI are expressed with more confidence than the material in Section V.A and the cited study-phase documents support, particularly with respect to device credential bootstrap and the trust model for a UE acting as a reader. As a survey, the paper does not need original derivations or experiments, but it would benefit from more explicit separation of agreed 3GPP conclusions from the authors' own analysis.

major comments (2)
  1. [Section VI, referring to Section V.A] Section VI states that establishing security at the AIoT NAS layer "reduces the trust base to endpoints only" and aims for "the same security level as existing 3GPP features," but the paper does not provide or cite a mechanism by which a battery-free type-1 device (1 µW peak power, backscatter-only) and the AIOTF establish shared credentials, keys, counters, and anti-replay state. Section V.A explicitly says that A-IoT devices cannot use UICCs or conventional registration and that the only concrete proposal is static third-party provisioning, with dynamic provisioning still under study. The security assertions in Section VI should therefore be qualified as study-phase objectives, and the credential-bootstrap gap should be explicitly identified as an open problem for the proposed NAS-layer security model.
  2. [Section VI, topology 2 discussion] In the discussion of topology 2, the paper argues that the risk of a UE impersonating a privileged reader is addressed by reusing the primary authentication of the reader UE. This authenticates the UE but does not authenticate the A-IoT device, nor does it protect against a malicious UE relaying or altering device responses. Since the paper's earlier claim is that NAS-layer security is agnostic to topology and reduces the trust base to endpoints only, the reader UE would still be in the trust path unless additional integrity protection is applied. Please clarify this limitation and indicate whether any 3GPP study has addressed end-to-end integrity through an untrusted UE reader.
minor comments (5)
  1. [Section I] The text contains typos: "Radio Rre-quency" should be "Radio Frequency" in Section I, and "donlink" should be "downlink" in Section II.A, item (d).
  2. [Author line] The author affiliation line says "Philippe Godin id with Nokia Standards," which should read "is with Nokia Standards."
  3. [References and literature gap] Reference [9] is the authors' own prior paper and is used to assert that "available literature lacks information" on A-IoT architecture. To avoid a self-referential gap claim, please cite additional independent surveys or rephrase the statement to indicate that this paper builds on the authors' own earlier overview.
  4. [Section III.B and Fig. 4] The qualitative claim that the user plane option for topology 2 "may well be more suitable for applications requiring support for large traffic volumes" is not supported by a quantitative analysis or a citation. If this is the authors' own assessment, it should be labeled as such and briefly justified; if it is based on a 3GPP analysis, the corresponding document should be cited.
  5. [Section VII.7] The text says "locating AIoT device" but should be "locating A-IoT device" for consistent terminology; also, the relationship between the reader-granularity positioning described in Section II.B and the target accuracy of 1-3 meters in Section VII.7 should be clarified.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the paper is a survey of 3GPP study-item content, with only a minor non-load-bearing self-citation.

full rationale

The paper does not contain a derivation chain. It summarizes architecture options, procedures, and security considerations from public 3GPP TRs (TR 22.840, TR 38.848, TR 23.700-13, TR 33.713, TR 38.769) and RP-243326, so the central claims about the AIOTF, A-IoT NAS, reader authorization, and device provisioning are reports of ongoing standardization work rather than predictions derived from the paper's own assumptions. No fitted parameters are renamed as predictions, no uniqueness theorem is imported from the authors' prior work, and no ansatz is smuggled in via self-citation. The only self-citations are [1] as an example application and [9] in a literature-gap sentence: 'available literature lacks information on 3GPP progress regarding A-IoT services and architecture enhancements to enable A-IoT services in 3GPP networks [9]' (Section I). That self-citation is not load-bearing: it merely asserts novelty of the survey and does not justify any architecture or security conclusion. The paper also explicitly flags unresolved premises (e.g., dynamic provisioning in Section V.A and reader impersonation in Section VI) rather than presenting them as established results. Accordingly, the manuscript is self-contained against external 3GPP specifications and exhibits no meaningful circularity; the score of 1 reflects only the minor, non-load-bearing self-citation in the introduction.

Assumptions & free parameters 0 free parameters · 3 assumptions · 1 invented entities

The paper is a survey and introduces no free parameters. The main assumptions are the reliability of cited 3GPP documents, the viability of non-SIM authentication for constrained devices, and RAN control of licensed spectrum resources. The AIOTF entity is inherited from 3GPP study work rather than invented ad hoc by the authors.

assumptions (3)
  • domain assumption 3GPP TRs and work items cited represent the authoritative state of standardization discussions.
    The entire survey is built on trust in the cited TR 38.848, TR 23.700-13, TR 38.769, TR 33.713, and RP-243326; these are not independently verified in the paper.
  • domain assumption A-IoT devices can be authenticated without UICC or conventional registration, using statically provisioned credentials or external AAA.
    Sections IV.B and V.A state this as the working assumption for device provisioning; the paper flags further study needed, so the architecture rests on an unresolved premise.
  • domain assumption Licensed spectrum use requires the A-IoT RAN to control radio resources for device-to-reader links.
    Section V.F takes RAN control of resources as a given for licensed bands; this underpins the AIOTF-RAN interaction design.
invented entities (1)
  • AIOTF (Ambient IoT Function) independent evidence
    purpose: New 5G core network function to receive A-IoT service requests, select A-IoT readers, aggregate device responses, and expose A-IoT service APIs.
    The AIOTF is proposed as part of 3GPP Release 19 architecture work (TR 23.700-13), not solely by this paper; its future specification in public 3GPP documents provides a falsifiable and testable handle.

how reviews work

0 comments
Cite this review

Pith. "Pith review of 3GPP Network Architecture Enhancement for Ambient IoT Service." pith.science (2026). https://pith.science/paper/D3YQOXKS

@misc{pith2026250108990,
  author       = {Pith},
  title        = {Pith review of: 3GPP Network Architecture Enhancement for Ambient IoT Service},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/D3YQOXKS}},
  note         = {Machine review of arXiv:2501.08990}
}
read the original abstract

Ambient internet of things (A-IoT) paradigm is under study in 3GPP with the intention to provide a sustainable solution for the IoT market without any need to replace the batteries and operate in harsh environments where it is difficult to replenish batteries. This article provides insight on 3rd Generation Partnership Project (3GPP) discussions in Release 18 and 19 with the focus on network architecture aspects. 3GPP has recently decided to start normative work in its Radio Access Network (RAN) Working Group (WG) and discussions are ongoing to start a work item in other WGs with more focus on architecture aspects. We explore and analyze various aspects of system design related to architecture requirements to support A-IoT service, different architecture options to consider, security and authentication mechanisms for A-IoT devices as well as key challenges for standardization of A-IoT service.

Figures

Figures reproduced from arXiv: 2501.08990 by the authors.

Figure 1
Figure 1. A-IoT scenarios and topologies as defined in 3GPP. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Architecture options to support Topology 1. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Architecture options to support Topology 2. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: A comparison of architecture options for topology 1 and 2. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Simplified protocol stacks for topology 1 and topology 2. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Overall service flow for A-IoT service operations. [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Considerations on the Design of Transceivers for Ambient Internet of Things

    eess.SY 2025-04 reject novelty 4.0 of 10

    An approximate low-IF, crystal-less receiver with carrier-auxiliary IF feedback LO synthesis is proposed for Type-B/C Ambient IoT, with -88 dBm sensitivity estimated from a link budget rather than measured.

Reference graph

Works this paper leans on

18 extracted references · 18 canonical work pages · cited by 1 Pith paper

  1. [9]

    Ambient IoT: A missing link in 3GPP IoT devices landscape,

    M. M. Butt, N. R. Mangalvedhe, N. K. Pratas, J. Harrebek, J. Kimionis, M. Tayyab, O.-E. Barbu, R. Ratasuk, and B. Vejlgaard, “Ambient IoT: A missing link in 3GPP IoT devices landscape,” IEEE Internet of Things Magazine, vol. 7, no. 2, pp. 85–92, 2024

  2. [1]

    Ambient IoT: Communications Enabling Precision Agriculture

    A. N. Arun, B. Lee, F. A. Castiblanco, D. R. Buckmaster, C.-C. Wang, D. J. Love, J. V . Krogmeier, M. M. Butt, and A. Ghosh, “Ambient IoT: Communications enabling precision agriculture,” 2024. [Online]. Available: https://arxiv.org/abs/2409.12281

  3. [2]

    Energy harvesting systems market size & share analysis - growth trends & forecasts (2025 - 2030),

    “Energy harvesting systems market size & share analysis - growth trends & forecasts (2025 - 2030),” Mordor Intelligence, India, Tech. Rep., 2024. [Online]. Available: https://www.mordorintelligence.com/ industry-reports/energy-harvesting-system-market

  4. [3]

    Fundamentals of wireless information and power transfer: From RF energy harvester models to signal and system designs,

    B. Clerckx, R. Zhang, R. Schober, D. W. K. Ng, D. I. Kim, and H. V . Poor, “Fundamentals of wireless information and power transfer: From RF energy harvester models to signal and system designs,” IEEE Journal on Selected Areas in Communications , vol. 37, no. 1, pp. 4–33, 2019

  5. [4]

    Joint waveform and beamforming optimization for MIMO wireless power transfer,

    S. Shen and B. Clerckx, “Joint waveform and beamforming optimization for MIMO wireless power transfer,” IEEE Transactions on Communi- cations, vol. 69, no. 8, pp. 5441–5455, 2021

  6. [5]

    Learning to communicate and energize: Modulation, coding, and multiple access designs for wireless information-power transmission,

    M. Varasteh, J. Hoydis, and B. Clerckx, “Learning to communicate and energize: Modulation, coding, and multiple access designs for wireless information-power transmission,” IEEE Transactions on Communica- tions, vol. 68, no. 11, pp. 6822–6839, 2020

  7. [6]

    Resource allocation for simultaneous wireless information and power transfer systems: A tutorial overview,

    Z. Wei, X. Yu, D. W. K. Ng, and R. Schober, “Resource allocation for simultaneous wireless information and power transfer systems: A tutorial overview,”Proceedings of the IEEE, vol. 110, no. 1, pp. 127–149, 2022

  8. [7]

    Access control for ambient backscatter enhanced wireless internet of things,

    L. Zhang, G. Feng, S. Qin, Y . Sun, and B. Cao, “Access control for ambient backscatter enhanced wireless internet of things,” IEEE Transactions on Wireless Communications , vol. 21, no. 7, pp. 5614– 5628, 2022

Show all 18 references
  1. [8]

    Study on ambient power-enabled internet of things,

    3rd Generation Partnership Project (3GPP), TR 22.840, “Study on ambient power-enabled internet of things,” Tech. Rep., 2023. [Online]. Available: https://www.3gpp.org/ftp/Specs/archive/22 series/ 22.840/22840-120.zip

  2. [10]

    Ambient IoT (internet of things) in RAN,

    3rd Generation Partnership Project (3GPP), TR 38.848, “Ambient IoT (internet of things) in RAN,” Tech. Rep.,

  3. [11]

    New work item: Solutions for ambient IoT (internet of things) in NR,

    3rd Generation Partnership Project (3GPP), RP-243326, “New work item: Solutions for ambient IoT (internet of things) in NR,” Tech. Rep., Dec. 2024. [Online]. Available: https://www.3gpp.org/ftp/Meetings 3GPP Sync/RAN/Inbox/

  4. [12]

    Study on architecture support of ambient power- enabled internet of things (release 19),

    3rd Generation Partnership Project (3GPP), TR 23.700- 13, “Study on architecture support of ambient power- enabled internet of things (release 19),” Tech. Rep., Dec

  5. [13]

    EPC tag data standard (TDS), release 2.1,

    GS1, “EPC tag data standard (TDS), release 2.1,” Tech. Rep., Feb

  6. [14]

    Study on solutions for ambient IoT (internet of things) in NR

    3rd Generation Partnership Project (3GPP), TR 38.769, “Study on solutions for ambient IoT (internet of things) in NR.” Tech. Rep., Dec. 2024. [Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=4285

  7. [15]

    Study on security aspect of ambient IoT services in 5G (release 19)

    3rd Generation Partnership Project (3GPP), TR 33.713, “Study on security aspect of ambient IoT services in 5G (release 19).” Tech. Rep., Dec. 2024. [Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=4291

  8. [16]

    Available: https://www.gs1.org/standards/tds

    [Online]. Available: https://www.gs1.org/standards/tds

  9. [2023]

    Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=4146

    [Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=4146

  10. [2024]

    Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=4255

    [Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=4255

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.