3GPP TSG RAN Meeting #103 RP-240155

Maastricht, Netherlands, March 18-21, 2024

Status Report to TSG

Agenda item: 9.2.3

WI / SI Name New SID: Study on solutions for Ambient IoT (Internet of Things) in NR
included in this status Study Item: Core part: Performance part: Testing part:
report Yes
Acronym FS_Ambient_IoT_solutions
Unique ID 1020085
TSG Tdoc of latest RP-234058
approved WI/SI
description (if any)
Target Completion Study Item: Core part: Performance part: Testing part:
Date 12/2024
(indicate if changed) (No change)
Overall Completion Study Item: Core part: Performance Part: Testing part:
level 8%
Note: Overall completion level percentage numbers should use one of the colors below:
 xx%: Normal progress, no RAN plenary action needed
 xx%: Progress behind schedule, may need RAN plenary intervention. If so, SR should clearly define
requested action
 xx%: Progress critically behind, RAN plenary shall intervene. SR should define requested action

Source:
Leading WG RAN1
Name Xiaodong Shen
Company CMCC
Email [email protected]
Name Matthew Webb
Rapporteur Company Huawei
Email [email protected]
Name John Humbert
Company T-Mobile USA
Email [email protected]

1 Work plan related evaluation

Do you want to modify the time budget for this WI/SI compared to
No
what was endorsed at the last RAN meeting?

If you answered No: Then please remove the Excel file from the zip file of this status report.

1 / 17
 If you answered Yes: Then please fill out the attached Excel template to request a modification of the time
budgets for your WI /SI. The Excel table has to be filled out for all affected RAN WGs and
up to the target date of the WI/SI. The basis are the endorsed time budgets of the last
RAN meeting. Please highlight all changes of the values.
One time unit (TU) corresponds to ~ 2 hours in the meeting.
If this status report covers a WI with Core and Performance part, then please have one
line for each in the attached Excel table.
Note: If no Excel table is attached, then this means no time budget change.

Additional explanations/motivations for the time budget changes in the attached Excel table:

2. Detailed progress in RAN WGs since last TSG meeting (for all
involved WGs)
NOTE: Agreements and Open issues impacted cross-TSG aspects shall be explicitly highlighted

2.1 RAN1

2.1.1 Agreements
Agreement

The Skeleton for TR 38.769 in R1-2401795 is endorsed.

2.1.1.1 Evaluation assumptions and results

Agreement

For this study item, the coverage evaluation methodology is based on the following steps.

For an evaluation scenario

 For each of the link i,

o Step 1: Obtain the required SINR for the physical channels under target scenarios and service/reliability
requirements if Budget-Alt2 is used for this link i.
o Step 2: Obtain the receiver sensitivity using the method Budget-Alt1 (if a predefined threshold is assumed to
derive the receiver sensitivity) or Budget-Alt2 (if no predefined threshold is assumed to derive the receiver
sensitivity).
o Step 3: Obtain the coverage performance for link i based on the receiver sensitivity from step 2 and link
budget template.
 The coverage results for each link are provided.
 FFS: what links are evaluated besides R2D and D2R (e.g., RF-EH)
 FFS whether/how to model the interferenceFFS: for which device(s) a predefined threshold is assumed

Note the following alternatives for obtaining receiver sensitivity are defined,

 Budget-Alt1: receiver sensitivity is derived by a predefined threshold and no LLS is needed for link budget
calculation
o The results rely on the received sensitivity and maximum transmit power, and directly calculate the
maximum distance / pathloss based on these values and other related parameters. The link-level simulation
2 / 17
 (LLS) performances, such as required SINR can be satisfied for such case and no LLS is needed for link
budget calculation.

 Budget-Alt2: receiver sensitivity is derived by required SINR which is given by LLS results
o The results rely on link-level simulation results, e.g., required SINR which corresponds to detail LLS
assumptions (e.g., BW, coding, data rate). And based on the required SINR, the received sensitivity can be
calculated and then the maximum distance / pathloss can be derived.
o Note: For noise power, a noise figure value needs to be provided.

Agreement

MPL and distance is used as performance evaluation metric for link budget calculation.

 Note: the distance is derived from MPL and corresponding pathloss model.
 FFS: Pathloss model

Agreement

The following pathloss model is used in the coverage evaluation.

 For D1T1,
o InF-DH defined in TR38.901 is used.
o Decide which of the following is used for each link,
 NLOS
 LOS
o FFS: InF-SH
 For D2T2, down-select from the following path loss models
o InF-DL defined in TR38.901 where the BS path loss model is reused for intermediate-UE with antenna
height of 1.5m
o InH-Office model defined in TR38.901, (a.k.a, InH_B in Report ITU-R M.2412-0) where the BS path loss
model is reused for intermediate-UE with antenna height of 1.5m
o Decide which of the following is used for each link,
 NLOS
 LOS

Conclusion

Companies are encouraged to consider Table 3.4.2 in R1-2401735 for their contributions to RAN1#116bis regarding link
budget template.

2.1.1.2 Ambient IoT device architectures

Agreement

For the purpose of the study, RAN1 uses the following terminologies:

 Device 1: ~1 µW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10 X
ppm, neither DL nor UL amplification in the device. The device’s UL transmission is backscattered on a carrier wave
provided externally.
 Device 2a: ≤ a few hundred µW peak power consumption, has energy storage, initial sampling frequency offset (SFO)
3 / 17
 up to 10X ppm, both DL and/or UL amplification in the device. The device’s UL transmission is backscattered on a
