3GPP TSG RAN WG1 #121 R1-2504894
St Julian’s, Malta, May 19th – 23th, 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.
[121-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-121-Rel19-38.291-Ambient_IoT_Solutions] Email discussion on endorsement of Rel-19 draft TS38.291 – Matthew (Huawei)
Editor to prepare draft TS by XXX
Endorsement by YYY
R1-2503830 TP for A-IoT physical layer functions for TS 38.300 CMCC, Huawei, HiSilicon
R1-2504920 Summary for TP for TS 38.300 PHY function Moderator (CMCC)
Agreement
The TP in section 3 of R1-2504920, for TS 38.300 Clause 16.x.3, is endorsed with the following revisions:
The R2D transmission is a DFT-s-OFDM-based OOK waveform
Modulation of OOK or BPSK, small frequency shift
Agreement
The draft LS to RAN2 with the Ambient IoT stage-2 TP for TS38.300 is endorsed in R1-2504923.
Final LS in R1-2504924.
Agreement
The draft LS to RAN2 with Ambient IoT higher-layer parameters is endorsed in R1-2504914 with the following action for RAN2:
ACTION: RAN1 respectfully asks RAN2 to take the above RAN1 agreements into account when designing the higher layer signalling, including defining R2D TBS information (excluding CRC length) to be included in higher layer signaling, at least for messages with variable size.
Final LS in R1-2504915.
Physical channels design – modulation aspects
Including discussions on CP handling for R2D.
R1-2503220 Modulation aspects for Ambient IoT Ericsson
R1-2503224 Discussion on modulation aspects for A-IoT physical channel FUTUREWEI
R1-2503294 Physical channels design on modulation Huawei, HiSilicon
R1-2503299 AIoT Physical channels design - modulation aspects Nokia
R1-2503311 Discussion on Ambient IoT modulation ZTE Corporation, Sanechips
R1-2503358 Remaining issues on Modulation Aspects of Physical Channels Design vivo
R1-2503515 Discussion on modulation aspects of physical channels design for Ambient IoT Spreadtrum, UNISOC
R1-2503536 Discussion on modulation aspects for Ambient IoT physical design TCL
R1-2503566 Views on Physical channels design – modulation aspects Samsung
R1-2503703 Discussion on modulation aspects for A-IoT physical channel Tejas Network Limited
R1-2503725 Discussion on Physical Channel Design and Modulation Aspects for Ambient-IoT EURECOM
R1-2503734 Views on Physical channels design – modulation aspects for AIoT Ofinno
R1-2503793 Ambient IoT physical channel design and modulation CATT
R1-2503831 Discussion on modulation aspects of physical channel design CMCC
R1-2503882 Discussion on modulation aspects for Ambient IoT Xiaomi
R1-2503924 Discussion on modulation aspects of ambient IoT NEC
R1-2504007 A-IoT Physical Channels Design on Modulation Aspects Panasonic
R1-2504046 Discussion on physical channels design about modulation aspects for Ambient IoT China Telecom
R1-2504088 Modulation for R2D Fujitsu
R1-2504098 Discussion on Physical channels design for Ambient IoT-modulation aspects HONOR
R1-2504205 Discussion on modulation aspects of A-IoT OPPO
R1-2504243 A-IoT PHY layer design - waveform and modulation aspects LG Electronics
R1-2504287 Remaining issues on modulation aspects for Ambient IoT InterDigital, Inc.
R1-2504318 On remaining modulation aspects for Ambient IoT Apple
R1-2504394 Physical channels design – modulation aspects Qualcomm Incorporated
R1-2504433 Discussion on modulation aspects Sharp
R1-2504482 Discussion on Modulation Aspects for Ambient IoT Indian Institute of Tech (M)
R1-2504501 Discussion on modulation aspects of physical channel design for Ambient IoT NTT DOCOMO, INC.
R1-2504585 Discussion on physical channels design for A-IoT China Unicom
R1-2504617 Discussion on modulation aspects of physical channels design for Ambient IoT WILUS Inc.
R1-2504633 Discussion on modulation related aspects of AIoT IIT Kanpur
R1-2504710 FL summary #1 for Ambient IoT: “9.4.1 Physical channels design – modulation aspects” Moderator (Huawei)
Agreement
For R2D, the minimum Btx,R2D # of PRBs associated to each agreed M value (i.e. M = 2, 6, 12 and 24) is specified as per TR38.769.
Agreement
For M=24 on CP handling, update the below agreement as follows:
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’
For the OFDM symbol contains CAP
The last 2 out of M OOK chips at the end of the OFDM symbol are always ‘ON’
Option 3: RAN1 will not further pursue additional CP handling design
Agreement
For R2D chip duration, for CP handling that retains sub-carrier orthogonality, the length of a R2D chip duration (denoted as ‘C’) in one OFDM symbol is defined as:
C = 1/(SCS*M)
Note: the total length of M OOK chips is equal to 1/SCS
Working assumption
When padding is used in R2D, padding is present right after postamble (if postamble is supported).
Agreement
The working assumption is confirmed as follows:
When padding is used in R2D, padding is present right after postamble (if postamble is supported).
Agreement
When the generated number of chips for the R2D transmission does not fully occupy the last OFDM symbol, padding is used as follows:
Alt 1a: The content of padding is up to reader implementation and transparent to device.
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.
Note: the padding time could be used for extra time needed for calculating FEC/CRC for D2R (if applied)
The end chip(s) of the padding content shall follow the CP handling solution determined in RAN1, and may be affected by other agreements.
The chip(s) of the padding content shall avoid to result in SIP pattern.
Conclusion
The other steps (in addition to agreed Step 1 and Step 5) for R2D waveform generation will not be described in the RAN1 TS.
Physical channels design – line coding, FEC, CRC, repetition aspects
Including discussions on small frequency shift
R1-2503221 Coding aspects for Ambient IoT Ericsson
R1-2503225 Coding aspects for A-IoT physical channel FUTUREWEI
R1-2503295 Physical channel design on channel coding Huawei, HiSilicon
R1-2503300 AIoT Physical channels design - line coding, FEC, CRC, repetition aspects Nokia
R1-2503312 Discussion on Ambient IoTcoding and SFS ZTE Corporation, Sanechips
R1-2503359 Remaining issues on line coding, FEC, CRC and repetition for A-IoT vivo
R1-2503516 Discussion on line coding, FEC, CRC, repetition aspects for Ambient IoT Spreadtrum, UNISOC
R1-2503537 Discussion on other aspects for Ambient IoT physical design TCL
R1-2503567 Views on Physical channels design – line coding, FEC, CRC, repetition aspects Samsung
R1-2503618 Discussion on Physical Channel Designs for A-IoT Panasonic
R1-2503794 Ambient IoT channel coding and small frequency shift CATT
R1-2503832 Discussion on coding aspects of physical channel design CMCC
R1-2503883 Discussion on line coding, FEC, CRC and repetition aspects for Ambient IoT Xiaomi
R1-2503925 Physical layer design – line coding, FEC, CRC, repetition aspects NEC
R1-2504047 Discussion on physical channels design about line coding, FEC, CRC, repetition aspects for Ambient IoT China Telecom
R1-2504089 Discussion on coding aspects Fujitsu
R1-2504099 Discussion on Physical channels design for Ambient IoT-other aspects HONOR
R1-2504206 Discussion on physical channels design for A-IoT OPPO
R1-2504244 A-IoT PHY layer design - line coding, FEC, CRC and repetition aspects LG Electronics
R1-2504261 A-IoT - PHY line coding, FEC, CRC, repetition aspects MediaTek Inc.
R1-2504288 Remaining issues on coding aspects for Ambient IoT InterDigital, Inc.
R1-2504319 On remaining coding aspects for Ambient IoT Apple
R1-2504395 Physical channels design – line coding, FEC, CRC, repetition aspects Qualcomm Incorporated
R1-2504434 Discussion on coding aspects Sharp
R1-2504474 Discussion on A-IoT Physical channels design ASUSTeK
R1-2504502 Discussion on coding and CRC aspects of physical channel design for Ambient IoT NTT DOCOMO, INC.
R1-2504634 Discussion on other aspects of Phy design for AIoT IIT Kanpur
R1-2504749 Summary #1 for coding aspects of physical channel design Moderator (CMCC)
Agreement
For D2R transmission,
The minimum Tb is 1.39μs.
Support at least the following values of Tb, Tchip, and R from the table agreed in RAN1#120bis.
Note: This does not imply the device to pre-store the table.
Agreement
For bit collection after FEC, the output bits for each input bit are arranged sequentially in accordance with the input bits, e.g., for input bits , the output of the FEC is , with the code rate of 1/3.
Agreement
For attaching the CRC, the parity bits are appended to the end of the input bits, according to the order in TS38.212.
R1-2504750 Summary #2 for coding aspects of physical channel design Moderator (CMCC)
Agreement
For the number of block-level repetitions, {1, 2} are supported.
Note: When the number of block-level repetition is 1, it indicates no repetition.
Agreement
For indication of frequency domain resources for Msg 1 transmissions when Y≥1, the reader indicates
a single bit duration Tb which is same for all frequency domain resources
a set of R values, where the possible R values correspond to the agreed table of values of Tb, Tchip, and R
note: the set of R values could be signalled using a bitmap
The detailed signalling design is left to RAN2.
R1-2504751 Summary #3 for coding aspects of physical channel design Moderator (CMCC)
Agreement
For frequency domain resource for Msg 3 transmission determined based on explicit indication in the PRDCH for Msg 2 transmission for one or multiple devices, the reader indicates:
a single bit duration, which is same for all frequency domain resources,
a set of R values, where the possible R values correspond to the agreed table of values of Tb, Tchip, and R
note: the set of R values could be signalled using a bitmap
The mapping relationship between device and its Msg 3 frequency domain resource is left to RAN2.
Note: Device could determine its R value for Msg 3 transmission based on its order of random ID in Msg 2
The detailed signalling design is left to RAN2.
Timing acquisition and synchronization
Including discussions on the necessity/functionalities of preamble/midamble/postamble for R2D and D2R, respectively.
R1-2503222 Timing acquisition and synchronization for Ambient IoT Ericsson
R1-2503226 Discussion on timing acquisition and synchronization aspects for A-IoT FUTUREWEI
R1-2503296 Physical signals design Huawei, HiSilicon
R1-2503301 AIoT Timing acquisition and synchronization Nokia
R1-2503313 Discussion on Ambient IoT signals ZTE Corporation, Sanechips
R1-2503360 Remaining issues on Timing acquisition and synchronization for AIoT vivo
R1-2503420 Discussion on timing acquisition and synchronization NEC
R1-2503517 Discussion on timing acquisition and synchronization for Ambient IoT Spreadtrum, UNISOC
R1-2503538 Discussion on timing acquisition and synchronization functionalities for Ambient IoT TCL
R1-2503568 Views on timing acquisition and synchronization Samsung
R1-2503610 Discussion on timing acquisition and synchronization InterDigital, Inc.
R1-2503660 Discussion on timing acquisition and synchronization for Ambient IoT Lenovo
R1-2503704 Discussion on timing acquisition and synchronization of A-IoT Tejas Network Limited
R1-2503715 Discussion on timing acquisition and synchronisation for Ambient IoT Lekha Wireless Solutions
R1-2503735 Views on Timing acquisition and synchronization Ofinno
R1-2503795 Ambient IoT Timing and synchronization CATT
R1-2503833 Discussion on timing acquisition and synchronization CMCC
R1-2503884 Discussion on timing acquisition and synchronization for Ambient IoT Xiaomi
R1-2504008 A-IoT Timing acquisition and synchronization Panasonic
R1-2504048 Discussion on timing acquisition and synchronization for Ambient IoT China Telecom
R1-2504090 Discussion on timing acquisition and synchronization Fujitsu
R1-2504111 Discussion on timing acquisition and synchronization for Ambient-IOT Fraunhofer IIS, Fraunhofer HHI
R1-2504139 Discussion on timing acquisition and synchronization ETRI
R1-2504207 Discussion on timing acquisition and synchronization for A-IoT OPPO
R1-2504245 Timing acquisition and synchronization for A-IoT LG Electronics
R1-2504320 On remaining timing acquisition & synchronization aspects for Ambient IoT Apple
R1-2504396 Timing acquisition and synchronization Qualcomm Incorporated
R1-2504435 Discussion on timing acquisition and synchronization Sharp
R1-2504483 Discussion on Timing acquisition and synchronization for Ambient IoT Indian Institute of Tech (M)
R1-2504503 Discussion on timing acquisition and synchronization for Ambient IoT NTT DOCOMO, INC.
R1-2504600 Discussion on timing acquisition and synchronization aspects for Ambient IoT CEWiT
R1-2504635 Discussion on timing and synchronization aspects for AIoT IIT Kanpur
R1-2504322 FL Summary#1 on timing acquisition and synchronization for Ambient IoT Moderator (Apple)
Agreement
Confirm the working assumption in the following agreement from RAN1#120bis:
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
M = {2,6,12,24} are adopted for CAP and same M value is used for CAP and PRDCH in an R2D transmission.
R1-2504323 FL Summary#2 on timing acquisition and synchronization for Ambient IoT Moderator (Apple)
Agreement
For D2R ambles,
For n = 3, adopt m-sequence with following:
Polynomial: x³ + x² + 1
Initial State: Down-select between 010 or 100
Resulting Sequence: Down-select between 0 1 0 0 1 1 1 (for 010 initial state) or 1 0 0 1 1 1 0 (for 100 initial state)
For n = 5, adopt m-sequence with following:
Polynomial: x⁵ + x³ + 1
Initial State: 01001
Resulting Sequence: 0 1 0 0 1 0 0 0 0 1 0 1 0 1 1 1 0 1 1 0 0 0 1 1 1 1 1 0 0 1 1
R1-2504324 FL Summary#3 on timing acquisition and synchronization for Ambient IoT Moderator (Apple)
Agreement
SIP of R-TAS is adopted with 2 OFDM symbol duration, i.e. ON-OFF-ON-OFF with a ratio of 2:2:1:3
Note: Detection method of SIP presence at the device is not specified
Agreement from RAN1#120bis is updated as follows:
Agreement
For R-TAS, SIP duration of 1 2 OFDM symbols 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.
OPPO expressed the concern that the agreement above has higher overhead and latency.
Agreement
For D2R, for indicating the interval between consecutive midambles, and between the preamble and the first midamble, via R2D control information, following interval values are adopted:
For bit duration of 266.67μs
I = 48 bits, 96 bits, 168 bits, 240 bits
For other supported bit durations of 266.67μs/Y
I = Y * {48, 96, 168, 240} bits
Values of Y: 2, 4, 8, 16, 32, 64, 192
For signaling via R2D control information, following is adopted:
1-bit length codepoint is used to indicate whether long or short preamble/midamble is applied at the device, where “0” indicates short preamble/midamble and “1” indicates long preamble/midamble
Midamble interval is indicated by a 2-bit length codepoint
Lowest to highest codepoint value indicates lowest to highest interval value
1-bit length codepoint is used to indicate whether the midamble is present at the end or not, where “0” indicates no midamble present at the end and “1” indicates midamble present at the end
Note: if the indicated interval is longer than the number of bits after FEC (if FEC is applied) and repetition (if repetition is applied), and 1-bit length codepoint does not indicate midamble present at the end, then there is no midamble.
R1-2504863 FL Summary#4 on timing acquisition and synchronization for Ambient IoT Moderator (Apple)
Agreement
For m-sequence with n =3 for D2R ambles, adopt initial State of 100 and resulting sequence of 1 0 0 1 1 1 0
Agreement
R2D postamble is specified with 4 ON chips corresponding to M value of the PRDCH
R2D postamble is added immediately after the PRDCH
R2D postamble has always 4 ON chips
Note: For M=24, 2 ON chips at the end of OFDM symbol for CP handling are in addition to R2D postamble, and are not part of the R2D postamble
R2D padding duration is determined after R2D postamble insertion
TBS information for R2D is supported via higher layer R2D control signalling.
Send LS to RAN2 asking to include R2D TBS information (excluding CRC length) in higher layer signaling, at least for messages with variable size.
Note: Exact method for determining the end of PRDCH at the device is not specified.
Other aspects incl. multiplexing/multiple access, scheduling information, and timing relationships
Including discussions on L1 control information and any other L1 procedural aspects.
R1-2503223 Other aspects for Ambient IoT Ericsson
R1-2503227 Multiple access, scheduling and timing aspects for A-IoT FUTUREWEI
R1-2503297 Multiplexing, scheduling, and other physical-layer procedures Huawei, HiSilicon
R1-2503302 AIoT Other aspects incl. multiplexing/multiple access, scheduling information, and timing relationships Nokia
R1-2503314 Discussion on Ambient IoT multiple access and timing ZTE Corporation, Sanechips
R1-2503361 Remaining issues on other aspects for Rel-19 Ambient IoT vivo
R1-2503518 Discussion on other aspects for Ambient IoT Spreadtrum, UNISOC
R1-2503569 Views on aspects including multiplexing/multiple access, scheduling information, and timing relationships Samsung
R1-2503611 Discussion on multiplexing/multiple access, scheduling information, and timing relationships InterDigital, Inc.
R1-2503619 Discussion on other aspects of A-IoT Panasonic
R1-2503661 Discussion on multiple access, scheduling and timing aspects of Ambient IoT Lenovo
R1-2503705 Discussion on multiple access, scheduling and timing aspects for A-IoT Tejas Network Limited
R1-2503736 Views on other aspects for AIoT Ofinno
R1-2503796 Ambient IoT frame structure, system control and resource allocation CATT
R1-2503834 Discussion on access, scheduling and timing relationships CMCC
R1-2503885 Discussion on other aspects for Ambient IoT Xiaomi
R1-2503926 Discussion on control and other aspects of ambient IoT NEC
R1-2504049 Discussion on other aspects for Ambient IoT China Telecom
R1-2504064 Multiple access and timing relationships for Ambient IoT Sony
R1-2504091 Discussion on other aspects of Ambient IoT Fujitsu
R1-2504100 Discussion on L1 control information and L1 procedural aspects HONOR
R1-2504140 Discussion on other aspects for Ambient IoT ETRI
R1-2504208 Discussions on other aspects of A-IoT communication OPPO
R1-2504246 Other aspects for A-IoT LG Electronics
R1-2504299 Discussion on multiplexing, multiple access, scheduling information, and timing relationships Google
R1-2504321 On remaining multiple access, scheduling and control aspects for Ambient IoT Apple
R1-2504397 Discussion on other aspects for Rel-19 Ambient IoT Qualcomm Incorporated
R1-2504436 Discussion on other aspects Sharp
R1-2504475 Discussion on control information and procedural aspects ASUSTeK
R1-2504504 Discussion on other aspects for Ambient IoT NTT DOCOMO, INC.
R1-2504542 Discussion on other aspects of Ambient IoT KT Corp.
R1-2504589 Discussion on multiple access, scheduling information and timing relationships for Ambient IoT TCL
R1-2504601 Discussion on multiple access, scheduling and timing aspects for Ambient IoT CEWiT
R1-2504618 Discussion on multiplexing/multiple access and timing relationships for Ambient IoT WILUS Inc.
R1-2503362 FL summary #1 on other aspects for Rel-19 Ambient IoT Moderator (vivo)
Agreement
For Toffset1, where Toffset1 is the time interval from the end of the R2D transmission triggering random access to the starting time of the first Msg1 time domain resource for X=1 or X=2,
Toffset1 is not smaller than 30 us for CBRA.
R1-2503363 FL summary #2 on other aspects for Rel-19 Ambient IoT Moderator (vivo)
Agreement
For Toffset1, where Toffset1 is the time interval from the end of the R2D transmission triggering random access to the starting time of the first Msg1 time domain resource for X=1 or X=2, from the device perspective:
Toffset1 is from a set of predefined values.
FFS: the predefined values
E.g. values within the range [2666.8, 1333.4, 666.6, 333.4, 222.2, 166.6, 133.34, 111.2, 83.4, 55.6, 44.44, 41.6, 30] us
FFS: which values of Toffset1 correspond to which values of the following factors (to be selected with future agreement):
R2D chip length, D2R chip length, padding length, whether FEC is applied
Agreement
, where
is the duration of the 1st Msg1 time domain resource
=0.25 and =1.25
Agreement
Define Toffset3, which is the time interval from the end of a R2D transmission for Msg2 to the starting time of the corresponding Msg3 time domain resource, from the device perspective.
Agreement
Define Toffset4, which is the time interval from the end of a R2D transmission to the starting time of the corresponding D2R time domain resource except for Msg1 and Msg3 transmission, from the device perspective.
Agreement
Confirm the working assumption with following updates
Working assumption
For indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size except for Msg1 and Msg3 transmission in CBRA and 1st D2R Message in CFRA:
7 bits for byte-level D2R payload size indication
Regarding the TBS of Msg3 in CBRA, and 1st D2R Message in CFRA
From RAN1 perspective, it is up to other WGs to decide the actual payload value set and how device knows the actual payload size
Agreement
It is up to RAN4 to define the value(s) for TD2R_min.
Note: RAN1 expects that the value(s) for TD2R_min will be defined in RAN4 specifications
Agreement
For CBRA, for FDMA of multiple Msg1 transmissions in response to a R2D transmission triggering random access, the bit duration Tb, the sequence length for D2R preamble, the block repetition number, the channel coding information, the sequence length and the interval bits for D2R midamble insertion, if applicable, provided in the paging message are the same for all the FDMed Msg1 transmissions.
Agreement
For CBRA, for TDMA of X=2 Msg1 transmissions in response to a R2D transmission triggering random access, the bit duration Tb, the sequence length for D2R preamble, the block repetition number, the channel coding information, the sequence length and the interval bits for D2R midamble insertion, if applicable, provided in the paging message are the same for all the TDMed Msg1 transmissions.
R1-2503364 FL summary #3 on other aspects for Rel-19 Ambient IoT Moderator (vivo)
Working assumption
For Toffset1, for CBRA, regardless of the use of FEC,
The reference D2R chip length is the largest D2R chip length among the scheduled FDMed Msg1 for Y>1 or the D2R chip length for Y=1.
If reference D2R chip length is 133.33 or 66,67us, Toffset1 = 20* 66.67=1333.4us
If reference D2R chip length is 33.33, 16.67, or 8.33us, Toffset1 = 20* 33.33=666.6us
If reference D2R chip length is 4.17us, Toffset1 = 4* 33.33=133.32us
If reference D2R chip length is 2.08, 1.04, or 0.69us,
If the R2D chip length is 33.33us, Toffset1 = 4* 33.33=133.32us
If the R2D chip length is 11.11, 5.56 or 2.78us, Toffset1 = 3*11.11=33.33us
The R2D chip length refers to the corresponding R2D transmission triggering the D2R
Agreement
For Toffset3, for CBRA
The reference D2R chip length is the largest D2R chip length among the scheduled FDMed Msg3 for Y>1 or the D2R chip length for Y=1.
when FEC is not used:
If reference D2R chip length is 133.33 or 66,67us, Toffset3 = 20* 66.67=1333.4us
If reference D2R chip length is 33.33, 16.67, or 8.33us, Toffset3 = 20* 33.33=666.6us
If reference D2R chip length is 4.17us, Toffset3 = 4* 33.33=133.32us
If reference D2R chip length is 2.08, 1.04, or 0.69us,
If the R2D chip length is 33.33us, Toffset3 = 4* 33.33=133.32us
If the R2D chip length is 11.11, 5.56 or 2.78us, Toffset3 = 3*11.11=33.33us
The R2D chip length refers to the corresponding R2D transmission triggering the D2R
when FEC is used: down-select from the options below:
Opt1: same as when FEC is not used
Opt2: same as when FEC is not used + TFEC, where TFEC = [66.67]us
Opt3:
If reference D2R chip length is 133.33 or 66,67us, Toffset3 = 20* 66.67=1333.4us
If reference D2R chip length is 33.33, 16.67, or 8.33us, Toffset3 = 20* 33.33=666.6us
If reference D2R chip length is 4.17us, Toffset3 = 133.32us [+ 66.67us]
If reference D2R chip length is 2.08, 1.04, or 0.69us,
If the R2D chip length is 33.33us, Toffset3 = 133.32us [+ 66.67us]
If the R2D chip length is 11.11, 5.56 or 2.78us, Toffset3 = 33.33+[66.67]us
The R2D chip length refers to the corresponding R2D transmission triggering the D2R
Agreement
For FDMA of Msg3 transmissions in response to a PRDCH for Msg2:
The bit duration Tb, the sequence length for D2R preamble, the block repetition number, the channel coding information, the sequence length and the interval bits for D2R midamble insertion, if applicable, provided in the PRDCH for Msg2 are the same for all the FDMed Msg3 transmissions
R1-2504821 FL summary #4 on other aspects for Rel-19 Ambient IoT Moderator (vivo)
Working assumption
For Toffset3, for CBRA, when FEC is used
If reference D2R chip length is 133.33 or 66,67us, Toffset3 = 20* 66.67=1333.4us
If reference D2R chip length is 33.33, 16.67, or 8.33us, Toffset3 = 20* 33.33=666.6us
If reference D2R chip length is 4.17us, Toffset3 = 133.32us + X
If reference D2R chip length is 2.08, 1.04, or 0.69us,
If the R2D chip length is 33.33us, Toffset3 = 133.32us+ X
If the R2D chip length is 11.11, 5.56 or 2.78us, Toffset3 = 33.33+X
The R2D chip length refers to the corresponding R2D transmission triggering the D2R
Where X= 133.3us
Note: X=133.3us assumes the maximum size of Msg3 is 128 bits.
Agreement
For Toffset4, which is the time interval from the end of a R2D transmission to the starting time of the corresponding D2R time domain resource except for Msg1 and Msg3 transmission.
When FEC is not used:
If the D2R chip length is 133.33 or 66,67us, Toffset4 = 20* 66.67=1333.4us
If the D2R chip length is 33.33, 16.67, or 8.33us, Toffset4 = 20* 33.33=666.6us
If the D2R chip length is 4.17us, Toffset4 = 4* 33.33=133.32us
If the D2R chip length is 2.08, 1.04, or 0.69us,
If the R2D chip length is 33.33us, Toffset4 = 4* 33.33=133.32us
If the R2D chip length is 11.11, 5.56 or 2.78us, Toffset4 = 3*11.11=33.33us
The R2D chip length refers to the corresponding R2D transmission triggering the D2R
Agreement
For Toffset4, which is the time interval from the end of a R2D transmission to the starting time of the corresponding D2R time domain resource except for Msg1 and Msg3 transmission.
When FEC is used
Same as when FEC is not used + TFEC, where
TFEC = 2X for TBS <=32bytes
TFEC = 4X for 32bytes |