3GPP TSG RAN WG1 #120bis R1-2503112
Wuhan, China, April 7th – 11th, 2025
Agenda Item: 9.4
Source: Ad-Hoc Chair (Huawei)
Title: Session notes for 9.4 Solutions for Ambient IoT in NR
Document for: Discussion, Decision
Solutions for Ambient IoT (Internet of Things) in NR
Please refer to RP-250796 for detailed scope of the WI.
[120bis-R19-A-IoT] Email discussion on Rel-19 Ambient IoT – Jingwen (CMCC)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
[Post-120bis-Rel19-38.291-Ambient_IoT_Solutions] Email discussion on endorsement of initial Rel-19 draft TS38.291 – Matthew (Huawei)
Editor to prepare draft TS by XXX
Endorsement by YYY
R1-2501957 Discussion on timing acquisition and synchronisation for Ambient IoT Lekha Wireless Solutions
Withdrawn
R1-2502662 Skeleton for TS 38.291: “Ambient IoT Physical layer” v0.0.1 Huawei
Physical channels design – modulation aspects
Including discussions on CP handling for R2D.
R1-2501706 Discussion on modulation aspects for A-IoT physical channel FUTUREWEI
R1-2501719 Modulation aspects for Ambient IoT Ericsson
R1-2501733 Discussion on general aspects of physical layer design for Ambient IoT TCL
R1-2501760 Discussion on Ambient IoT modulation ZTE Corporation, Sanechips
R1-2501776 AIoT Physical channels design - modulation aspects Nokia
R1-2501806 Discussion on Modulation Aspects of Physical Channels Design vivo
R1-2501868 Discussion on modulation aspects of physical channels design for Ambient IoT Spreadtrum, UNISOC
R1-2501992 Ambient IoT physical channel design and modulation CATT
R1-2502016 Discussion on modulation aspects for A-IoT physical channel Tejas Network Limited
R1-2502022 Discussion on physical channels design about modulation aspects for Ambient IoT China Telecom
R1-2502068 Discussion on modulation aspects of ambient IoT NEC
R1-2502123 Modulation for R2D and D2R Fujitsu
R1-2502160 Discussion on modulation aspects of physical channel design CMCC
R1-2502233 Physical channels design on modulation Huawei, HiSilicon
R1-2502273 Discussion on modulation aspects of A-IoT OPPO
R1-2502318 Physical channel design aspects for Ambient IoT Sony
R1-2502368 Views on Physical channels design – modulation aspects Samsung
R1-2502441 Discussion on modulation aspects for Ambient IoT Xiaomi
R1-2502467 A-IoT Physical Channels Design on Modulation Aspects Panasonic
R1-2502474 A-IoT PHY layer design - waveform and modulation aspects LG Electronics
R1-2502584 Discussion on modulation aspects of physical channel design for Ambient IoT InterDigital Finland Oy
R1-2502586 Discussion on Physical Channel Modulation Aspects for Ambient-IoT EURECOM
R1-2502605 On modulation aspects for Ambient IoT Apple
R1-2502671 Discussion on modulation aspects Sharp
R1-2502690 Discussion on Physical channels design for Ambient IoT-modulation aspects HONOR
R1-2502704 A-IoT - PHY modulation aspects MediaTek Inc.
R1-2502766 Discussion on modulation aspects of physical channel design for Ambient IoT NTT DOCOMO, INC.
R1-2502839 Physical channels design – modulation aspects Qualcomm Incorporated
R1-2502898 Discussion on modulation aspects for Ambient-IOT Fraunhofer IIS, Fraunhofer HHI
R1-2502905 Discussion on modulation aspects for Ambient IoT physical channels Lenovo
R1-2502927 Discussion on modulation aspects of physical channels design for Ambient IoT WILUS Inc.
R1-2502938 Discussion on modulation related aspects of AIoT IIT Kanpur
Late submission
R1-2502992 FL summary #1 for Ambient IoT: “9.4.1 Physical channels design – modulation aspects” Moderator (Huawei)
Agreement
For R2D, for the OOK-4 modulation for M-chip per OFDM symbol transmission, the maximum M value is 24.
RAN1 will further determine the set of M values up to the maximum M value.
The maximum M value applicable to the PRDCH is 24
The maximum M value applicable to the R-TAS is not larger than 24
Agreement
For R2D, at least for PRDCH, the set of M values is {2, 6, 12, 24}
FFS: whether/how CAP use same M values set as PRDCH
R1-2502993 FL summary #2 for Ambient IoT: “9.4.1 Physical channels design – modulation aspects” Moderator (Huawei)
Agreement
For further down-selection among CP handing which retains subcarrier orthogonality, at least for PRDCH, at least Method Type 1 is supported
For supported M values <= 12
RAN1 will not further pursue additional CP handling design
For supported M values > 12
RAN1 will further down-select one from the followings
Option 1: Candidate 3 of M2-1-1 (as per agreements from RAN1#120)
Insert padding chips only at the end OOK chips of OFDM symbol
Option 3: RAN1 will not further pursue additional CP handling design
Agreement
Proposal: For Ambient IoT, RAN1 clarify that the definition of PRB is same as NR in TS 38.211.
R1-2502994 FL summary #3 for Ambient IoT: “9.4.1 Physical channels design – modulation aspects” Moderator (Huawei)
Agreement
For the below agreement, further update on the followings
Agreement
For further down-selection among CP handing which retains subcarrier orthogonality, at least for PRDCH, at least Method Type 1 is supported
For supported M values <= 12
RAN1 will not further pursue additional CP handling design
For supported M values > 12
RAN1 will further down-select one from the followings
Option 1: Candidate 3 of M2-1-1 (as per agreements from RAN1#120)
Insert padding chips only at the end OOK chips of OFDM symbol
The last 2 out of M OOK chips at the end of an OFDM symbol are always ‘ON’
Option 3: RAN1 will not further pursue additional CP handling design
Agreement
When the generated number of chips for the R2D transmission does not fully occupy the last OFDM symbol, padding is used.
Padding is to be down-selected among the following alternatives:
Alt 1a: The content of padding is up to reader implementation and transparent to device.
Note: the timeline determination of any timing relationship refers to the end of padding.
Note: it implies the device should be aware of the duration of padding or the last OFDM symbol boundary by implementation. FFS how accurately the device can be aware.
Alt 1b: The content of padding is up to reader implementation and transparent to device.
Note: the timeline determination of any timing relationship refers to the start of the padding.
Alt 2: Specify the detailed content of padding
Note: the timeline determination of any timing relationship refers to the end of padding.
Note: the end chip(s) of the padding content shall follow the CP handling solution determined in RAN1, and may be affected by other agreements.
Agreement
From reader perspective, for the needed certain specification of DFT-s-OFDM waveform generation for OOK-4 modulation:
An example is provided below, which does not presume any specific reader implementation:
Step 1: The time domain OOK signal is the M chips of one OFDM symbol
The specification only needs to reflect that one OFDM symbol contains M chips
Step 2: A chip is represented (e.g. upsampled) by L samples
The specification only needs to reflect that one chip contains L samples as the input to N’-points DFT
Step 3: An N’-points DFT is performed on the samples of one OFDM symbol to obtain the frequency domain signal.
The specification only needs to reflect that there is an N’-points DFT operation, where N’ = M*L
Step 4: Map the frequency domain signal obtained by N’-points DFT to the X subcarriers of Btx,R2D
The specification only needs to reflect that N’ >= X, where X is corresponding to the Btx,R2D
Step 5: An N-points IDFT is performed to obtain the time domain signal.
The specification only needs to reflect that there is an N-points IDFT operation
Note: other examples were provided in contributions to RAN1#120bis, e.g. in annex 2 of R1-2502160
From the example above, some normative specification related to at least step 1 and step 5 are needed.
Note: RAN1 to consider whether an information annex could describe other steps
Note: some normative RAN1 specification text about waveform is assumed to be needed for RAN4 requirements definition
Note: the specification also needs to reflect the timing of the CP insertion operation.
Physical channels design – line coding, FEC, CRC, repetition aspects
Including discussions on small frequency shift
R1-2501707 Discussion on coding aspects for A-IoT physical channel FUTUREWEI
R1-2501720 Coding aspects for Ambient IoT Ericsson
R1-2501734 Discussion on other aspects for Ambient IoT physical design TCL
R1-2501761 Discussion on Ambient IoTcoding ZTE Corporation, Sanechips
R1-2501777 AIoT Physical channels design - line coding, FEC, CRC, repetition aspects Nokia
R1-2501807 Discussion on line coding, FEC, CRC and repetition for A-IoT vivo
R1-2501869 Discussion on line coding, FEC, CRC, repetition aspects for Ambient IoT Spreadtrum, UNISOC
R1-2501993 Ambient IoT channel coding and small frequency shift CATT
R1-2502023 Discussion on physical channels design about line coding, FEC, CRC, repetition aspects for Ambient IoT China Telecom
R1-2502069 Physical layer design – line coding, FEC, CRC, repetition aspects NEC
R1-2502124 Discussion on coding aspects Fujitsu
R1-2502161 Discussion on coding aspects of physical channel design CMCC
R1-2502204 Discussion on Physical Channel Designs for A-IoT Panasonic
R1-2502234 Physical channel design on channel coding Huawei, HiSilicon
R1-2502274 Discussion on physical channels design for A-IoT OPPO
R1-2502369 Views on Physical channels design – line coding, FEC, CRC, repetition aspects Samsung
R1-2502442 Discussion on line coding, FEC, CRC and repetition aspects for Ambient IoT Xiaomi
R1-2502475 A-IoT PHY layer design - line coding, FEC, CRC and repetition aspects LG Electronics
R1-2502583 Discussion on coding aspects of physical channel design for Ambient IoT InterDigital Finland Oy
R1-2502606 On coding aspects for Ambient IoT Apple
R1-2502672 Discussion on coding aspects Sharp
R1-2502691 Discussion on Physical channels design for Ambient IoT-other aspects HONOR
R1-2502705 A-IoT - PHY line coding, FEC, CRC, repetition aspects MediaTek Inc.
R1-2502752 Discussion on A-IoT Physical channels design ASUSTeK
R1-2502767 Discussion on coding and CRC aspects of physical channel design for Ambient IoT NTT DOCOMO, INC.
R1-2502840 Physical channels design – line coding, FEC, CRC, repetition aspects Qualcomm Incorporated
R1-2502906 Discussion on the Ambient IoT physical layer design aspects for Line coding, FEC, CRC, Repetition Lenovo
R1-2502930 Coding aspects for Ambient IoT ITL
R1-2502939 Discussion on other aspects of Phy design for AIoT IIT Kanpur
R1-2503020 Summary #1 for coding aspects of physical channel design Moderator (CMCC)
R1-2503021 Summary #2 for coding aspects of physical channel design Moderator (CMCC)
Agreement
For the initial values of the shift register of the CC encoder, the initial values of the shift register of the CC encoder are set to the values corresponding to the last (K-1) information bits defined in TS 36.212.
Note: K is the constraint length.
For discussion on timing relationships in 9.4.4, the entire processing time for encoding (including finishing CRC encoding) should be taken into account
R1-2503022 Summary #3 for coding aspects of physical channel design Moderator (CMCC)
Agreement
When CRC is attached to a PRDCH or PDRCH transmission, when the number of information bits is ≤ 24 bits, CRC-6 is used. Otherwise, when the number of information bits is > 24 bits, CRC-16 is used.
Agreement
There is no case in D2R or R2D where CRC is not attached.
Conclusion
RAN1 will not address the FFS in the agreement from RAN1#120:
Agreement
When CRC is attached to a PRDCH or PDRCH transmission,
When the number of information bits is ≤ X bits, CRC-6 is used. Otherwise, when the number of information bits is > X bits, CRC-16 is used. Down-selection by RAN1#120bis from the following for X considering the balance of overhead and probability of undetected error:
Alt. 1: 24
Alt. 2: 56
FFS impact of segmentation, if any
Note: impact may not be in RAN1
R1-2503023 Summary #4 for coding aspects of physical channel design Moderator (CMCC)
Agreement
The potential values of D2R chip duration Tchip, bit duration Tb, and SFS factor R, are shown in the following table:
FFS further down-selections of Tchip, Tb, and R to be supported
Note: Detailed indication signaling of D2R scheduling information is discussed in AI 9.4.4.
R1-2503106 Summary #5 for coding aspects of physical channel design Moderator (CMCC)
Agreement
For block-level repetition of a D2R transmission, the repeated blocks are transmitted in the single PDRCH of the D2R transmission.
Timing acquisition and synchronization
Including discussions on the necessity/functionalities of preamble/midamble/postamble for R2D and D2R, respectively.
R1-2501708 Discussion on timing acquisition and synchronization aspects for A-IoT FUTUREWEI
R1-2501721 Timing acquisition and synchronization for Ambient IoT Ericsson
R1-2501735 Discussion on timing acquisition and synchronization functionalities for Ambient IoT TCL
R1-2501762 Discussion on Ambient IoT signals ZTE Corporation, Sanechips
R1-2501778 AIoT Timing acquisition and synchronization Nokia
R1-2501808 Discussion on Timing acquisition and synchronization for AIoT vivo
R1-2501870 Discussion on timing acquisition and synchronization for Ambient IoT Spreadtrum, UNISOC
R1-2501895 Discussion on timing acquisition and synchronization for Ambient IoT Lenovo
R1-2501921 Discussion on timing acquisition and synchronization InterDigital, Inc.
R1-2501994 Ambient IoT Timing and synchronization CATT
R1-2502024 Discussion on timing acquisition and synchronization for Ambient IoT China Telecom
R1-2502042 Views on Timing acquisition and synchronization Ofinno
R1-2502125 Discussion on timing acquisition and synchronization Fujitsu
R1-2502162 Discussion on timing acquisition and synchronization CMCC
R1-2502202 Discussion on timing acquisition and synchronization NEC
Late submission
R1-2502235 Physical signals design Huawei, HiSilicon
R1-2502275 Discussion on timing acquisition and synchronization for A-IoT OPPO
R1-2502319 Timing acquisition and synchronisation for Ambient IoT Sony
R1-2502370 Views on timing acquisition and synchronization Samsung
R1-2502443 Discussion on timing acquisition and synchronization for Ambient IoT Xiaomi
R1-2502468 A-IoT Timing Acquisition and Synchronization Panasonic
R1-2502471 Discussion on timing acquisition and synchronisation for Ambient IoT Lekha Wireless Solutions
R1-2502476 Timing acquisition and synchronization for A-IoT LG Electronics
R1-2502511 Discussion on timing acquisition and synchronization ETRI
R1-2502607 On timing acquisition & synchronization aspects for Ambient IoT Apple
R1-2502664 Discussion on timing and synchronization aspects Fraunhofer HHI, Fraunhofer IIS
Withdrawn
R1-2502673 Discussion on timing acquisition and synchronization Sharp
R1-2502706 A-IoT - Timing acquisition and synchronization MediaTek Inc.
R1-2502768 Discussion on timing acquisition and synchronization for Ambient IoT NTT DOCOMO, INC.
R1-2502841 Timing acquisition and synchronization Qualcomm Incorporated
R1-2502896 Timing acquisition and synchronization aspects for Ambient-IOT Fraunhofer IIS, Fraunhofer HHI
R1-2502915 Discussion on timing acquisition and synchronization aspects for Ambient IoT CEWiT
R1-2502940 Discussion on timing and synchronization aspects for AIoT IIT Kanpur
Late submission
R1-2502609 FL Summary#1 on timing acquisition and synchronization for Ambient IoT Moderator (Apple)
Agreement
For D2R midamble, for determining the presence and location of midamble(s) at the device:
Reader explicitly indicates the same interval between consecutive midambles, and between the preamble and the first midamble, via R2D control information
FFS: details of signalling
FFS: whether the reader can explicitly indicate with one bit whether a midamble is additionally present at the end
Note: This does not preclude the support of having no midamble present in the D2R transmission
Agreement
For the pattern of SIP of R-TAS, only the following 2 alternatives are considered for further down-selection:
Alt 1-2: ON-OFF with a ratio of 1:3 and with following total SIP duration to be further down-selected:
Option 1: 0.5 OFDM symbol duration
Option 2: 1 OFDM symbol duration
Alt 2-4: ON-OFF-ON-OFF with a ratio of 1:1:1:3 and with following total SIP duration to be further down-selected:
Option 1: 0.5 OFDM symbol duration
Option 2: 1 OFDM symbol duration
R1-2502610 FL Summary#2 on timing acquisition and synchronization for Ambient IoT Moderator (Apple)
Agreement
For D2R preamble/midamble, base sequence is generated from m-sequence, where the length of the sequence is
Value(s) of n
Long preamble/midamble is generated based on n = 5
Working assumption: Short preamble/midamble is generated based on n=3
Only 1-part preamble/midamble are supported for D2R
Preamble immediately precedes the PDRCH without any gap
Both long and short preamble and midamble are supported based on the working assumption on n
when midamble is present at least the following cases are supported and reader explicitly indicates one of the following cases for PDRCH:
Short preamble and short midamble
Long preamble and long midamble
Note: the case of short preamble and long midamble will not be supported
When midamble is not present the reader explicitly indicates short or long preamble for PDRCH
Agreement
For CAP of R-TAS, following is adopted:
Option 1 for CAP of R-TAS from TR 38.769 is adopted where the CAP duration becomes proportionally shorter with increasing value of M, i.e. if for , duration is OFDM symbol long, then for , duration is OFDM symbol long
Note: Duration without CP insertion is considered above, with CP insertion, the total duration may not be exactly proportional
Only following two alternatives for CAP pattern are considered for further down-selection to one alternative:
Alt 1: ON-OFF-ON-OFF
Alt 2: ON-OFF-ON
Agreement
For indicating the interval between consecutive midambles, and between the preamble and the first midamble, via R2D control information, following is adopted:
Unit of interval is number of bits after FEC (if FEC is applied) and repetition (if repetition is applied)
FFS: the candidate values in terms of the unit of interval
R1-2502611 FL Summary#3 on timing acquisition and synchronization for Ambient IoT Moderator (Apple)
Agreement
For R-TAS, SIP duration of 1 OFDM symbol is adopted with CAP pattern ON-OFF-ON-OFF for all values of M corresponding to PRDCH
Note: device cannot assume the presence/absence of RF transmission prior to the SIP.
Other aspects incl. multiplexing/multiple access, scheduling information, and timing relationships
Including discussions on L1 control information and any other L1 procedural aspects.
R1-2501709 Discussion on multiple access, scheduling and timing aspects for A-IoT FUTUREWEI
R1-2501722 Other aspects for Ambient IoT Ericsson
R1-2501763 Discussion on Ambient IoT multiple access and timing ZTE Corporation, Sanechips
R1-2501779 AIoT Other aspects incl. multiplexing/multiple access, scheduling information, and timing relationships Nokia
R1-2501809 Discussion on other aspects for Rel-19 Ambient IoT vivo
R1-2501871 Discussion on other aspects for Ambient IoT Spreadtrum, UNISOC
R1-2501896 Discussion on multiple access, scheduling and timing aspects of Ambient IoT Lenovo
R1-2501922 Discussion on multiplexing/multiple access, scheduling information, and timing relationships InterDigital, Inc.
R1-2501995 Ambient IoT frame structure, system control and resource allocation CATT
R1-2502017 Discussion on multiple access, scheduling and timing aspects for A-IoT Tejas Network Limited
R1-2502025 Discussion on other aspects for Ambient IoT China Telecom
R1-2502043 Views on other aspects for AIoT Ofinno
R1-2502070 Discussion on control and other aspects of ambient IoT NEC
R1-2502126 Discussion on other aspects of Ambient IoT Fujitsu
R1-2502163 Discussion on access, scheduling and timing relationships CMCC
R1-2502205 Discussion on other aspects of A-IoT Panasonic
R1-2502236 Multiplexing, scheduling, and other physical-layer procedures Huawei, HiSilicon
R1-2502276 Discussions on other aspects of A-IoT communication OPPO
R1-2502320 Multiplexing, multiple access and timing relationships for Ambient IoT Sony
R1-2502371 Views on aspects including multiplexing/multiple access, scheduling information, and timing relationships Samsung
R1-2502444 Discussion on other aspects for Ambient IoT Xiaomi
R1-2502477 Other aspects for A-IoT LG Electronics
R1-2502512 Discussion on other aspects for Ambient IoT ETRI
R1-2502608 On multiple access, scheduling and control for Ambient IoT Apple
R1-2502674 Discussion on other aspects Sharp
R1-2502692 Discuss on L1 control information and L1 procedural aspects HONOR
R1-2502699 Discussion on multiple access, scheduling information and timing relationships for Ambient IoT TCL
R1-2502707 A-IoT - Other aspects MediaTek Inc.
R1-2502729 Discussion on other aspects of Ambient IoT KT Corp.
R1-2502753 Discussion on control information and procedural aspects ASUSTeK
R1-2502769 Discussion on other aspects for Ambient IoT NTT DOCOMO, INC.
R1-2502842 Discussion on other aspects for Rel-19 Ambient IoT Qualcomm Incorporated
R1-2502890 Discussion on multiplexing, multiple access, scheduling information, and timing relationships Google
R1-2502916 Discussion on multiple access, scheduling and timing aspects for Ambient IoT CEWiT
R1-2502928 Discussion on multiplexing/multiple access and timing relationships for Ambient IoT WILUS Inc.
R1-2502941 Discussion on other aspects of AIoT IIT Kanpur
R1-2502498 FL summary #1 on other aspects for Rel-19 Ambient IoT Moderator (vivo)
Agreement
For scheduling D2R transmission, any scheduling information related to resource allocation that needs to be signaled is indicated by higher-layer signaling via the corresponding PRDCH.
R1-2502499 FL summary #2 on other aspects for Rel-19 Ambient IoT Moderator (vivo)
Agreement
For Msg 1 transmission determined by one R2D transmission triggering random access, support X=1 and X=2 time domain resource(s) for D2R transmission(s) for Msg1 only, where each D2R transmission for Msg1 occurs in one time domain resource of the X time domain resource(s) in Rel-19.
All devices support the above
Note: the impact of specification support (at least including signalling overhead) for X=2 to a reader supporting only X=1 should be minimized
Only support X=1 time domain resource for D2R transmission for Msg3 in response to a PRDCH for Msg2 transmission.
R1-2502500 FL summary #3 on other aspects for Rel-19 Ambient IoT Moderator (vivo)
Agreement
A device is not required to monitor a corresponding R2D transmission earlier than TD2R_min after the end of a D2R transmission from the device.
Conclusion
For any timing requirement that needs to be specified from device perspective by RAN1, the timing(s) do not include the impacts of SFO from the RAN1 perspective.
Whether 3GPP needs to specify some requirement on device’s SFO is up to RAN4 discussion.
Note: RAN1 will not specify TR2D_min or TR2D_max in Rel-19
Note: SFO may still be considered when discussing time-domain resources for Msg1 when X=2
Agreement
Use 1 bit to indicate the value of X (X=1 or X=2) time domain resource(s) for Msg1 transmission(s).
Agreement
For X=1 or X=2, from device perspective, the starting time for the first Msg1 time domain resource is Toffset1 after the end of the corresponding R2D transmission triggering random access.
FFS Toffset1 is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access.
FFS detailed value(s) of Toffset1, considering at least the device processing time including FEC impact
FFS: how to define the end of the R2D transmission in 9.4.1
Working assumption
For X=2, from device perspective, for determination of the starting time for the second Msg1 time domain resource:
Derived based on the starting time of the first Msg1 time domain resource plus Toffset2
FFS Toffset2 is predefined in the spec or derived by a rule or indicated implicitly or explicitly by the R2D transmission triggering random access.
Agreement
At least for CBRA, for FDMA of multiple Msg1 transmissions in response to a R2D transmission triggering random access, support only the same data rate for the FDMed Msg1 transmissions.
Working assumption
For indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size:
7 bits for byte-level D2R payload size indication
|