carrier wave provided externally.
 Device 2b: ≤ a few hundred µW peak power consumption, has energy storage, initial sampling frequency offset
(SFO) up to 10X ppm, both DL and/or UL amplification in the device. The device’s UL transmission is generated
internally by the device.

R1-2401703 FL Summary#2 for 9.4.1.2 Ambient IoT Device Architecture Moderator (Qualcomm)

Agreement

Study at least the following blocks for device 1 architecture.

 Antenna could be either shared or separate for RF energy harvester and receiver/transmitter.
 Matching network is to match impedance between antenna and other components (including RF energy harvester
and receiver related blocks).
 RF energy harvester can include rectifier performing RF signal (AC) to DC conversion.
 Energy storage (e.g., capacitor) stores harvested energy from RF energy harvester.
 Power management unit (PMU) manages storing energy to energy storage from energy harvester and suppling
power to active component blocks which needs power supply.
 Digital BB logic includes functional blocks like encoder, decoder, controller, etc.
 Memory can include two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently
storing device ID, etc, and 2) registers for temporarily keeping any information required for its operation only while
energy is available in energy storage.
 Clock generator provides required clock signal(s).
 Reception related blocks
o RF BPF for improving selectivity.
 Depending on implementation, it may not exist. RAN4 RF requirement (if any, e.g., ACS) and peak
power consumption target also need to be considered.
o RF Envelope Detector converts RF signal to baseband.
o BB LPF can filter out harmonics and high frequency components to improve input signal quality to
comparator.
 Depending on implementation, it may not exist. Presence of BB LPF is assumed for the study.
o Comparator determines high/low of input signal.
 Transmission related blocks
o Backscatter modulator switches impedance to modulate backscattered signal with tx signal from BB logics.
Waveform/Modulation type is FFS.

4 / 17
Agreement

Study at least following blocks for device 2a architecture w/ RF-ED receiver.

 Antenna could be either shared or separate for RF energy harvester (if present) and receiver/transmitter.
 Matching network is to match impedance between antenna and other components (including RF energy harvester (if
present) and receiver related blocks).
 Energy harvester.
 Energy storage (e.g., capacitor) stores harvested energy from energy harvester.
 Power management unit (PMU) manages storing energy to energy storage from energy harvester and suppling
power to active component blocks which needs power supply.
 Digital BB logic includes functional blocks like encoder, decoder, controller, etc.
 Memory can include two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently
storing device ID, etc, and 2) registers for temporarily keeping any information required for its operation only while
energy is available in energy storage.
 Clock generator provides required clock signal(s).
 Reflection amplifier can amplify reflected backscattered signal.
o FFS study applicability of amplification of rx signal, power consumption.
o At least one of R2D/CW2D and D2R could be amplified by either reflection amplifier or LNA.
 Reception related blocks
o RF BPF filter for improving selectivity.
 Depending on implementation, it may not exist. RAN4 RF requirement (if any, e.g., ACS) and peak
power consumption target also need to be considered.
o FFS: LNA for improving signal strength and sensitivity of receiver.
 At least one of R2D/CW2D and D2R could be amplified by either reflection amplifier or LNA.
o RF envelope detector (RF-ED) detects envelope from RF signal.
o BB amplifier amplifies BB signal to improve signal strength.
o BB LPF can filter out harmonics and high frequency components to improve input signal quality to
comparator/ADC.
 Depending on implementation, it may not exist.
o Comparator or N-bit ADC
 Transmission related blocks
o Backscatter modulator switches impedance to modulate backscattered signal with tx signal from BB logics.
o FFS: Large Frequency shifter (e.g., tens of MHz) for shifting backscattered signal from one frequency (e.g.,
FDD-DL frequency) to another frequency (e.g., FDD-UL frequency).

5 / 17
2.1.1.3 General aspects of physical layer design

Agreement

A-IoT DL study includes an OFDM-based waveform from A-IoT R2D (reader-to-device) perspective.

 Depending on what modulation(s) are decided to be studied:

o Study whether/how to handle CP at transmitter/device/design
 Study other characteristics of the OFDM waveform, e.g.:
o CP-OFDM
o DFT-s-OFDM
o Etc.
o The type of OFDM waveform is transparent to A-IoT device.
Other waveforms from DL transmitter’s perspective can be proposed, and further discussion will consider whether or not they
are included in the study.

Agreement

A-IoT DL study includes OOK from DL transmitter’s perspective.

 For an OFDM waveform, assume OOK-1 for single-chip per OFDM symbol transmission, and OOK-4 for M-chip per
OFDM symbol transmission, starting from definitions in TR 38.869.
o FFS value(s) of M.
o FFS: Any changes needed from the definitions in TR 38.869.
o FFS: Exact definition of chip
 If other DL waveforms are included, further elaboration of the transmitter’s OOK generation would be needed.

Agreement

For R2D, line codes studied are: Manchester encoding and pulse-interval encoding (PIE).

 FFS: Mapping(s) from bit(s) to line-code codewords

 FFS: Time domain definition of e.g., chips and relation to OFDM symbols, resource allocation unit, etc.
6 / 17
Agreement

Regarding FEC, R2D with no forward error-correction code (FEC) is studied as baseline.

 Evaluations would be by comparison to this baseline

Agreement

R2D study assumes use of CRC. FFS which CRC generator polynomial(s) are assumed, and if any cases are included with no
CRC.

 FFS: Association, if any, between down-selected CRC(s) and message size, considering at least false-alarm rate target

Agreement

D2R study assumes use of CRC. FFS which CRC generator polynomial(s) are assumed, and if any cases are included with no
CRC.

 FFS: Association, if any, between down-selected CRC(s) and message size, considering at least false-alarm rate target

Agreement

At least the following bandwidths for R2D are defined for the purpose of the study:

 Transmission bandwidth, Btx,R2D from a Reader perspective: The frequency resources used for transmitting R2D
 Occupied bandwidth, Bocc,R2D from a Reader perspective: The frequency resources used for transmitting R2D, and
potential guard band
 Bocc,R2D ≥ Btx,R2D
o FFS: Further constraint(s) e.g. Bocc,R2D = Btx,R2D.
o Possible values of each bandwidth are FFS

2.1.1.4 Frame structure and timing aspects

Agreement

From RAN1 perspective, at least when a response is expected from multiple devices that are intended to be identified, an A-
IoT contention-based access procedure initiated by the reader is used.

Agreement

For A-IoT contention-based access procedure, at least slotted-ALOHA based access is studied.

Agreement

At least the following time domain frame structure is studied for A-IoT R2D and D2R transmission.

 For R2D transmission,

o A R2D timing acquisition signal (e.g. R2D preamble) is included at least for timing acquisition and for
indicating the start of the R2D transmission in time domain.
 For D2R transmission,

7 / 17
 o A D2R timing acquisition signal (e.g. D2R preamble) is included at least for timing acquisition and for
indicating the start of the D2R transmission in time domain.
 FFS other necessary component(s), e.g. midamble, postamble, periodic sync signal, control fields, guard period

Agreement

For further discussion, the following terminologies are used for A-IoT for studying processing time aspects:

 TR2D_min: Minimum Time between a R2D transmission and the corresponding D2R transmission following it.
 TD2R_min: Minimum Time between a D2R transmission and the corresponding R2D transmission following it.
 TR2D_R2D_min: Minimum Time between two different consecutive R2D transmissions to the same A-IoT device.
 TD2R_D2R_min: Minimum Time between two different consecutive D2R transmissions from the same A-IoT device.
 The study should consider at least following aspects
o Implementation restrictions for the existing BS/UE
o [Processing time is common or different for different A-IoT devices]
o [Processing time for different traffic types/command types (e.g. DT or DO-DTT) and/or different use case
(e.g., Inventory or Command)]
 FFS other timing aspects

2.1.1.5 Downlink and uplink channel/signal aspects

Agreement

For ambient IoT devices, a dedicated physical broadcast channel for R2D, e.g. PBCH-like, is not considered for study.

Agreement

For ambient IoT devices, at least for R2D data transmission, a physical channel (PRDCH) is studied,

o System information (if defined) is transmitted on the PRDCH

o FFS Whether/how control information is transmitted on the PRDCH
 Note: the naming of PRDCH is used for the sake of the study

Agreement
For ambient IoT devices, at least for D2R data transmission, a physical channel (PDRCH) is studied along with the following,

 Response transmitted from device to reader during contention-based access procedure is

transmitted on the PDRCH
o FFS: Details of response
 FFS Whether/how/what D2R control information (if defined) is transmitted on the PDRCH
 Note: the naming of PDRCH is used for the sake of the study

2.1.1.6 Waveform characteristics of carrier-wave provided externally to the Ambient IoT device

Agreement

For R19 A-IoT study item, at least single-tone unmodulated sinusoid waveform is a candidate waveform for carrier wave for
D2R backscattering.

8 / 17
Agreement

For R19 A-IoT study item, multi-tone waveforms for carrier wave for D2R backscattering can be studied.

Agreement

For the case that D2R backscattering is transmitted in the same carrier as CW for D2R backscattering, and for topology 1, the
following cases for CW transmission are studied.
 Case 1-1: CW is transmitted from inside the topology, transmitted in DL spectrum
 Case 1-2: CW is transmitted from inside the topology, transmitted in UL spectrum
 Case 1-4: CW is transmitted from outside the topology, transmitted in UL spectrum

Agreement

For the case that D2R backscattering is transmitted in the same carrier as CW for D2R backscattering, and for topology 2, the
following cases for CW transmission are studied.
 Case 2-2: CW is transmitted from inside the topology (i.e., intermediate UE), transmitted in UL spectrum
 Case 2-3: CW is transmitted from outside the topology, transmitted in DL spectrum
 Case 2-4: CW is transmitted from outside the topology, transmitted in UL spectrum

2.1.2 Remaining Open issues

The following opens need to be addressed in RAN1:

1. Evaluation assumptions
a) Conclude at least the following aspects of design targets left to WGs in Clause 5 (RAN design targets) of TR 38.848
[RAN1].
o Clause 5.3: Applicable maximum distance target values(s)

o Clause 5.6: Refine the definition of latency suitable for use in RAN WGs

o Clause 5.8: 2D distribution of devices

b) Define necessary further evaluation assumptions of deployment scenarios for coverage and coexistence evaluations
[RAN1, RAN4]
c) Identify basic blocks/components of possible Ambient IoT device architectures, taking into account state of the art
implementations of low-power low-complexity devices which meet the RAN design target for power consumption and
complexity. [RAN1]
d) Define link budget calculation for coverage, including whether/how to model carrier wave from node(s) inside or
outside the connectivity topology.
NOTE: Assessment performance of the design targets is within the study of feasibility and necessity of proposals in the
following objectives, e.g. by inspection of reference implementations in the field, simulations, analytically.
NOTE: strive to minimize evaluation cases in RAN1.

2. Study necessary and feasible solutions for Ambient IoT as prescribed in the General Scope, including decisions on which
functions, procedures, etc. are needed and not needed, and ensuring at least the required functionalities in Section 6.2 of TR
38.848.

9 / 17
 Study the feasibility and required functionalities for proximity determination (coordination with SA3 is required for privacy
aspects).
 RAN1-led:
For the Ambient IoT DL and UL:
o Frame structure, synchronization and timing, random access

o Numerologies, bandwidths, and multiple access

o Waveforms and modulations

o Channel coding

o Downlink channel/signal aspects

o Uplink channel/signal aspects

o Scheduling and timing relationships

o Study necessary characteristics of carrier-wave waveform for a carrier wave provided externally to the
Ambient IoT device, including for interference handling at Ambient IoT UL receiver, and at NR basestation.
For Topology 2, no difference in physical layer design from Topology 1.

2.2 RAN2

2.2.1 Agreements

2.2.2 Remaining Open issues

 RAN2-led:
o Study and decide which functions are needed for an Ambient IoT compact protocol stack and lightweight
signalling procedure to enable DO-DTT and DT data transmission, and study those functions.

For example:

 Paging

 Random access

 Data transmission, including necessary radio resource control aspects, respecting the limitation in
the General Scope

 Interactions with upper layers

For functionalities not listed above, they are studied only if found essential.

2.3 RAN3

2.3.1 Agreements

2.3.2 Remaining Open issues

 RAN3-led:

10 / 17
 o Identify necessary impacts on signaling and procedures for CN-RAN interface, to enable:

 Paging
 Device context management
 Data transport
o Identify RAN architecture aspects, including whether support for split architecture is necessary.

o Identify potential solutions for locating an Ambient IoT device with no specification impact, e.g. reusing
existing user location report, or minimal specification impact to convey location information to core network.

2.4 RAN4

2.4.1 Agreements

2.4.2 Remaining Open issues

 RAN4-led:
o Coexistence study of Ambient IoT and NR/LTE.

o RF requirements study for Ambient IoT:

 Ambient IoT BS transmission and reception

 Ambient IoT Device, as per the General Scope, transmission and reception
 Intermediate node (UE), as per the General Scope, transmission and reception

2.5 RAN5

2.5.1 Agreements

2.5.2 Remaining Open issues

2.5.3 Remaining Open issues with cross-WG dependencies

2.6 RAN6

2.6.1 Agreements

2.6.2 Remaining Open issues

3. Detailed progress in SA/CT WGs since last TSG meeting (for all
involved WGs)
NOTE: This section only needs to be filled in for WI/SIs where there is a corresponding relevant WI/SI in SA/CT.

11 / 17
3.1 SAx/CTs

3.1.1 Agreements with cross-TSG impacts

3.1.2 Remaining Open issues with cross-TSG impacts

NOTE: This section should also flag any critical dependencies that need TSG attention.

4. References
NOTE: This can be e.g. a list of all related Tdocs in the affected WGs since last TSG, references to LSs,
produced TRs/TSs, the work/study item description or status reports of previous TSGs.

[1] R1-2401767 Session notes for 9.4 (Study on solutions for Ambient IoT in NR) Ad-Hoc Chair (Huawei)
[2] R1-2400328 Ambient IoT Study Item work plan CMCC, Huawei, T-Mobile USA
[3] R1-2401404 Skeleton for TR 38.769 "Study on Solutions for Ambient IoT (Internet of Things)" v0.0.1
Huawei
[4] R1-2401795 Skeleton for TR 38.769 "Study on Solutions for Ambient IoT (Internet of Things)" v0.0.1
Huawei
[5] R1-2401797 Editor’s summary for discussion on TR 38.769 skeleton Huawei
[6] R1-2400783 Operator view on Ambient IoT design targets T-Mobile USA Inc.
[7] R1-2400956 LS to SA3 requesting Ambient IoT security requirements T-Mobile USA Inc.
[8] R1-2400075 Evaluation assumptions and results for Ambient IoT Ericsson
[9] R1-2401306 On evaluation assumptions and results for A-IoT MediaTek Inc.
[10]R1-2400056 Discussion on evaluation assumptions and results for Ambient IoT Spreadtrum Communications
[11]R1-2400087 Discussion on evaluation assumptions and results for Ambient IoT devices FUTUREWEI
[12]R1-2400113 Evaluation assumptions for Ambient IoT Huawei, HiSilicon
[13]R1-2400244 Evaluation methodologies assumptions and results for Ambient IoT vivo
[14]R1-2400329 Discussion on evaluation methodology and assumptions CMCC
[15]R1-2400361 Initial views on Evaluation assumptions and results for Ambient IoT Nokia, Nokia Shanghai
Bell
[16]R1-2400435 The evaluation methodology and preliminary results of Ambient IoT CATT
[17]R1-2400486 Discussion on Ambient IoT evaluations ZTE, Sanechips
[18]R1-2400560 Evaluation methodology and assumptions for Ambient IoT xiaomi
[19]R1-2400609 Discussion on evaluation assumptions and results for A-IoT OPPO
[20]R1-2400662 Discussion on evaluation assumptions and results for Ambient IoT China Telecom
[21]R1-2400734 Considerations for evaluation assumptions and resultsSamsung
[22]R1-2400805 Discussion on ambient IoT evaluation framework NEC
[23]R1-2400855 Evaluation assumptions for Ambient IoT Sony
[24]R1-2400885 Discussion on the evaluation assumptions for Ambient IoT devices Lenovo
[25]R1-2400924 The Evaluation on Ambient IoT in NR Comba
[26]R1-2400942 Considerations for evaluation assumptions and resultsSemtech Neuchatel SA
[27]R1-2401014 Views on evaluation assumptions and link budget analysis for AIoT Apple
[28]R1-2401156 Discussion on Evaluation Assumptions and Results for Ambient IoT Indian Institute of Tech
(M), IIT Kanpur
[29]R1-2401180 Evaluation assumptions for Ambient IoT InterDigital, Inc.
[30]R1-2401326 Discussion on Ambient IoT evaluation LG Electronics
[31]R1-2401443 Evaluation Assumptions and Results Qualcomm Incorporated
[32]R1-2401647 FL summary #1 for Ambient IoT evaluation Moderator (CMCC)
[33]R1-2401735 FL summary #2 for Ambient IoT evaluation Moderator (CMCC)
12 / 17
[34]R1-2400735 Considerations for Ambient-IoT device architectures Samsung
[35]R1-2401015 Views on device architecture for AIoT Apple
[36]R1-2400057 Discussion on Ambient IoT device architectures Spreadtrum Communications
[37]R1-2400076 Ambient IoT device architectures Ericsson
[38]R1-2400088 Discussion on Ambient IoT device architectures FUTUREWEI
[39]R1-2400114 Ultra low power device architecutre for Ambient IoT Huawei, HiSilicon
[40]R1-2400187 Discussion on ambient IoT architecture TCL
[41]R1-2400245 Discussion on Ambient IoT Device architectures vivo
[42]R1-2400330 Discussion on Ambient IoT device architectures CMCC
[43]R1-2400362 Initial views on Ambient IoT device architectures Nokia, Nokia Shanghai Bell
[44]R1-2400436 Study of the Ambient IoT devices architecture CATT
[45]R1-2400487 Discussion on Ambient IoT device architectures ZTE, Sanechips
[46]R1-2400524 Discussion on Ambient IoT device architectures Honor
[47]R1-2400561 Discussion on ambient IoT device architectures xiaomi
[48]R1-2400610 Discussion on device architecture for A-IoT device OPPO
[49]R1-2400856 Ambient IoT device architectures Sony
[50]R1-2400887 Discussion on the Ambient IoT device architectures Lenovo
[51]R1-2400926 Ambient IoT device architectures Comba
[52]R1-2401065 Ambient IoT device architectures China Unicom
[53]R1-2401182 Device architectures for Ambient IoT InterDigital, Inc.
[54]R1-2401264 Discussion on Ambient IoT device architectures IIT Kanpur, Indian Institute of Tech (M)
[55]R1-2401275 Discussion on Ambient IoT device architectures CEWiT
[56]R1-2401307 On Ambient IoT device architectures MediaTek Inc.
[57]R1-2401327 Discussion on Ambient IoT device architectures LG Electronics
[58]R1-2401444 Ambient IoT Device ArchitectureQualcomm Incorporated
[59]R1-2401682 FL Summary#1 for 9.4.1.2 Ambient IoT Device Architecture Moderator (Qualcomm)
[60]R1-2401703 FL Summary#2 for 9.4.1.2 Ambient IoT Device Architecture Moderator (Qualcomm)
[61]R1-2401704 FL Summary#3 for 9.4.1.2 Ambient IoT Device Architecture Moderator (Qualcomm)
[62]R1-2400331 Discussion on general aspects of Ambient IOT physical layer design CMCC
[63]R1-2400777 Consideration on general aspects of physical layer Fujitsu
[64]R1-2400058 Discussion on general aspects of physical layer design for Ambient IoT Spreadtrum
Communications
[65]R1-2400077 General aspects of physical layer design for Ambient IoT Ericsson
[66]R1-2400089 Discussion on physical layer design for Ambient IoT devices FUTUREWEI
[67]R1-2400115 On general aspects of physical layer design for Ambient IoT Huawei, HiSilicon
[68]R1-2400246 Discussion on General Aspects of Physical Layer Design vivo
[69]R1-2400363 Initial views on General aspects of physical layer design for Ambient IoT Nokia, Nokia Shanghai
Bell
[70]R1-2400385 Optimal Training Sequence for Backscattering Tag BJTU
[71]R1-2400437 Discussion on general aspects of physical layer design CATT
[72]R1-2400459 Discussion on general aspects of ambient IoT physical layer design NEC
[73]R1-2400488 Discussion on general aspects of physical layer design for Ambient IoT ZTE, Sanechips
[74]R1-2400562 Discussion on physical layer design of Ambient IoT xiaomi
[75]R1-2400611 Discussion on general aspects of physical layer design of A-IoT communication OPPO
[76]R1-2400630 Discussion on general aspects of physical layer design Sharp
[77]R1-2400663 Discussion on general aspects of physical layer design for Ambient IoT China Telecom
[78]R1-2400736 Discussion on general aspects of Ambient IoT Samsung
[79]R1-2400756 On General Physical Layer Design Considerations for Ambient IoT Applications Lekha Wireless
Solutions
[80]R1-2400857 General aspects of physical layer design for Ambient IoT Sony
[81]R1-2400872 Discussions on general aspects for A-IoT Intel Corporation
[82]R1-2400888 Discussion on the Physical layer design for Ambient IoT devices Lenovo
[83]R1-2400934 Discussions on general aspects of physical layer design for Ambient IoT Ruijie Network Co. Ltd
13 / 17
[84]R1-2401016 Views on general physical layer design aspects for AIoT Apple
[85]R1-2401034 General aspects of physical layer design for Ambient IoT Panasonic
[86]R1-2401119 Study on general aspects of physical layer design for Ambient IoT NTT DOCOMO, INC.
[87]R1-2401160 Views on physical layer design Comba
[88]R1-2401183 Physical layer design for Ambient IoT InterDigital, Inc.
[89]R1-2401230 Discussion on general aspects of physical layer design for ambient IoT ETRI
[90]R1-2401258 Discussion on general aspects of physical layer design Google
[91]R1-2401265 Discussion on General aspects of physical layer design IIT Kanpur, Indian Institute of Tech (M)
[92]R1-2401276 Discussion on General aspects of physical layer design CEWiT
[93]R1-2401308 On general aspects of physical layer design for A-IoT MediaTek Inc.
[94]R1-2401328 General aspects of Ambient IoT physical layer design LG Electronics
[95]R1-2401350 General aspects of physical layer design Nordic Semiconductor ASA
[96]R1-2401445 General aspects of physical layer design Qualcomm Incorporated
[97]R1-2401464 General aspects of physical layer design for Ambient IoT ITL
[98]R1-2400755 Modulation Comparison for AIoT Wiliot Ltd.
[99]R1-2401567 Feature Lead Summary for 9.4.2.1: “Ambient IoT – General aspects of physical layer design” #1
Moderator (Huawei)
[100] R1-2401568 Feature Lead Summary for 9.4.2.1: “Ambient IoT – General aspects of physical layer design” #2
Moderator (Huawei)
[101] R1-2400116 On frame structure and timing aspects of Ambient IoT Huawei, HiSilicon
[102] R1-2400373 Discussions on frame structure and timing aspects for A-IoT Intel Corporation
[103] R1-2400059 Discussion on frame structure and timing aspects for Ambient IoT Spreadtrum Communications
[104] R1-2400078 Frame structure and timing aspects for Ambient IoT Ericsson
[105] R1-2400090 Discussion on frame structure and timing aspects for Ambient IoT devicesFUTUREWEI
[106] R1-2400200 Discussion on frame structure and timing aspects for ambient IoT Lenovo
[107] R1-2400247 Discussion on Frame structure, random access, scheduling and timing aspects vivo
[108] R1-2400305 Discussion on frame structure and timing aspects for Ambient IoT TCL
[109] R1-2400332 Discussion on frame structure and timing aspects for Ambient IOT CMCC
[110] R1-2400364 Initial views on Frame structure and timing aspects for Ambient IoT Nokia, Nokia Shanghai
Bell
[111] R1-2400438 Study of Frame structure and timing aspects for Ambient IoT CATT
[112] R1-2400460 Discussion on frame structure and timing for ambient IoT NEC
[113] R1-2400489 Discussion on frame structure and physical layer procedure for Ambient IoT ZTE, Sanechips
[114] R1-2400563 Discussion on frame structre and timing aspects for Ambient IoT xiaomi
[115] R1-2400612 Initial considerations on frame structure and timing aspects of A-IoT communication OPPO
[116] R1-2400631 Discussion on frame structure and timing aspects Sharp
[117] R1-2400664 Discussion on frame structure and timing aspects for Ambient IoT China Telecom
[118] R1-2400737 Considerations for frame structure and timing aspects Samsung
[119] R1-2400778 Discussion on frame structure and timing Fujitsu
[120] R1-2400784 Discussion on frame structre and timing aspects for Ambient IoT BUPT
[121] R1-2400799 The frame structure consideration for Ambient IoT Comba
[122] R1-2400858 Frame structure and timing aspects for Ambient IoT Sony
[123] R1-2400954 Frame structure and timing aspects of Ambient IoT InterDigital, Inc.
[124] R1-2401017 Views on frame structure, synchronization, random access and timing for AIoT Apple
[125] R1-2401062 Discussion on A-IoT Frame Structure and Timing Aspects Panasonic
[126] R1-2401066 Ambient IoT: Frame structure and timing aspects China Unicom
[127] R1-2401120 Study on frame structure and timing aspects for Ambient IoT NTT DOCOMO, INC.
[128] R1-2401157 Discussion on Frame Structure and Timing Aspects for Ambient IoT Indian Institute of Tech
(M), IIT Kanpur
[129] R1-2401231 Discussion on frame structure for ambient IoT ETRI
[130] R1-2401259 Discussion on frame structure and timing aspects Google
[131] R1-2401266 "Discussion on Frame structure and timing aspects" IIT Kanpur, Indian Institute of Tech (M)
[132] R1-2401277 Discussion on Frame structure and timing aspects CEWiT
14 / 17
[133] R1-2401309 On frame structure and timing aspects for A-IoT MediaTek Inc.
[134] R1-2401329 Frame structure and timing aspects for Ambient IoT LG Electronics
[135] R1-2401402 Discussion on frame structure and timing aspects for Ambient IoT Sequans Communications
[136] R1-2401446 Frame structure and timing aspects Qualcomm Incorporated
[137] R1-2401541 FL summary #1 on frame structure and timing aspects for Rel-19 Ambient IoT Moderator (vivo)
[138] R1-2401789 FL summary #2 on frame structure and timing aspects for Rel-19 Ambient IoT Moderator (vivo)
[139] R1-2400490 Discussion on downlink and uplink channel and signal for Ambient IoT ZTE, Sanechips
[140] R1-2401447 Downlink and uplink channel/signal aspects Qualcomm Incorporated
[141] R1-2400060 Discussion on downlink and uplink channel/signal aspects for Ambient IoT Spreadtrum
Communications
[142] R1-2400079 Downlink and uplink channel/signal aspects for Ambient IoT Ericsson
[143] R1-2400091 Discussion on DL and UL channel/signal aspects for Ambient IoT devicesFUTUREWEI
[144] R1-2400117 Physical channels and signals for Ambient IoT Huawei, HiSilicon
[145] R1-2400188 Discussion on downlink and uplink channel/signal aspects TCL
[146] R1-2400201 Discussion on downlink and uplink channel/signal aspects for ambient IoT Lenovo
[147] R1-2400248 Discussion on Downlink and uplink channel/signal aspects vivo
[148] R1-2400333 Discussion on downlink and uplink channel/signal aspects CMCC
[149] R1-2400365 Initial views on Downlink and uplink channel/signal aspects for Ambient IoT Nokia, Nokia
Shanghai Bell
[150] R1-2400439 DL and UL Physical Channels/signals design in support of Ambient IoT devices CATT
[151] R1-2400461 Discussion on downlink and uplink channel for ambient IoT NEC
[152] R1-2400564 Discussion on downlink and uplink channel/signal aspects for Ambient IoT xiaomi
[153] R1-2400613 Discussion on downlink and uplink channel/signal aspects for A-IoT OPPO
[154] R1-2400632 Discussion on downlink and uplink channel/signal aspects Sharp
[155] R1-2400665 Discussion on downlink and uplink channel/signal aspects for Ambient IoT China Telecom
[156] R1-2400738 Considerations for downlink and uplink channel/signal aspect Samsung
[157] R1-2400779 Discussion on downlink and uplink channel/signal Fujitsu
[158] R1-2400800 The downlink and uplink channel consideration for Ambient IoT Comba
[159] R1-2400812 Discussion on Downlink and Uplink Channel/Signal Aspects for A-IoT EURECOM
[160] R1-2400859 Downlink and uplink physical channel for Ambient IoT Sony
[161] R1-2400890 Discussion on downlink and uplink channels and signals for A-IoT Panasonic
[162] R1-2400955 Downlink and uplink channels aspects of Ambient IoT InterDigital, Inc.
[163] R1-2401018 Views on DL and UL PHY channels/signals and proximity determination for AIoT Apple
[164] R1-2401067 Ambient IoT: Downlink and uplink channel/signal aspects China Unicom
[165] R1-2401121 Study on downlink and uplink channel/signal aspects for Ambient IoT NTT DOCOMO, INC.
[166] R1-2401260 Discussion on downlink and uplink transmission aspects Google
[167] R1-2401283 Discussion on Downlink and uplink channel/signal aspects IIT Kanpur, Indian Institute of Tech (M)
[168] R1-2401310 On downlink and uplink channel/signal aspects for A-IoT MediaTek Inc.
[169] R1-2401330 Downlink and uplink channel/signal aspects for Ambient IoT LG Electronics
[170] R1-2401401 Discussion on DL and UL channel/signal aspects for Ambient IoT Sequans Communications
[171] R1-2401729 Feature lead summary#1 on downlink and uplink channel/signal aspects Moderator (Apple)
[172] R1-2401799 Feature lead summary#2 on downlink and uplink channel/signal aspects Moderator (Apple)
[173] R1-2400249 Discussion on CW waveform and interference handling at AIoT UL receiver vivo
[174] R1-2401122 Study on waveform characteristics of carrier-wave for Ambient IoT NTT DOCOMO, INC.
[175] R1-2400061 Discussion on waveform characteristics of external carrier-wave for Ambient IoT Spreadtrum
Communications
[176] R1-2400080 Waveform characteristics of carrier wave provided externally to the Ambient IoT device
Ericsson
[177] R1-2400092 Discussion on external carrier waveform characteristics for Ambient IoT devices FUTUREWEI
[178] R1-2400118 On external carrier wave for backscattering based Ambient IoT device Huawei, HiSilicon
[179] R1-2400190 Discussion on waveform characteristics of external carrier-wave for Ambient IoT TCL
[180] R1-2400202 Discussion on external carrier wave for ambient IoT Lenovo
[181] R1-2400334 Discussion on waveform characteristics of carrier-wave provided externally to the Ambient IoT
15 / 17
 device CMCC
[182] R1-2400366 Initial views on Waveform characteristics of carrier-wave provided externally to the Ambient IoT
device Nokia, Nokia Shanghai Bell
[183] R1-2400386 Backscatter Scheme for Same Frequency Interference Avoidance and Image Interference Suppressio
n BJTU
[184] R1-2400440 Discussion on the waveform characteristics of carrier-wave for the Ambient IoT device CATT
[185] R1-2400491 Discussion on carrier wave for Ambient IoT ZTE, Sanechips
[186] R1-2400565 Discussion on waveform characteristics of carrier-wave xiaomi
[187] R1-2400614 Discussion on Waveform characteristics of carrier-wave provided externally to the A-IoT device
OPPO
[188] R1-2400633 Discussion on waveform characteristics of externally provided carrier-wave Sharp
[189] R1-2400666 Discussion on waveform characteristics of carrier-wave provided externally to the Ambient IoT
device China Telecom
[190] R1-2400739 Considerations for Waveform characteristics of carrier-wave Samsung
[191] R1-2401481 Considerations for Waveform characteristics of carrier-wave Samsung
[192] Revision of R1-2400739
[193] R1-2400860 External carrier wave for Ambient IoT Sony
[194] R1-2401019 Views on carrier waveform and interference handling for AIoT Apple
[195] R1-2401158 Discussion on Waveform Characteristics of External Carrier Wave in Ambient IoT Indian
Institute of Tech (M), IIT Kanpur
[196] R1-2401184 Carrier-wave design for Ambient IoT InterDigital, Inc.
[197] R1-2401261 Discussion on waveform characteristics of carrier-wave provided externally to the Ambient IoT
device Google
[198] R1-2401278 Discussion on Waveform characteristics of carrier-wave provided externally to the Ambient IoT
device CEWiT
[199] R1-2401311 On carrier-wave waveform characteristics for A-IoT MediaTek Inc.
[200] R1-2401331 Consideration points on carrier-wave transmission for Ambient IoTLG Electronics
[201] R1-2401448 Waveform characteristics of carrier-wave provided externally to the Ambient IoT device
Qualcomm Incorporated
[202] R1-2401647 FL summary #1 for Ambient IoT evaluation Moderator (CMCC)
[203] R1-2401735 FL summary #2 for Ambient IoT evaluation Moderator (CMCC)
[204] R1-2401874 FL summary (final) for Ambient IoT evaluation Moderator (CMCC)
[205] R1-2401682 FL Summary#1 for 9.4.1.2 Ambient IoT Device Architecture Moderator (Qualcomm)
[206] R1-2401703 FL Summary#2 for 9.4.1.2 Ambient IoT Device Architecture Moderator (Qualcomm)
[207] R1-2401704 FL Summary#3 for 9.4.1.2 Ambient IoT Device Architecture Moderator (Qualcomm)
[208] R1-2401835 FL Summary#4 for 9.4.1.2 Ambient IoT Device Architecture Moderator (Qualcomm)
[209] R1-2401567 Feature Lead Summary for 9.4.2.1: “Ambient IoT – General aspects of physical layer design” #1
Moderator (Huawei)
[210] R1-2401568 Feature Lead Summary for 9.4.2.1: “Ambient IoT – General aspects of physical layer design” #2
Moderator (Huawei)
[211] R1-2401851 Feature Lead Summary for 9.4.2.1: “Ambient IoT – General aspects of physical layer design” – #3
Moderator (Huawei)
[212] R1-2401541 FL summary #1 on frame structure and timing aspects for Rel-19 Ambient IoT Moderator (vivo)
[213] R1-2401789 FL summary #2 on frame structure and timing aspects for Rel-19 Ambient IoT Moderator (vivo)
[214] R1-2401849 Final summary on frame structure and timing aspects for Rel-19 Ambient IoT Moderator (vivo)
[215] R1-2401729 Feature lead summary#1 on downlink and uplink channel/signal aspects Moderator (Apple)
[216] R1-2401799 Feature lead summary#2 on downlink and uplink channel/signal aspects Moderator (Apple)
[217] R1-2401857 Final feature lead summary on downlink and uplink channel/signal aspects Moderator (Apple)
[218] R1-2401695 FL summary#1 on CW waveform characteristics for A-IoT Moderator (Spreadtrum
Communications)
[219] R1-2401788 FL summary#2 on CW waveform characteristics for A-IoT Moderator (Spreadtrum
Communications)
R1-2401855 Final summary on CW waveform characteristics for A-IoT Moderator (Spreadtrum Communications)
16 / 17
 10.01.2022 minor adaptations for RAN #95e
04.10.2021 minor adaptations for RAN #94e
08.08.2021 minor adaptations for RAN #93e
17.05.2021 minor adaptations for RAN #92e
28.01.2021 minor adaptations for RAN #91e
09.11.2020 minor adaptations for RAN #90e
31.08.2020 minor adaptations for RAN #89e
20.04.2020 minor adaptations for RAN #88e
18.02.2020 minor adaptations for RAN #87e
14.11.2019 minor adaptations for RAN #86
18.08.2019 minor adaptations for RAN #85
12.05.2019 minor adaptations for RAN #84
27.02.2019 minor adaptations for RAN #83
21.11.2018 completion levels with colours added (for RAN #82)
v04.81 31.07.2018 simplification of template and addition of cross-TSG aspects (for RAN #81)
v04.80 21.05.2018 minor adaptations for RAN #80
v04.79 26.02.2018 minor adaptations for RAN #79
v04.78 18.11.2017 minor adaptations for RAN #78
v04.77 06.08.2017 minor adaptations for RAN #77
v04.76 15.05.2017 minor adaptations for RAN #76
v04.75 31.01.2017 minor adaptations for RAN #75
v04.74 28.10.2016 minor adaptations for RAN #74
v04.73 01.09.2016 adaptations for RAN #73 (time units in extra Excel table, RAN6 reporting included)
v04.72 26.05.2016 adaptations for RAN #72 (introduction of NR & GERAN TUs)
v04.71 10.02.2016 minor adaptations for RAN #71
v04.70 30.10.2015 minor adaptations for RAN #70
v04.69 12.08.2015 minor adaptations for RAN #69
v04.68 21.05.2015 minor adaptations for RAN #68
v04.67 01.02.2015 minor adaptations for RAN #67
v04.66 16.11.2014 minor adaptations for RAN #66
v04.65 16.08.2014 minor adaptations for RAN #65
v04.64 22.05.2014 minor adaptations for RAN #64
v04.63 24.01.2014 restructuring for RAN #63 to cover Core & Perf. in one doc file
v03.62 11.11.2013 section 1.2.3 adapted for RAN #62
v03 11.08.2013 section 1.2.3 added on time budget
v02 07.05.2010 history added, some spelling corrections
v01 13.11.2009 First version of the template

17 / 17