3GPP TSG-RAN WG1 Meeting #121	R1- 2503223
Malta, MT, May 19th – May 23rd, 2025

Agenda Item:	9.4.4
Source:	Ericsson
Title:	Other aspects for Ambient IoT
Document for:	Discussion, Decision
1	

Conclusion
In the previous sections we made the following observations:
Observation 1	Support for variable preamble lengths, midambles, FEC and block repetition for Msg1 scheduling implies that Msg1 lengths might vary.
Observation 2	Transmission time for Msg1 at X=1 can be calculated by the device based on values configured by the reader for parameters stated in Observation 1.
Observation 3	A guard interval G= 2*(TMsg1)*SFO is required between Msg1 TDMA occasions to prevent timing overlaps, where TMsg1 is the time duration of Msg1 transmission. This can result in variable guard bands. SFO value can be discussed in RAN4.
Observation 4	Pre-configuring Toffset2 in the standard might be challenging based on observation 1 and 3.
Observation 5	It is feasible for the device to calculate  Toffset2 given the maximum possible SFO based on Observation 2.
Observation 6	Since Msg3 scheduling is device-specific, there is a possibility to assign device specific parameters on preamble lengths, midamble fields, FEC, block repetitions etc.
Observation 7	Device-specific scheduling might benefit from supporting different data rates as well.
Observation 8	Supporting a common D2R chip duration and a reader-configured set of R values can provide frequency resources supporting variable BWs which can be FDMA’ed without overlaps. However, overall resource allocation might not be very efficient in this case.
Observation 9	If PRDCH for Msg2 contains only one Msg1 response, then every Msg2 transmission is followed by a Msg3 response; i.e, Msg3 becomes interleaved.
Observation 10	For the case mentioned in Observation 7, the resource allocation is most beneficial if Msg3 transmission is scheduled across the entire transmission bandwidth.
Observation 11	If PRDCH for Msg2 contains Msg1 responses to all devices which are simultaneously FDMA’ed, then every Msg2 transmission is followed by Y Msg3 responses which are simultaneously FDMA’ed; Y being the number of FDMA occasions.
Observation 12	For FDMA resources in Msg1 where collision has occurred, the case mentioned in Observation 9, can result in unused FDMA resources if frequency domain resource for Msg3 reuses the frequency domain resource for Msg1.
Observation 13	Scheduling variable Msg3 bandwidths for different devices might be beneficial for better resource utilization even when Msg2 contains responses to multiple Msg1 transmissions.
Observation 14	Defining TD2R_min in the standard might allow defining a switching time for the device to go from transmit to receive mode. While this can be optionally considered based on the requirement, the following additional considerations will have to be discussed.
(1) Though a minimum time after which the device can switch to receive mode is defined, the actual time for monitoring receptions after a D2R transmission should be reader configurable.
(2) Clarify whether the ‘corresponding R2D transmission’ in the definition of TD2R_min can include L1 R2D control information as well.
Observation 15	TDMA related information for Msg1 scheduling need not support fields like preamble lengths and midamble details since these fields depend on TBS.
Observation 16	Supporting FEC and block repetition for Msg1 enables the reader to extend the coverage based on the deployment.
Observation 17	If Msg3 is the same for all devices participating in the inventory (subject to RAN2/SA2 agreements), the TBS field in the scheduling information for Msg3 as part of Msg2 is not needed.

Based on the discussion in the previous sections we propose the following:
Proposal 1	Toffset1 can be pre-configured in the standard based on the minimum processing capability of the device, reader’s CWT cancellation capability. Additional considerations, for eg: SFO can be discussed in RAN4.
Proposal 2	Toffset1 can be specified based on T1 value of RFID link timing parameters (Annex C-FLS [5] ) and impact of FEC.
Proposal 3	End of R2D transmission can be the end of last chip of the postamble.
Proposal 4	Toffset2 can be derived by the device based on the calculation of transmission time of Msg1 for X=1 and the value to be assumed for SFO. There is no need for the reader to explicitly schedule this parameter.
Proposal 5	Scheduling FDMA for Msg1 involves the reader providing a set of tuples containing (Tchip, R) such that their product   remains constant for all the scheduled resources.
Proposal 6	Additional restrictions on configuring combinations of (Tchip, R) are to be implemented by the reader so as to prevent overlaps in main lobes and restrictions due to harmonics.
Proposal 7	Device-specific D2R scheduling can support same as well as different D2R data rates.
Proposal 8	Indicating D2R chip duration and repetition separately during device-specific scheduling might be more efficient in terms of overall resource allocation.
Proposal 9	Support for X=1,2 for Msg1 and supporting only X=1 for Msg3 inevitably leads to interleaving Msg3 transmissions after every Msg2.
Proposal 10	Support variable bandwidths for dedicated scheduling of D2R transmissions from Msg3 onwards.
Proposal 11	The time duration for monitoring Msg2 in response to multiple Msg1 transmissions can be indicated as part of L1 control information preceding the Msg2 transmissions.
Proposal 12	A time monitoring window for monitoring L1 control information preceding Msg2 transmissions may be specified instead of a Msg2 monitoring window.
Proposal 13	RAN1 does not need to define different device1s with different capabilities. This does not exclude the possibility of devices supporting different D2R modulation formats (OOK/BPSK/both).
Proposal 14	TDMA related information for Msg1 scheduling includes configuring X value.
Proposal 15	FDMA related information for Msg1 scheduling includes frequency index Y and combinations of {R, }
Proposal 16	Scheduling information for Msg1 supports the following fields.

Proposal 17	TDMA related information for Msg3 scheduling can support fields including preamble lengths, midamble details, FEC and block repetition.
Proposal 18	Send an LS to RAN2 to clarify if Msg3 payload is the same for all devices.
Proposal 19	FDMA related information for Msg3 scheduling includes frequency index Y and combinations of {R, } for supporting Option 2. It can additionally support a 1-bit indication if option 1 is to be supported.
Proposal 20	Scheduling information for Msg3 supports the following fields-

Proposal 21	TDMA related information for other D2R scheduling from Msg5 onwards can benefit from supporting fields including TBS, preamble lengths, midamble details, FEC and block repetition.
Proposal 22	Scheduling information for other dedicated D2R messages support the following fields-

Proposal 23	D2R scheduling after Msg3 can also support an option of an additional 1 bit indicator to indicate that the scheduling information not specifically configured can follow the same values as that used for Msg3.
Proposal 24	Send the LS with the RAN1 agreements to RAN2 and RAN3 as well as RAN4.
Proposal 25	Indicate in the LS that Device 1 has no capabilities that require device capability signaling support.
Proposal 26	Discuss whether there are any device capabilities without capability signaling (e.g., D2R modulation) that should be highlighted in the LS.

3GPP TSG RAN WG1 Meeting #121	R1-2503227
St. Julian’s, Malta, May 19 – 23, 2025
Agenda Item:	9.4.4
Source:	Futurewei
Title:	Multiple access, scheduling and timing aspects for A-IoT
Document for:	Discussion and Decision 

Conclusion
The following observations / proposals were discussed in this contribution.
Msg1 / Msg2
Proposal 1: For the starting time of a D2R transmission for Msg1 after the end of the corresponding R2D transmission, slightly prefer signaling to provide the value of Toffset1.
Proposal 2: Confirm the working assumption with the following change to the FFS
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.
Proposal 3: For the FDMA of multiple Msg3 transmissions in response to a Msg2, support only the same data rate for the FDMed Msg3 transmissions.
Scheduling
Observation 1: The timing of a D2R transmission after the end of the corresponding R2D transmission (i.e., Msg3, command response) has not been specified.
Proposal 4: The starting time of a D2R transmission after the end of the corresponding R2D transmission is indicated by Toffset1.
Proposal 5: For the starting time of a D2R transmission other than Msg1 after the end of the corresponding R2D transmission, support signaling to provide the value of Toffset1.
The value of Toffset1 includes any processing time for FEC and message type
Proposal 6. The R2D chip duration for a PRDCH is the same as the clock-acquisition part of the R2D time acquisition signal immediately preceding the PRDCH.
Proposal 7: Support a joint encoding of the indicators for FEC and number of repetitions Rblock to generate the overall rate 1 (Rblock=1, no FEC), overall rate 1/2 (Rblock=1, Rcode=1/2), overall rate 1/3 (Rblock=1, Rcode=1/3), and overall rate 1/6 (Rblock=2, Rcode=1/3).

3GPP TSG-RAN WG1 Meeting #121                                        R1-2503297
St Julian’s, Malta, May 19-23, 2025

Agenda Item:	9.4.4
Source:	Huawei, HiSilicon
Title:	Multiplexing, scheduling, and other physical-layer procedures
Document for:	Discussion and Decision

Conclusions 
Based on the analysis in this contribution, we have the following proposals:
Proposal 1: Regarding the time gap between R2D and corresponding D2R, support followings:
Define Toffset3, which is the time gap between the end of Msg2 transmission in CBRA or the end of R2D transmission triggering CFRA, and the starting time of the corresponding D2R resource.
Define Toffset4, which is the time gap between the end of a R2D transmission and the starting time of the corresponding D2R resource after the random access procedure.
Toffset2 is indicated explicitly, and the value set is {60, 90, 120, 180, 240, 300, 360, 420}us.
For Toffset1, Toffset3, and Toffset4, assume “the timeline determination of any timing relationship refers to the end of padding”:
Toffset1 is 30us.
Toffset3 is 30us.
Toffset4 is 30us when FEC is not used, or 1500us when FEC is used.
If the timeline refers to the “start of padding”, then the duration of padding shall be added additionally
Proposal 2: No need to define TMsg2_start and TMsg2_end.
After TD2R_min of D2R transmission, device shall be able to receive the corresponding R2D at any time
Proposal 3: Regarding following timings, support:
TD2R_min is 10us
RAN1 does not define TD2R_max, TR2D_R2D_min, TD2R_D2R_min
Proposal 4: For R2D reception, there is nothing to consider in L1 scheduling information.
Proposal 5: For CBRA and CFRA, support R2D provides following scheduling information for corresponding D2R transmissions:
“0 bit” in following table means reuse the corresponding scheduling information for Msg1 in CBRA, or for 1st D2R Msg in CFRA. 
For frequency domain resource for Msg3 transmission, in addition to the already agreed Option 2, support Option 1 as a default if PRDCH does not provide the indication or based on a rule
“Option 1: the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device”

3GPP TSG RAN WG1 #121	R1-2503302
St Julian's, Malta, May 19th - 23rd, 2025

Source:	Nokia
Title:	AIoT Other aspects incl. multiplexing/multiple access, scheduling information, and timing relationships
Agenda item:	9.4.4
Document for:	Discussion and Decision

Conclusion

In this contribution we have made the following observations and proposals:


Proposal 2: In D2R control signaling, whether FEC is applied, which FEC code rate (if multiple code rates are supported) and the number of block level repetitions can be jointly encoded.
Proposal 3: For D2R scheduling, time domain resources shall be indicated by signaling in the corresponding PRDCH. 
Proposal 4: For D2R scheduling, frequency domain resources shall be indicated by signaling in the corresponding PRDCH. 
Observation 1: For D2R scheduling, the FDMA frequency domain resource can be indicated indirectly by signaling the chip duration and vice versa (assuming the bit duration is known).
Proposal 5: RAN1 to discuss whether for a given R2D transmission, “ID associated with device(s)” for R2D reception and for D2R scheduling is identical.

3GPP TSG RAN WG1 #121          		                                          R1-2503314
St Julian’s, Malta, May 19th – 23rd, 2025

Title:                     Discussion on Ambient IoT multiple access and timing
Source: 	        ZTE Corporation, Sanechips
Agenda item:       9.4.4
Document for:     Discussion

Conclusion
In this contribution, we discuss random access, timing aspect and scheduling information for Rel-19 A-IoT. And the relevant proposals are given below:
For X=1 or X=2, the starting time Toffset1 is predefined for the first Msg1 time domain resource.
The value of  is derived from , where a = [4], b = [20] and  equals to [4] us for FEC disabled and [12] us for FEC enabled.
The starting time for the second Msg1 time domain resource is calculated based on the duration of Msg1 time domain resource. And the duration of Msg1 time domain resource can be derived based on: 

The value of  be derived from , where  is the duration of a Msg1 time domain resource.
For TDMA of Msg1, the data rate for different TDMed Msg1 transmissions should be the same.
The maximum number of Msg1 responses that can be carried within a PRDCH for Msg2 does not need to be specified.
The pattern of multiple consecutive Msg2 transmissions and multiple FDMed Msg3 transmissions (e.g., Msg2-Msg2-Msg3) is not supported for A-IoT.
From device perspective, the starting time for Msg3 transmission can be defined as  after the end of the corresponding Msg2 transmission. 
, where a = [4], b = [20] and  equals to [10] us for FEC disabled and [60] us for FEC enabled.
For frequency-domain resource allocation for Msg3, Option 1 can be supported as a default if the PRDCH does not provide the indication.
In Option 1, the same FEC code rate and number of block repetitions employed for Msg1 can also be applied for Msg3 transmissions.
For FDMA of Msg3, different data rates for the FDMed Msg3 transmissions can be supported.
RAN1 should consider timing between other command (e.g., read and write) and its corresponding D2R response.
A common value of TD2R_min for different R2D responses to D2R transmissions is defined and this value can be derived from , where c = [10].
To sum up, Table 2 can be considered for D2R scheduling:
Table 2: D2R information field in R2D control information
For R2D messages other than the paging message, the transaction ID is implicitly conveyed through CRC mask.

3GPP TSG RAN WG1 #121		R1-2503361 
St Julian’s, Malta, MT, 19th – 23rd May, 2025
Source:	vivo
Title:	Remaining issues on other aspects for Rel-19 Ambient IoT
Agenda Item:	9.4.4
Document for:	Discussion and Decision

Conclusion: The R2D payload size (TBS-like) information is determined by MAC header, based on following agreement. 
At least the following field are required for at least for R2D in the MAC header– message type, length for SDU and variable part(s)
Proposal 3.2-1: Confirm the following working assumption
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

Proposal 3.2-2: Support separate indication of FEC and number of repetitions  
1-bit is used to enable/disable FEC
1 bit is used to indicate the repetition number is 1 or 2.

For timing relationships
Proposal 4.1: The value for TD2R_min should be one fixed value applicable to all devices in Rel-19 AIoT and include the necessary Tx-to-Rx transition time at the device side. 
Observation 1: Unlike NR UE, Rel-19 A-IoT device 1 does not support sleep function or autonomous re-access. The introduction of the Msg2 monitoring window does not provide benefits for device 1; instead, it complicates the device monitoring and increases specification and test efforts. 
Proposal 4.2:    
No need to define Msg2 monitoring window for Rel-19 A-IoT device 1. 
No need to define TD2R_max for Rel-19 A-IoT device 1. 

Other
Proposal 5: From RAN1 perspective, it may not need to define the maximum number of the Msg1 responses that can be carried within a PRDCH for Msg2. 
If needed, the maximum number of the Msg1 responses that can be carried within a PRDCH for Msg2 should not be larger than 2*Ymax, where Ymax is the maximum value of Y for FDMed Msg1 transmission.

3GPP TSG-RAN WG1 Meeting #121	         R1-2503362 
St. Julian’s, Malta 19 – 23 May, 2025
Agenda Item:	9.4.4
Title:	FL summary#1 on other aspects for Rel-19 Ambient IoT 
Source:	Moderator (vivo)
Document for:	Discussion, Decision

Conclusion 3.1: 
For CFRA and for a new R2D message other than the paging message for A-IoT device determining Msg1 resources, it is up to RAN2 to decide whether and how to support TDMA of X>1 and/or FDMA of Y>1 time-frequency resources for Msg1 transmissions.    

Starting time of time domain resource for Msg1 and Msg3/D2R

For Msg1 transmission  

For X=1 or X=2, the starting time for the first Msg1 time domain resource from the device perspective 
Companies’ views on the “FFS Toffset1 is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Option 1: Predefined in the spec with fixed value(s): [5], [6], [9], [13], [18?], [23], [31]
[5], [23] Predefined as one fixed value
[5]: i.e., 30us; 
[6] Up to RAN4 to determine the exact value
[9], [13] Predefined and account for the worst case, up to 0.26ms is needed 
[4], [31] Different values of Toffset1 are predefined for the Msg.1 with FEC and without FEC.  
Option 2: Predefined equation to derive the , where the equation is based on the  and  for the scheduled D2R transmission [1], [3], [10], [16], [20], [30], [32], [33], [36]
[1], [3], [10], [30]: 
[3], [10], [30] proposed a=[4]; 
[3], [10], [20] proposed b=[20] and [30] proposed b=[10]  
[3]: t equals to [4] us for FEC disabled and [12] us for FEC enabled.
[10]: t equals to 0 for FEC disabled; [0.5]ms for FEC enabled
[30]: t equals to 0 if CRC is not attached to at the end or CRC can be pre-calculated; Otherwise,  with sampling rate 
[20]: MAX(CAP duration, 20TD2R,chip)
[16], [36]: predefined in the spec in terms of a number of chips (i.e., based on the M value of the triggering R2D transmission)
In addition, [10], [30], [33] proposed to clarify for FDMA of Msg1 case, the D2R chip length should be “a reference D2R chip length” or “the D2R chip length corresponding to R=1” or “the D2R chip length corresponding to the smallest R among the FDMA of Msg1s” to align the starting time for Msg1 transmission
Option 3: Indicated explicitly by the R2D transmission triggering random access [2], [7], [8], [12], [15], [21], [22], [24], [28], [34]
Predefine a list of candidate values (absolute time or time unit level indication) and the reader explicitly indicates one of the value
[7]: Following options can be considered to determine the value of Toffset1
Option 1: Define Toffset1 as a number of slots with the Candidate values: {1, 2, 3, 4}.
Option 2: Define Toffset1 as an absolute time expressed in tenths of one millisecond with the  candidate values: {0.2ms, 0.4ms, 0.6ms, 0.8ms}.
Option 3: Define Toffset1 as a number of equivalent D2R symbols with the Candidate values: {3, 6, 9, 12}.
 About the impact of FEC impact for Msg1 transmission, 
[3]: additional time margin t=[4]us for FEC disabled and [12]us for FEC enabled
[5]: FEC has no impact here. Because before receiving paging, device can pre-generate the random ID and pre-calculate the CRC and performs coding. Thus, when FEC is used, the processing time can still be the same as no FEC case, i.e., 30us.
[30]: For Msg1/Msg3/D2R feedback, apply TBS restriction of [up to 12bytes] or use precalculated CRC, .
About the impact of “the end of R2D transmission triggering random access” ,
[5], [10]: If the end for timeline determination refers to the “start of padding”, additional time needs to be added; if the end for timeline determination refers to the “end of padding”, no additional time needs to be added.
[30]:  is counted from the end of the last bit of PRDCH (before the start of the padding) till the start of D2R preamble of corresponding D2R transmission.  
Round 1
FL1 Proposal 3.2.1-1
Select one option from the following 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.
Option 1: Toffset1 is predefined in the spec as one fixed value of [30]us  
FFS whether/how additional time needs to be added when FEC is used
Note: If the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1. 
Option 2: Toffset1 is derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission triggering random access  
+t1, where a=[4], b=[20] and t1≥0   
FFS t1 considering at least the FEC impact, if applicable, and/or R2D padding impact if the end of the R2D transmission is defined as before the start of padding
Option 3: Toffset1 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values 
FFS the set of predefined values     

From FL: 
For option2, some companies suggested clarifying the D2R chip duration for FDMA. My thinking is we can use the same interpretation as that for small frequency shifts in FDMA once agreed in AI 942.
About the FEC impact for Msg1, Msg3 and other D2R data transmissions, separate proposal is made in FL1 Proposal 3.2.3-3. 


For X=2, the starting time for the second Msg1 time domain resource from the device perspective
Most companies proposed to confirm the working assumption. In addition, companies’ views on the “FFS Toffset2 is predefined in the spec or derived by a rule or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Toffset2 is predefined in the spec: [14], [34?]
[14]: A set of Toffset2 values corresponds to the data rate are specified for the device. The appropriate value is selected for the second Msg1 transmission according to the indicated Msg1 data rate.
Toffset2 is derived by a rule based on the duration of the 1st Msg1 time domain resource and the gap between the two time domain resource considering the SFO impact: [1], [3], [6], [7], [10], [12], [13], [16?], [18], [23], [30], [31], [36] 
[6], [7], [12], [13], [16?], [20], [28], [30], [31], [36]: The value of Toffset2 can be implicitly derived as+Tgap, where Tgap = (Toffset1+TMsg1)×SFO×2, Tmsg1 is the duration of Msg.1 transmission length determined by 16-bit payload, 6-bit CRC, D2R chip length, FEC, repetition if applied and amble related parameter(s).
From FL: from above, assuming SFO=10%, Toffset2 = Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO  (equation 1), the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) (equation 2), combine equation 1 and equation 2, the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) = (Toffset1 + Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO) ×(1-SFO)  = 1.08 ×(Toffset1 + Tmsg1), which overlaps with the end of the first time domain resource with a slow clock given by (1+SFO)×(Toffset1 + Tmsg1) = 1.1 ×(Toffset1 + Tmsg1)
 
[2], [3], [10], [18]: Toffset2 should be set to prevent the second time domain resource for Msg1 transmission from device with fast clock from colliding with the first time domain resource for Msg1 transmission from device with slow clock at the reader side. Hence,  and by simplify it, , where te is 10% device clock error as defined in RAN4 
Toffset2 is indicated explicitly by the R2D transmission triggering random access: [2], [4], [5], [8], [9], [15], [22], [24], [32], [34]
[5]: Toffset2 is indicated explicitly, and the value set is {60, 90, 120, 180, 240, 300, 360, 420}us
[9]: 9 or 10 bits based on number of bits after FEC (if FEC is applied) and repetition (if repetition is applied) can be used for Toffset2 indication since the time duration of Toffset2 is likely to be less than 100ms.  
Round 1
FL1 Proposal 3.2.1-2 
Confirm the working assumption for determination of the starting time for the second Msg1 time domain resource for X=2 from device perspective, that is derived based on the starting time of the first Msg1 time domain resource plus Toffset2
Select one option from the following for Toffset2:
Option 1: , where
 is the duration of the 1st Msg1 time domain resource and  where  is the payload size of Msg1 and  is the number of CRC bits, is the number of ambles and  is the length of the D2R amble sequence 
te is the clock error defined in RAN4  
Option 2: Toffset2 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values 
FFS the set of predefined values 


For Msg3 transmission
Many companies also discussed the starting time for Msg3 time domain resource which should adopt the similar method as used for the first Msg1 time domain resource. In details,  
[5], [6], [9], [18], [32], [33] A similar terminology as Toffset1 between Msg2 and Msg3 can also be used to determine Msg3 time resource, with predefined value.
[5]: Similar as Toffset1, the value of Toffset3 mainly needs to consider device processing time, including: decoding the received R2D message, preparing the corresponding D2R message, and switch from R2D reception to D2R transmission. At least 30us is needed in this case. FEC has no impact here. Because device knows its ID in one paging round, and can pre-calculate the CRC and performs coding
[6]: the processing time requirement can be discussed in RAN4
[18]: If it is pre-defined, RAN1 also need to decide whether a value separate from Toffset1 should be defined.
[1], [3], [10], [30] From device perspective, the starting time for Msg3 transmission can be defined as  after the end of the corresponding Msg2 transmission. 
, where 
a = [4], b = [20] and  equals to [10] us for FEC disabled and [60] us for FEC enabled. [3]
a = [4], b = [10] and  equals to [0] us by applying TBS restriction of [up to 12bytes] or using precalculated CRC. [30]
[2], [5], [7], [22], [31]: The starting time of a D2R transmission after the end of the corresponding R2D transmission is indicated by R2D control information 
In addition, [5] proposed to apply the same time offset i.e., Toffset3 between “Msg2 and Msg3” in CBRA to “R2D Msg triggering CFRA and 1st D2R Msg” in CFRA. “1st D2R Msg” in CFRA is similar as Msg3 in CBRA, so they can have a unified design.
Round 1
FL1 Proposal 3.2.2-1
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.
Option 1: Toffset3 is predefined in the spec as one fixed value of [30]us  
FFS whether/how additional time needs to be added when FEC is used
Note: If the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset3. 
Option 2: Derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission for Msg2 
+t2, where a=[4], b=[20] and t2≥0   
FFS t2 considering at least the FEC impact, if applicable, and/or R2D padding impact if the end of the R2D transmission is defined as before the start of padding  
Option 3: Toffset3 is indicated explicitly in the R2D transmission for Msg2 from a set of predefined values 
FFS the set of predefined values    
From FL: Whether Toffset3 can be re-used as the time interval between the end of R2D transmission triggering CFRA and the starting time of the corresponding D2R resource depends on whether the content of the 1st D2R Msg in CFRA is the same as the content of the Msg3, hence a separate proposal FL1 Proposal 3.2.3-2 is made. 

For D2R data transmission 
For other D2R data transmission, companies views are similar as for Msg3 transmission and for Msg1 transmission on the 1st time domain resource, with a different time offset terminology and value(s). 
In addition, on the FEC impact on the processing time for different D2R transmissions, following Table 3.2.3 gives a brief summary.
Table 3.2.3 FEC impacts on Msg1, Msg3 and other D2R transmission after random access

Round 1
FL1 Proposal 3.2.3-1
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 after the random access procedure, from the device perspective.
Option 1: Toffset4 is predefined in the spec as fixed value(s).   
Toffset4 = [30]us when FEC is not used
Toffset4 = [1500]us when FEC is used 
Note: If the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset4. 
Option 2: Derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission  
+t3, where a=[4], b=[20] and t3≥0   
FFS t3 considering at least the FEC impact, if applicable, and/or R2D padding impact if the end of the R2D transmission is defined as before the start of padding   
Option 3: Toffset4 is indicated explicitly in the R2D transmission from a set of predefined values 
FFS the set of predefined values    


Round 1
FL1 Proposal 3.2.3-2
If the content of the first D2R message in CFRA is the same as that of Msg3 in CBRA,Toffset3 determines the start time of the first D2R message time domain resource, which is the time interval from the end of a R2D transmission triggering CFRA to the starting time of the first D2R message time domain resource, from the device perspective.
Otherwise, Toffset4 determines the start time of the first D2R message time domain resource, which is the time interval from the end of a R2D transmission triggering CFRA to the starting time of the first D2R message time domain resource, from the device perspective.
From FL: during SI, RAN2 agreed “In contention-free access, the A-IoT device directly sends the upper layer data (e.g. device ID) in its very first D2R message after being triggered (i.e. skip contention resolution Msg1/2).” While, no explicit agreement has been made in RAN2 whether the content for the 1st D2R message in CFRA is the same as that of Msg3 in CBRA. Considering this is the last RAN1 meeting above proposal is made.  

Round 1
FL1 Proposal 3.2.3-3
For Msg1 transmission, the processing time at device side is the same regardless of the use of FEC.
For Msg3 transmission, the processing time at device side is the same regardless of the use of FEC.
For D2R data transmission after random access procedure, when FEC is used, select one option from the following
Option 1: Add extra processing time at device side based on the D2R TBS compared to the case when FEC is not used 
Option 2: Add a fixed extra time at device side regardless of the D2R TBS compared to the case when FEC is not used 
For the 1st D2R data transmission in CFRA, when FEC is used 
If the content of the first D2R message in CFRA is the same as that of Msg3 in CBRA, the processing time at device side is the same as the case when FEC is not used 
Otherwise, same handling of the processing time as that for D2R data transmission after random access procedure.

From FL: Above proposal is made to address the FFS of FEC impact in Proposal 3.2.1-1 for Toffset1 for Msg1, Proposal 3.2.2-1 for Toffset3 for Msg3, and Proposal 3.2.3-1 for Toffset4 for other D2R data transmission after random access (RA). 
Data rate for Msg1 and Msg3

[30]: RAN1 needs to clarify the data rate, bit rate, chip rate for other cases of D2R with TDMA and/or FDMA, as listed in Table 1. Note that data rate is different from bit rate and chip rate, as defined as follows.
Data rate (bps): the number of information bits and CRC (if any) per second before FEC (if any)
Bit rate (bps): the number of bits per second after FEC (if any)
Chip rate (bps): the number of chips per second with , where R is the frequency shift factor
Table 1 configuration for D2R with TDMA/FDMA in [30]

[12]: the same data rate could be achieved by different combination of {Tb, repetition factor, FEC coding rate}, for example, date rate of {Tb = 133.33µs, repetition = 2, FEC = 1/3} and {Tb = 266.67 µs, repetition = 1, FEC = 1/3} are the same. But we have not seen the benefit of supporting this flexibility in Msg1/Msg.3 scheduling. Therefore, propose to male it clear that 
Same Tb, repetition factor and FEC coding rate are applied to all FDMed Msg.3 transmissions in response to a PRDCH for Msg.2 transmission.
Same Tb, repetition factor and FEC coding rate are applied to all FDMed Msg.1 transmissions (if supported) in response to R2D transmission triggering CFRA.

About data rate, in TR 38.769 Table 4.2.2-1, there are two notes for the data rate clarification as shown below:

About bit duration Tb, Tb= 2 × ×, as agreed in AI 9.4.2.
For Cases 4, 5, and 6 of CFRA, the current RAN2 agreement assumes no multiple devices are performing procedures with the given reader. FFS if we can assume or need to support multiple device scenario   
FL suggests focusing on Case 2 of CBRA Msg1 with TDMA and Case 7 Msg3 with FDMA. Case 3 of CBRA Msg1 with TDMA + FDMA will result from the decision made for Case 2.
Clarification is needed regarding the intention of the same data rate. FL views this as applying the same Tb, block repetition number, FEC coding rate, and amble-related parameters to all FDMed and/or TDMed D2R transmissions.

For the Case of CBRA Msg1 with TDMA of X=2, 
[3], [6], [34] proposed the same data rate
[30] proposed RAN1 to down select 
Opt1: support same Msg1 transmission time for 1st and 2nd time domain resource
Opt2: support shorter Msg1 transmission time in the 1st time domain resource than that of 2nd one 
Round 1
FL1 Proposal 3.3-1 
For following agreement, the same data rate means 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, is the same for the FDMed Msg1 transmissions.   
Comments?

Round 1
FL1 Proposal 3.3-2 
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, is the same for the TDMed Msg1 transmissions.  


For the Case of Msg3 with FDMA, 

[1] proposed to send an LS to RAN2 to clarify if Msg3 payload is the same for all devices and observed following 
[5]: In one paging round, Msg3 TBS can be known by device. Thus, there is no need to indicate TBS.
[18] proposed RAN1 needs to identify whether the Msg3 payload of devices is the same or not, and try to align the Msg3 transmission of devices. 
[20] proposed to keep the TBS carried in corresponding Msg2 to be the same for FDMed Msg3 transmissions
[24] proposed if the TBS of Msg.3 is variable, the different data rates for FDMA based multiple Msg.3 transmissions are supported.
About the TBS for Msg3, based on the section 5.7.2 of TS 23.369 V0.3.0, copy relevant text below

Considering this is the last RAN1 meeting, for the case that Msg3 TBS is the same for all devices participating in the inventory, companies views on the data rate for the FDMed Msg3 transmissions are summarized as below:
Alt.1: Support same data rate only: [2], [5], [9], [10], [14], [20], [21], [34]
Cannot improve the spectrum efficiency and complexity at reader side
Even one device can use higher data rate to reduce its Msg3 transmission time, Reader still has to wait until all the FDMed devices have finished their Msg3 transmission. And what more, Reader may need to know the channel condition of devices to adjust the data rate. 
Alt.2: Support same and different data rate(s): [1?], [3], [6], [23], [30], [35]
Offers improved spectral efficiency and reduced random access latency.
Round 1
FL1 Proposal 3.3-3 
For the case that the payload size for Msg3 transmissions is the same for all devices participating in the inventory, down-select one option from the following:  
Option 1: 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, is the same for the FDMed Msg3 transmissions 
Option 2: 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, can be different for the FDMed Msg3 transmissions 

Please also indicate your preference.

Timing relations 
Timing for R2D response to D2R
Value(s) for TD2R_min
Option 1: Fixed to one small value, i.e., =[10]us: [1], [5], [10]
[1]: A large enough switching time does not seem to be very necessary since A-IoT devices work with an envelope detector architecture. No switching between frequency bands is required to go from transmit to reception mode
[5], [10]: 10us
Option 2: derived based on D2R chip duration, i.e, =c×, where c=[3] or [10]: [3], [31], [33], [34]
[3]:, where c = [10].
[30]: , where  is the chip duration and for Msg1/Msg3 with FDMA, the chip duration  of the smallest frequency shift for the FDMA is used to derive .  
Option 3: request RAN4 to define the value for 
[22]: Given that minimum timing requirements (e.g., TD2R_min and any additional parameters to be agreed in this meeting) involves RF turn-around time, and base band modulation/demodulation time, which is highly dependent on implementation and within RAN4’s expertise, as well as considering that this is the last RAN1 meeting, it might be appropriate to request RAN4 to define these parameters.
Round 1
FL1 Proposal 4.1 
Select one option from the following for TD2R_min:
Option 1: TD2R_min is predefined in the spec as one fixed value of [10]us  
Option 2: TD2R_min is derived as TD2R_min= c  ,  is the D2R chip duration indicated in the R2D transmission scheduling the D2R transmission  
FFS c=[3] or [10] 
Option 3: Up to RAN4 to define the value for TD2R_min.  

The necessity and complexity to define the “Msg2 monitoring window” including the both the starting time e.g., TMsg2_start and TMsg2_end/TD2R_max for Msg2 monitoring from device perspective, companies’ views are summarized in the following:
No: It is not necessary  
[2], [3], [5], [6], [7], [10], [12], [20] 
Power saving is not considered/critical for device Type 1 in Rel. 19
The basic assumption of A-IoT design is the device always monitors R2D, when it is not otherwise occupied by e.g. R2D reception or processing. 
The start indicator part (SIP) in the preamble of every PRDCH transmission triggers the device to detect the Msg2 at each PRDCH transmission.
No impact on device behavior even without defining the monitoring window
E.g., If the device does not receive the Msg2 transmission by the next paging message, the device considers the A-IoT Msg1 transmission failed.

Yes: It is beneficial for device power saving or to determine a random access failure from physical layer if the Msg2 is not received within the Msg2 monitoring window.
[8], [9?], [16], [19], [22], [25], [28], [29], [30], [31], [32], [33], [34], [36]

Other way instead of specifying a Msg2 monitoring window: [1]
[1] proposed instead of specifying a Msg2 monitoring window, a time monitoring window for monitoring L1 control information preceding Msg2 transmissions may be specified and the L1 control information can contain the individual start times (or offsets) for Msg2 transmissions corresponding to each Msg1.

Details on Msg2 monitoring
[8]: If the number of configured time domain resources is small, or the interval between the first time domain resource and the MSG2 monitoring starting occasion is not long, the common starting occasion for MSG2 monitoring shall be supported, otherwise the separate starting occasion is more appropriate.
[9]: A larger TD2R_max for FDMA than TD2R_max for basic no multiplexing case can be considered to solve the issue of Msg2 falling out of [TD2R_min, TD2R_max] due to SFO.
[19], [29], [36]: Support association between the selected Msg1 time and frequency resources to its Msg2 time resources. 
[29] also proposed a Msg2 transmission order can be provided from initial PRDCH for Msg2 transmission.
[36] also proposed to consider Early Indication (EI) field indicating whether PRDCH(s) contains Msg2 corresponding to each access occasion configured for Msg1.
[22]: 
For Msg2 corresponding to one or more Msg1, a device starts monitoring the PRDCH providing Msg2 TD2R_min after the end of X time domain resources for Msg1 transmission. The monitoring window can be Δ = TD2R_max - TD2R_min such that the start of PRDCH falls within the Δ time interval. If Msg2 is not received within the Δ time interval, the device preceives that the current inventory round is unsuccessful and restarts the inventory round, e.g., retransmit Msg1 in a later round.as shown in Fig.9

Fig 9 of [22]

[33]:
TD2R_min and TD2R_max are defined based on multiple of chip length for D2R transmission when R value is 1:
TD2R_min= D* chip_lengthD2R_R=1 
TD2R_max= E* chip_lengthD2R_R=1 
Reference point for both TD2R_min and TD2R_max are defined as follows:
Starts from Toffset2 when X=2
Starts from the end of Msg1 transmission when X=1
About the reference time on the starting time for Msg2 monitoring /window, it is the end of the last of X time domain resource(s) determined for Msg1 transmission(s): [6], [22], [28], [31], [32], [33], [36]
Power saving is not crucial for Rel-19 A-IoT, which only considers device 1 without sleep function. Following direction 1, where the Reader doesn't inform the device about its availability, a simple and consistent approach is to have device 1 monitor Msg2 following the Tx-to-Rx switching time after transmitting Msg1. No critical issue is identified by the following in the TS 38.291 [37].

In addition, it should be noted that failure detection is addressed in Section 5.5 of TS 38.391 [38]. FL suggests lowering the priority of this topic in RAN1.
 
Other timing relation aspects
For the time interval between two different consecutive R2D transmissions to the same A-IoT device, TR 38.769 captures TR2D_R2D_min as the minimum time between two different consecutive R2D transmissions to the same A-IoT device.
[5], [7] proposed RAN1 does not define TR2D_R2D_min, TD2R_D2R_min
[22], [25], [32], [34] proposed to define TR2D_R2D_min, considering the following
[22]: There is a need to define TR2D_R2D_min considering that there should be a sufficient processing time provisioned for a device to process back-to-back R2D transmissions such as a PRDCH providing a paging message followed by another PRDCH providing a triggering message, or a PRDCH providing a command followed by another PRDCH providing a command, etc. There is no need to define TR2D_R2D_max, given that R2D transmission can occur at any time.    
[25]: The minimum time interval between R2D transmissions TR2D_R2D_min can be considered regardless of whether one or more of the R2D transmissions targets the device or not. 
[34]: Beneficial to define TR2D_R2D_min to avoid the device to continuous reception for power saving
From FL: Currently, the procedure or interaction between the AIoT paging message and the new R2D message is not clear and RAN2 is still discussing it. Since this is the last RAN1 meeting, we can keep the parameter open without making any agreement on TR2D_R2D_min or we can try to make agreement based on the if condition.   
Round 1
FL1 Proposal 4.2
Option 1: Keep TR2D_R2D_min open without any agreement. 
Option 2: TR2D_R2D_min is defined such that a device is not require to monitor a R2D transmission earlier than TR2D_R2D_min after the end of a previous R2D transmission to the device, if the case that two different consecutive R2D transmissions to the same A-IoT device exits. 
Please indicate your preference on handling the TR2D_R2D_min.

Scheduling information
For R2D reception  
The agreements related to ID and Message Type made by RAN2#129 can be found in Annex C. 
Overview for R2D reception
Nothing need to be considered in R2D L1 scheduling information.
[5], [9], [10], [14], [20]

Following needs to be indicated in R2D control information  
ID associated with device(s) intended for the reception of R2D or AS ID [4], [8], [12], [22],[23], [25],[30], [31], [35] 
From FL: Based on RAN2 agreements, the Paging ID, Transaction ID, Echoed Random ID, Assigned AS ID and “message type” of R2D Message Type is/are included in the higher layer data and captured in TS 38.391 [38] section 6 of Protocol Data Units, formats and parameters.
TBS: either explicitly or implicitly based on message type indication for messages having a fixed size. [22] [31] 
Reserved bits for forward compatibility [4]

About explicit TBS indication, AI 9.4.3 will discuss it. 
[4]: Compare the overhead of TBS indication vs. postamble size to decide on the method indicating end of PRDCH transmission.
[10], [12]: As RAN2 has already agreed that one field is included in the MAC header for SDU length indication, there is no needed to support R2D post-amble or even physical layer control information for R2D TBS indication, the device can be aware of the end of PRDCH by decoding the MAC header in advance.
[12] proposed to send an LS to RAN2 to inform them that RAN1 relies on the MAC header to indicates the end of R2D transmission when MAC PDU includes one MAC SDU, or multiple MAC PDU if supported by RAN2.
[14]: For scheduling R2D transmission, any scheduling information related to resource allocation that needs to be signaled is indicated by higher-layer signaling via the PRDCH indicated by higher-layer signaling 
[30]: R2D L1 control indicate TBS

PRDCH chip duration
Option 1: Same as clock-acquisition part of the R2D preamble [2], [5], [6], [8], [10], [22], [23], [27], [34] 
No clear motivation and rather it increases device complexity for switching the chip duration and impact on the chip synchronization accuracy.
Option 2: indicated by R2D L1 control 
[30]: If not configured, the R2D data payload assumes the same parameters as R2D L1 control
Option 3: The clock acquisition signal can be transmitted in two parts, the first part contains smaller M value indicating M value used for the L1 control signaling while the second part uses larger M value indicating the M value used in data. 
[4]
Round 1
FL1 Proposal 5.1-1
The R2D chip duration for a PRDCH is the same as the clock-acquisition part of the R2D time acquisition signal immediately preceding the PRDCH.

In case there is any explicit scheduling information agreed for R2D reception, 
On R2D L1 control with separate CRC and higher layer control with Joint CRC  
[4], [8], [15], [22], [23], [30], [31] support R2D L1 control with separate CRC  
[4], [15], [22], [30] discussed the main motivation is for power saving, by allowing a device to early determine whether to continue or terminate R2D reception based on control information. 
[8] discussed another motivation is for different reliability between the R2D control and data.
[7] support higher layer control with Joint CRC  
Power saving by early identification is Not essential for Rel-19 device 1
Prolonged transmission due to additional CRC
Increased device complexity for processing two CRCs and potential additional behaviour depending on two CRC check
Increased specification efforts, potentially including the introduction of multiple 'DCI'.
[15]: Down-select between fixed format L1 control multiplexed with PRDCH data, or a single PRDCH transmission with higher-layer control and data multiplexed together
In addition, [27] proposed to attach a separate CRC to the first part of the PRDCH. It seems imply a separate CRC is attached to the “MAC header”.
To avoid blind detection or introduction of multiple 'DCI', following options proposed for identification of the R2D L1 control information with separate CRC
[15], [22]: The L1 R2D control information should have a fixed size and attached with a separate CRC. 
The R2D control information carrying “ID” of Paging ID, Transaction ID, Echoed Random ID, Assigned AS ID and “message type” of R2D Message Type was agreed to be included in the higher layer data, see TS 38.391 [38] figure 4.2-1 in section 4.2 and section 6 of Protocol Data Units, formats and parameters. 
We can revisit this if explicit scheduling information is agreed upon for R2D reception.

For D2R transmission   
Joint or Separate indication of FEC and block level repetition
Alt.1: Separate indication of FEC and number of repetitions  
[1], [5], [6], [7], [9], [10], [20], [31], [34]: small specification effort and full indication flexibility.
[5], [6], [10], [20]: 1 bit is used to indicate that whether FEC is applied for the D2R transmission and 1 bit is used to indicate the number (1 or 2) of block-level repetitions for D2R. 
Alt 2: joint indication of FEC and number of repetitions [2], [3], [4], [8], [11], [18], [24], [30] 
[2] Support a joint encoding of the indicators for FEC and number of repetitions Rblock to generate the overall rate 1 (Rblock=1, no FEC), overall rate 1/2 (Rblock=1, Rcode=1/2), overall rate 1/3 (Rblock=1, Rcode=1/3), and overall rate 1/6 (Rblock=2, Rcode=1/3).
[3] Code rates and repetitions combinations candidates {1, 1}, {1/2, 1}, {1/3, 1}, {1/3, 2} and candidates {1, 1}, {1/3, 1}, {1/3, 2}, {1/3, 4} are proposed, which require 2 bits for indication.
[8]: 3-bit by following table 
[18] proposed to adopt table 2 for joint indication
[30]: 
Alt1: 2bits for {no FEC, FEC1/2, FEC1/3, FEC1/3+rep2}
Alt2: 2bits for {no FEC, FEC 1/3, FEC 1/3+rep2, FEC 1/3+rep4}
Alt3: 2bits for {no FEC, FEC 1/3, FEC 1/3+rep2, reserved}
Round 1
FL1 Proposal 5.2-1
Select one option from the following for indicating the the FEC and the number of block-level repetition(s) for PDRCH transmission in the corresponding PRDCH:
Option 1: Separate indication of FEC and number of block-level repetitions
If FEC coding rate supports 1/3 only, 1-bit indication is used; If FEC coding rate supports 1/3 and 1/2, 2-bit indication is used
If the number of values for block-level repetition number is 2, 1-bit indication is used; if the number of values for block-level repetition number is more than 2, 2-bit indication is used 
  
Option 2: 2-bit joint indication of FEC and number of block-level repetitions, down-select one from the following
Alt1: 2bits for (no FEC, Rblock=1), (Rcode=1/3, Rblock=1),  (Rcode=1/3, Rblock=2), (reserved) 
Alt2: 2bits for (no FEC, Rblock=1), (Rcode=1/3, Rblock=1), (Rcode=1/3, Rblock=2), (Rcode=1/3, Rblock=4) 
Alt3: 2bits for (no FEC, Rblock=1), (Rcode=1/2, Rblock=1), (Rcode=1/3, Rblock=1), (Rcode=1/3, Rblock=2) 
From FL: The main motivation for joint indication is signalling overhead reduction, hence 2-bit joint indication proposed here. 

About the TBS indication, no companies against to confirm the working assumption.  
Round 1
FL1 Proposal 5.2-2
Confirm the following working assumption  
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

Scheduling information for Msg1
[1] proposed to support the following fields 

[5] proposed to support the following fields

[30] The R2D control to schedule Msg1/Msg3/D2R data have multiple components, as summarized in Table 3.
Table 3 R2D control for PDRCH [30]

Scheduling information for Msg3
[1] proposed to support the following fields  

[5] proposed to support the following fields

Scheduling information for D2R data 
[1] proposed to support the following fields 

[3] To sum up, Table 2 can be considered for D2R scheduling:
Table 2: D2R information field in R2D control information [3]

[5] proposed to support the following fields


Omit some scheduling information for the subsequent Msg3 and/or D2R data transmission 
Frequency domain resource for Msg3 transmission
Companies’ views for above FFS: support option 1 as a default if PRDCH does not provide the indication or based on a rule, are following 
Support option 1 to reduce R2D signaling overhead.
[3], [6], [15], [18], [19], [20], [23], [25], [29], [32]: support option 1 as a default if PRDCH does not provide the indication
[3]: In Option 1, the same FEC code rate and number of block repetitions employed for Msg1 can also be applied for Msg3 transmissions.
[3]: whether and how MAC payload indicate which of the two options to be used can be left to RAN2.
[4], [34]: support option 1 as a default when X=1 (based on a rule) 

[5]: support option 1 as a default if PRDCH does not provide the indication or based on a rule?
Device already knows Y pairs of {R, T_chip} that are used for Msg1.
In separate Msg2 case: this Msg2 only needs to schedule 1 device, so a codepoint way can be used, i.e., use log2(Y) bits to indicate which one pair of {R, T_chip} among the ones for Msg1 is reused for Msg3.
In common Msg2 case: a bitmap way can be considered, which only needs Y bit, where there are N “1”s in the bitmap, and “1” means this resource is to be used for Msg3, “0” means this resource is not to be used for Msg3, and N is the number of scheduled devices in Msg2. 
[9]: The frequency domain resource for Msg3 can be determined based on successfully reception state of Msg1 and predefined frequency resources orders. For example, Msg2 can provide a bitmap where each bit corresponds to reception state of Msg1 in one frequency resource.

Do not support option 1: [1], [7], [10], [13], [22], [28] 
Inefficient resource usage 
Complex the operation as it involves a decision making on whether an explicit indication is provided or not
Additional signaling is needed to inform which option, option 1 or 2 is used for Msg3 transmission 

Other scheduling information  
[1]: D2R scheduling after Msg3 can also support an option of an additional 1 bit indicator to indicate that the scheduling information not specifically configured can follow the same values as that used for Msg3. 
[3]: if the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device, the same FEC code rate and number of block repetitions employed for Msg1 can also be applied for Msg3 transmissions.
[5]: in one paging round, Msg1, Msg3, and other D2R messages should have similar coverage requirement, so Msg3, and other D2R messages can reuse following scheduling information of Msg1 transmission:
Preamble length
Midamble details
Apply FEC or not
Block repetition
{R, }
[9]: If no Msg3 scheduling information is carried by Msg2, Msg3 use the same data rate and chip rate as Msg1.

From FL: check the progress on the signalling design in AI 942 for D2R chip duration and small frequency shift and in AI 943 for amble related information. Then update the following list of D2R scheduling information with the bit length for Msg1, Msg3 and D2R data transmission.   
For Msg1, following D2R scheduling information needs to be indicated in the R2D transmission triggering the contention based random access 
The number of time domain resources for transmission: 1 bit
Amble length 
Amble related information, including the interval in bits for D2R amble insertion, if applicable 
D2R chip duration  
Small frequency shift(s) 
the block repetition number
the channel coding information

For Msg3 or the first D2R message in CFRA, following D2R scheduling information needs to be indicated in the R2D transmission for Msg2 or for triggering the CFRA, assuming the payload size for Msg3 and the first D2R message is the same for all devices participating in the inventory
Amble length 
Amble related information, including the interval in bits for D2R amble insertion, if applicable 
D2R chip duration  
Small frequency shift(s) 
the block repetition number
the channel coding information

For D2R data after random access, following D2R scheduling information needs to be indicated in the R2D transmission scheduling the D2R data 
TBS indication: 7-bit byte level indication 
Amble length 
Amble related information, including the interval in bits for D2R amble insertion, if applicable 
D2R chip duration  
Small frequency shift 
the block repetition number
the channel coding information
   
Proposals for offline discussions
Proposals for May. 19th Offline



Agreements achieved in RAN1#121 meeting
TBU

3GPP TSG-RAN WG1 Meeting #121	         R1-2503363 
St. Julian’s, Malta 19 – 23 May, 2025
Agenda Item:	9.4.4
Title:	FL summary#2 on other aspects for Rel-19 Ambient IoT 
Source:	Moderator (vivo)
Document for:	Discussion, Decision

Conclusion 3.1: 
For CFRA and for a new R2D message other than the paging message for A-IoT device determining Msg1 resources, it is up to RAN2 to decide whether and how to support TDMA of X>1 and/or FDMA of Y>1 time-frequency resources for Msg1 transmissions.    

Round 2
FL2 Proposed conclusion 3.1a
For CFRA, 
RAN1 assumes X=1 and Y=1 in the paging message for A-IoT device determining Msg1 resources. 
It is up to RAN2 to decide signaling details for the case of X=2 and/or Y>1 time-frequency resources for Msg1 transmissions if multiple devices are scheduled in CFRA.


FL2 Proposed conclusion 3.1b
For a new R2D message other than the paging message for A-IoT device determining Msg1 resources, down-select from the following:
Alt.1: RAN1 does not see the need to change X and Y value by the new R2D message
Alt.2: it is up to RAN2 to decide whether and how to change X and Y value by the new R2D message

Starting time of time domain resource for Msg1 and Msg3/D2R

For Msg1 transmission  

For X=1 or X=2, the starting time for the first Msg1 time domain resource from the device perspective 
Companies’ views on the “FFS Toffset1 is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Option 1: Predefined in the spec with fixed value(s): [5], [6], [9], [13], [18?], [23], [31]
[5], [23] Predefined as one fixed value
[5]: i.e., 30us; 
[6] Up to RAN4 to determine the exact value
[9], [13] Predefined and account for the worst case, up to 0.26ms is needed 
[4], [31] Different values of Toffset1 are predefined for the Msg.1 with FEC and without FEC.  
Option 2: Predefined equation to derive the , where the equation is based on the  and  for the scheduled D2R transmission [1], [3], [10], [16], [20], [30], [32], [33], [36]
[1], [3], [10], [30]: 
[3], [10], [30] proposed a=[4]; 
[3], [10], [20] proposed b=[20] and [30] proposed b=[10]  
[3]: t equals to [4] us for FEC disabled and [12] us for FEC enabled.
[10]: t equals to 0 for FEC disabled; [0.5]ms for FEC enabled
[30]: t equals to 0 if CRC is not attached to at the end or CRC can be pre-calculated; Otherwise,  with sampling rate 
[20]: MAX(CAP duration, 20TD2R,chip)
[16], [36]: predefined in the spec in terms of a number of chips (i.e., based on the M value of the triggering R2D transmission)
In addition, [10], [30], [33] proposed to clarify for FDMA of Msg1 case, the D2R chip length should be “a reference D2R chip length” or “the D2R chip length corresponding to R=1” or “the D2R chip length corresponding to the smallest R among the FDMA of Msg1s” to align the starting time for Msg1 transmission
Option 3: Indicated explicitly by the R2D transmission triggering random access [2], [7], [8], [12], [15], [21], [22], [24], [28], [34]
Predefine a list of candidate values (absolute time or time unit level indication) and the reader explicitly indicates one of the value
[7]: Following options can be considered to determine the value of Toffset1
Option 1: Define Toffset1 as a number of slots with the Candidate values: {1, 2, 3, 4}.
Option 2: Define Toffset1 as an absolute time expressed in tenths of one millisecond with the  candidate values: {0.2ms, 0.4ms, 0.6ms, 0.8ms}.
Option 3: Define Toffset1 as a number of equivalent D2R symbols with the Candidate values: {3, 6, 9, 12}.
 About the impact of FEC impact for Msg1 transmission, 
[3]: additional time margin t=[4]us for FEC disabled and [12]us for FEC enabled
[5]: FEC has no impact here. Because before receiving paging, device can pre-generate the random ID and pre-calculate the CRC and performs coding. Thus, when FEC is used, the processing time can still be the same as no FEC case, i.e., 30us.
[30]: For Msg1/Msg3/D2R feedback, apply TBS restriction of [up to 12bytes] or use precalculated CRC, .
About the impact of “the end of R2D transmission triggering random access” ,
[5], [10]: If the end for timeline determination refers to the “start of padding”, additional time needs to be added; if the end for timeline determination refers to the “end of padding”, no additional time needs to be added.
[30]:  is counted from the end of the last bit of PRDCH (before the start of the padding) till the start of D2R preamble of corresponding D2R transmission.  
Round 1
FL1 Proposal 3.2.1-1
Select one option from the following 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.
Option 1: Toffset1 is predefined in the spec as one fixed value of [30]us  
FFS whether/how additional time needs to be added when FEC is used
Note: If the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1. 
Option 2: Toffset1 is derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission triggering random access  
+t1, where a=[4], b=[20] and t1≥0   
FFS t1 considering at least the FEC impact, if applicable, and/or R2D padding impact if the end of the R2D transmission is defined as before the start of padding
Option 3: Toffset1 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values 
FFS the set of predefined values     

From FL: 
For option2, some companies suggested clarifying the D2R chip duration for FDMA. My thinking is we can use the same interpretation as that for small frequency shifts in FDMA once agreed in AI 942.
About the FEC impact for Msg1, Msg3 and other D2R data transmissions, separate proposal is made in FL1 Proposal 3.2.3-3. 

Round 2
Following is agreed on Monday online
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.

Based on the online discussions, following questions are asked.
FL2 Question 3.2.1-1a
For CBRA, what is your preferred way on determination of the smallest value for Toffset1?
Option 1: RAN1 defines the smallest value is 30us for Toffset1 and RAN4 can revisit it if they have concern.
Option 2: Up to RAN4 to decide the smallest value for Toffset1. 


FL2 Question 3.2.1-1b
For CBRA, in addition to the smallest value of Toffset1, are there any additional value(s) needed?
If Yes, what is/are the additional value(s) and how to use it?


For X=2, the starting time for the second Msg1 time domain resource from the device perspective
Most companies proposed to confirm the working assumption. In addition, companies’ views on the “FFS Toffset2 is predefined in the spec or derived by a rule or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Toffset2 is predefined in the spec: [14], [34?]
[14]: A set of Toffset2 values corresponds to the data rate are specified for the device. The appropriate value is selected for the second Msg1 transmission according to the indicated Msg1 data rate.
Toffset2 is derived by a rule based on the duration of the 1st Msg1 time domain resource and the gap between the two time domain resource considering the SFO impact: [1], [3], [6], [7], [10], [12], [13], [16?], [18], [23], [30], [31], [36] 
[6], [7], [12], [13], [16?], [20], [28], [30], [31], [36]: The value of Toffset2 can be implicitly derived as+Tgap, where Tgap = (Toffset1+TMsg1)×SFO×2, Tmsg1 is the duration of Msg.1 transmission length determined by 16-bit payload, 6-bit CRC, D2R chip length, FEC, repetition if applied and amble related parameter(s).
From FL: from above, assuming SFO=10%, Toffset2 = Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO  (equation 1), the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) (equation 2), combine equation 1 and equation 2, the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) = (Toffset1 + Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO) ×(1-SFO)  = 1.08 ×(Toffset1 + Tmsg1), which overlaps with the end of the first time domain resource with a slow clock given by (1+SFO)×(Toffset1 + Tmsg1) = 1.1 ×(Toffset1 + Tmsg1)
 
[2], [3], [10], [18]: Toffset2 should be set to prevent the second time domain resource for Msg1 transmission from device with fast clock from colliding with the first time domain resource for Msg1 transmission from device with slow clock at the reader side. Hence,  and by simplify it, , where te is 10% device clock error as defined in RAN4 
Toffset2 is indicated explicitly by the R2D transmission triggering random access: [2], [4], [5], [8], [9], [15], [22], [24], [32], [34]
[5]: Toffset2 is indicated explicitly, and the value set is {60, 90, 120, 180, 240, 300, 360, 420}us
[9]: 9 or 10 bits based on number of bits after FEC (if FEC is applied) and repetition (if repetition is applied) can be used for Toffset2 indication since the time duration of Toffset2 is likely to be less than 100ms.  
Round 1
FL1 Proposal 3.2.1-2 
Confirm the working assumption for determination of the starting time for the second Msg1 time domain resource for X=2 from device perspective, that is derived based on the starting time of the first Msg1 time domain resource plus Toffset2
Select one option from the following for Toffset2:
Option 1: , where
 is the duration of the 1st Msg1 time domain resource and  where  is the payload size of Msg1 and  is the number of CRC bits, is the number of ambles and  is the length of the D2R amble sequence 
te is the clock error defined in RAN4  
Option 2: Toffset2 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values 
FFS the set of predefined values 


Round 2


Please check companies’ comments in the first round. 
FL2 Question 3.2.1-2a

For Option 1 that , where  is the duration of the 1st Msg1 time domain resource, what is the  and  value considering the 10% SFO to avoid the resource overlapping between the first and second time domain resource and device complexity for calculating the ?



FL2 Question 3.2.1-2b

For Option 2 that Toffset2 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values,what are the predefined values and give the justification 


For Msg3 transmission
Many companies also discussed the starting time for Msg3 time domain resource which should adopt the similar method as used for the first Msg1 time domain resource. In details,  
[5], [6], [9], [18], [32], [33] A similar terminology as Toffset1 between Msg2 and Msg3 can also be used to determine Msg3 time resource, with predefined value.
[5]: Similar as Toffset1, the value of Toffset3 mainly needs to consider device processing time, including: decoding the received R2D message, preparing the corresponding D2R message, and switch from R2D reception to D2R transmission. At least 30us is needed in this case. FEC has no impact here. Because device knows its ID in one paging round, and can pre-calculate the CRC and performs coding
[6]: the processing time requirement can be discussed in RAN4
[18]: If it is pre-defined, RAN1 also need to decide whether a value separate from Toffset1 should be defined.
[1], [3], [10], [30] From device perspective, the starting time for Msg3 transmission can be defined as  after the end of the corresponding Msg2 transmission. 
, where 
a = [4], b = [20] and  equals to [10] us for FEC disabled and [60] us for FEC enabled. [3]
a = [4], b = [10] and  equals to [0] us by applying TBS restriction of [up to 12bytes] or using precalculated CRC. [30]
[2], [5], [7], [22], [31]: The starting time of a D2R transmission after the end of the corresponding R2D transmission is indicated by R2D control information 
In addition, [5] proposed to apply the same time offset i.e., Toffset3 between “Msg2 and Msg3” in CBRA to “R2D Msg triggering CFRA and 1st D2R Msg” in CFRA. “1st D2R Msg” in CFRA is similar as Msg3 in CBRA, so they can have a unified design.
Round 1
FL1 Proposal 3.2.2-1
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.
Option 1: Toffset3 is predefined in the spec as one fixed value of [30]us  
FFS whether/how additional time needs to be added when FEC is used
Note: If the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset3. 
Option 2: Derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission for Msg2 
+t2, where a=[4], b=[20] and t2≥0   
FFS t2 considering at least the FEC impact, if applicable, and/or R2D padding impact if the end of the R2D transmission is defined as before the start of padding  
Option 3: Toffset3 is indicated explicitly in the R2D transmission for Msg2 from a set of predefined values 
FFS the set of predefined values    
From FL: Whether Toffset3 can be re-used as the time interval between the end of R2D transmission triggering CFRA and the starting time of the corresponding D2R resource depends on whether the content of the 1st D2R Msg in CFRA is the same as the content of the Msg3, hence a separate proposal FL1 Proposal 3.2.3-2 is made. 

Round 2
FL2 Proposal 3.2.2-1a
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.
Toffset3 has the same design and value set of Toffset1

For D2R data transmission 
For other D2R data transmission, companies views are similar as for Msg3 transmission and for Msg1 transmission on the 1st time domain resource, with a different time offset terminology and value(s). 
In addition, on the FEC impact on the processing time for different D2R transmissions, following Table 3.2.3 gives a brief summary.
Table 3.2.3 FEC impacts on Msg1, Msg3 and other D2R transmission after random access

Round 1
FL1 Proposal 3.2.3-1
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 after the random access procedure, from the device perspective.
Option 1: Toffset4 is predefined in the spec as fixed value(s).   
Toffset4 = [30]us when FEC is not used
Toffset4 = [1500]us when FEC is used 
Note: If the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset4. 
Option 2: Derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission  
+t3, where a=[4], b=[20] and t3≥0   
FFS t3 considering at least the FEC impact, if applicable, and/or R2D padding impact if the end of the R2D transmission is defined as before the start of padding   
Option 3: Toffset4 is indicated explicitly in the R2D transmission from a set of predefined values 
FFS the set of predefined values    


Round 2
FL2 Proposal 3.2.3-1a
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 after the random access procedure, from the device perspective. 
Select one option from the following for Toffset4 
Option 1: Toffset4 is predefined in the spec as fixed value(s).   
Toffset4 = 30us when FEC is not used
Toffset4 = 1500us when FEC is used 
Option 2: Derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission  
+t3, where a=4, b=20 and t3≥0   
Determine t3 within this meeting considering at least the FEC impact, if applicable
Option 3: Toffset4 is indicated explicitly in the R2D transmission from a set of predefined values 
The predefined values are {30, 40, 50, 60}us when FEC is not used and {1500, 2000, 2500, 3000}us when FEC is used
If the end of the R2D transmission is defined as before the start of padding, the length of padding is additionally added to Toffset4.

Round 1
FL1 Proposal 3.2.3-2
If the content of the first D2R message in CFRA is the same as that of Msg3 in CBRA,Toffset3 determines the start time of the first D2R message time domain resource, which is the time interval from the end of a R2D transmission triggering CFRA to the starting time of the first D2R message time domain resource, from the device perspective.
Otherwise, Toffset4 determines the start time of the first D2R message time domain resource, which is the time interval from the end of a R2D transmission triggering CFRA to the starting time of the first D2R message time domain resource, from the device perspective.
From FL: during SI, RAN2 agreed “In contention-free access, the A-IoT device directly sends the upper layer data (e.g. device ID) in its very first D2R message after being triggered (i.e. skip contention resolution Msg1/2).” While, no explicit agreement has been made in RAN2 whether the content for the 1st D2R message in CFRA is the same as that of Msg3 in CBRA. Considering this is the last RAN1 meeting above proposal is made.  

Round 1
FL1 Proposal 3.2.3-3
For Msg1 transmission, the processing time at device side is the same regardless of the use of FEC.
For Msg3 transmission, the processing time at device side is the same regardless of the use of FEC.
For D2R data transmission after random access procedure, when FEC is used, select one option from the following
Option 1: Add extra processing time at device side based on the D2R TBS compared to the case when FEC is not used 
Option 2: Add a fixed extra time at device side regardless of the D2R TBS compared to the case when FEC is not used 
For the 1st D2R data transmission in CFRA, when FEC is used 
If the content of the first D2R message in CFRA is the same as that of Msg3 in CBRA, the processing time at device side is the same as the case when FEC is not used 
Otherwise, same handling of the processing time as that for D2R data transmission after random access procedure.

From FL: Above proposal is made to address the FFS of FEC impact in Proposal 3.2.1-1 for Toffset1 for Msg1, Proposal 3.2.2-1 for Toffset3 for Msg3, and Proposal 3.2.3-1 for Toffset4 for other D2R data transmission after random access (RA). 
Data rate for Msg1 and Msg3

[30]: RAN1 needs to clarify the data rate, bit rate, chip rate for other cases of D2R with TDMA and/or FDMA, as listed in Table 1. Note that data rate is different from bit rate and chip rate, as defined as follows.
Data rate (bps): the number of information bits and CRC (if any) per second before FEC (if any)
Bit rate (bps): the number of bits per second after FEC (if any)
Chip rate (bps): the number of chips per second with , where R is the frequency shift factor
Table 1 configuration for D2R with TDMA/FDMA in [30]

[12]: the same data rate could be achieved by different combination of {Tb, repetition factor, FEC coding rate}, for example, date rate of {Tb = 133.33µs, repetition = 2, FEC = 1/3} and {Tb = 266.67 µs, repetition = 1, FEC = 1/3} are the same. But we have not seen the benefit of supporting this flexibility in Msg1/Msg.3 scheduling. Therefore, propose to male it clear that 
Same Tb, repetition factor and FEC coding rate are applied to all FDMed Msg.3 transmissions in response to a PRDCH for Msg.2 transmission.
Same Tb, repetition factor and FEC coding rate are applied to all FDMed Msg.1 transmissions (if supported) in response to R2D transmission triggering CFRA.

About data rate, in TR 38.769 Table 4.2.2-1, there are two notes for the data rate clarification as shown below:

About bit duration Tb, Tb= 2 × ×, as agreed in AI 9.4.2.
For Cases 4, 5, and 6 of CFRA, the current RAN2 agreement assumes no multiple devices are performing procedures with the given reader. FFS if we can assume or need to support multiple device scenario   
FL suggests focusing on Case 2 of CBRA Msg1 with TDMA and Case 7 Msg3 with FDMA. Case 3 of CBRA Msg1 with TDMA + FDMA will result from the decision made for Case 2.
Clarification is needed regarding the intention of the same data rate. FL views this as applying the same Tb, block repetition number, FEC coding rate, and amble-related parameters to all FDMed and/or TDMed D2R transmissions.

For the Case of CBRA Msg1 with TDMA of X=2, 
[3], [6], [34] proposed the same data rate
[30] proposed RAN1 to down select 
Opt1: support same Msg1 transmission time for 1st and 2nd time domain resource
Opt2: support shorter Msg1 transmission time in the 1st time domain resource than that of 2nd one 
Round 1
FL1 Proposal 3.3-1 
For following agreement, the same data rate means 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, is the same for the FDMed Msg1 transmissions.   
Comments?

Round 2
FL2 Proposal 3.3-1a
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, is the same for the FDMed Msg1 transmissions.

Round2/Round 1
FL1 Proposal 3.3-2 
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, is the same for the TDMed Msg1 transmissions.  


For the Case of Msg3 with FDMA, 

[1] proposed to send an LS to RAN2 to clarify if Msg3 payload is the same for all devices and observed following 
[5]: In one paging round, Msg3 TBS can be known by device. Thus, there is no need to indicate TBS.
[18] proposed RAN1 needs to identify whether the Msg3 payload of devices is the same or not, and try to align the Msg3 transmission of devices. 
[20] proposed to keep the TBS carried in corresponding Msg2 to be the same for FDMed Msg3 transmissions
[24] proposed if the TBS of Msg.3 is variable, the different data rates for FDMA based multiple Msg.3 transmissions are supported.
About the TBS for Msg3, based on the section 5.7.2 of TS 23.369 V0.3.0, copy relevant text below

Considering this is the last RAN1 meeting, for the case that Msg3 TBS is the same for all devices participating in the inventory, companies views on the data rate for the FDMed Msg3 transmissions are summarized as below:
Alt.1: Support same data rate only: [2], [5], [9], [10], [14], [20], [21], [34]
Cannot improve the spectrum efficiency and complexity at reader side
Even one device can use higher data rate to reduce its Msg3 transmission time, Reader still has to wait until all the FDMed devices have finished their Msg3 transmission. And what more, Reader may need to know the channel condition of devices to adjust the data rate. 
Alt.2: Support same and different data rate(s): [1?], [3], [6], [23], [30], [35]
Offers improved spectral efficiency and reduced random access latency.
Round2/Round 1
FL1 Proposal 3.3-3 
For the case that the payload size for Msg3 transmissions is the same for all devices participating in the inventory, down-select one option from the following:  
Option 1: 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, is the same for the FDMed Msg3 transmissions 
Option 2: 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, can be different for the FDMed Msg3 transmissions 

Please also indicate your preference.

Timing relations 
Timing for R2D response to D2R
Value(s) for TD2R_min
Option 1: Fixed to one small value, i.e., =[10]us: [1], [5], [10]
[1]: A large enough switching time does not seem to be very necessary since A-IoT devices work with an envelope detector architecture. No switching between frequency bands is required to go from transmit to reception mode
[5], [10]: 10us
Option 2: derived based on D2R chip duration, i.e, =c×, where c=[3] or [10]: [3], [31], [33], [34]
[3]:, where c = [10].
[30]: , where  is the chip duration and for Msg1/Msg3 with FDMA, the chip duration  of the smallest frequency shift for the FDMA is used to derive .  
Option 3: request RAN4 to define the value for 
[22]: Given that minimum timing requirements (e.g., TD2R_min and any additional parameters to be agreed in this meeting) involves RF turn-around time, and base band modulation/demodulation time, which is highly dependent on implementation and within RAN4’s expertise, as well as considering that this is the last RAN1 meeting, it might be appropriate to request RAN4 to define these parameters.
Round 1
FL1 Proposal 4.1 
Select one option from the following for TD2R_min:
Option 1: TD2R_min is predefined in the spec as one fixed value of [10]us  
Option 2: TD2R_min is derived as TD2R_min= c  ,  is the D2R chip duration indicated in the R2D transmission scheduling the D2R transmission  
FFS c=[3] or [10] 
Option 3: Up to RAN4 to define the value for TD2R_min.  

Round 2
FL2 Proposal 4.1a
Select one option from the following for TD2R_min:
Option 1: TD2R_min is predefined in the spec as one fixed value of 10us  
Option 2: TD2R_min is derived as TD2R_min= c  ,  is the D2R chip duration indicated in the R2D transmission scheduling the D2R transmission  
Down-select between c=3 and 10 
Option 3: Up to RAN4 to define the value for TD2R_min. 

The necessity and complexity to define the “Msg2 monitoring window” including the both the starting time e.g., TMsg2_start and TMsg2_end/TD2R_max for Msg2 monitoring from device perspective, companies’ views are summarized in the following:
No: It is not necessary  
[2], [3], [5], [6], [7], [10], [12], [20] 
Power saving is not considered/critical for device Type 1 in Rel. 19
The basic assumption of A-IoT design is the device always monitors R2D, when it is not otherwise occupied by e.g. R2D reception or processing. 
The start indicator part (SIP) in the preamble of every PRDCH transmission triggers the device to detect the Msg2 at each PRDCH transmission.
No impact on device behavior even without defining the monitoring window
E.g., If the device does not receive the Msg2 transmission by the next paging message, the device considers the A-IoT Msg1 transmission failed.

Yes: It is beneficial for device power saving or to determine a random access failure from physical layer if the Msg2 is not received within the Msg2 monitoring window.
[8], [9?], [16], [19], [22], [25], [28], [29], [30], [31], [32], [33], [34], [36]

Other way instead of specifying a Msg2 monitoring window: [1]
[1] proposed instead of specifying a Msg2 monitoring window, a time monitoring window for monitoring L1 control information preceding Msg2 transmissions may be specified and the L1 control information can contain the individual start times (or offsets) for Msg2 transmissions corresponding to each Msg1.

Details on Msg2 monitoring
[8]: If the number of configured time domain resources is small, or the interval between the first time domain resource and the MSG2 monitoring starting occasion is not long, the common starting occasion for MSG2 monitoring shall be supported, otherwise the separate starting occasion is more appropriate.
[9]: A larger TD2R_max for FDMA than TD2R_max for basic no multiplexing case can be considered to solve the issue of Msg2 falling out of [TD2R_min, TD2R_max] due to SFO.
[19], [29], [36]: Support association between the selected Msg1 time and frequency resources to its Msg2 time resources. 
[29] also proposed a Msg2 transmission order can be provided from initial PRDCH for Msg2 transmission.
[36] also proposed to consider Early Indication (EI) field indicating whether PRDCH(s) contains Msg2 corresponding to each access occasion configured for Msg1.
[22]: 
For Msg2 corresponding to one or more Msg1, a device starts monitoring the PRDCH providing Msg2 TD2R_min after the end of X time domain resources for Msg1 transmission. The monitoring window can be Δ = TD2R_max - TD2R_min such that the start of PRDCH falls within the Δ time interval. If Msg2 is not received within the Δ time interval, the device preceives that the current inventory round is unsuccessful and restarts the inventory round, e.g., retransmit Msg1 in a later round.as shown in Fig.9

Fig 9 of [22]

[33]:
TD2R_min and TD2R_max are defined based on multiple of chip length for D2R transmission when R value is 1:
TD2R_min= D* chip_lengthD2R_R=1 
TD2R_max= E* chip_lengthD2R_R=1 
Reference point for both TD2R_min and TD2R_max are defined as follows:
Starts from Toffset2 when X=2
Starts from the end of Msg1 transmission when X=1
About the reference time on the starting time for Msg2 monitoring /window, it is the end of the last of X time domain resource(s) determined for Msg1 transmission(s): [6], [22], [28], [31], [32], [33], [36]
Power saving is not crucial for Rel-19 A-IoT, which only considers device 1 without sleep function. Following direction 1, where the Reader doesn't inform the device about its availability, a simple and consistent approach is to have device 1 monitor Msg2 following the Tx-to-Rx switching time after transmitting Msg1. No critical issue is identified by the following in the TS 38.291 [37].

In addition, it should be noted that failure detection is addressed in Section 5.5 of TS 38.391 [38]. FL suggests lowering the priority of this topic in RAN1.
 
Other timing relation aspects
For the time interval between two different consecutive R2D transmissions to the same A-IoT device, TR 38.769 captures TR2D_R2D_min as the minimum time between two different consecutive R2D transmissions to the same A-IoT device.
[5], [7] proposed RAN1 does not define TR2D_R2D_min, TD2R_D2R_min
[22], [25], [32], [34] proposed to define TR2D_R2D_min, considering the following
[22]: There is a need to define TR2D_R2D_min considering that there should be a sufficient processing time provisioned for a device to process back-to-back R2D transmissions such as a PRDCH providing a paging message followed by another PRDCH providing a triggering message, or a PRDCH providing a command followed by another PRDCH providing a command, etc. There is no need to define TR2D_R2D_max, given that R2D transmission can occur at any time.    
[25]: The minimum time interval between R2D transmissions TR2D_R2D_min can be considered regardless of whether one or more of the R2D transmissions targets the device or not. 
[34]: Beneficial to define TR2D_R2D_min to avoid the device to continuous reception for power saving
From FL: Currently, the procedure or interaction between the AIoT paging message and the new R2D message is not clear and RAN2 is still discussing it. Since this is the last RAN1 meeting, we can keep the parameter open without making any agreement on TR2D_R2D_min or we can try to make agreement based on the if condition.   
Round 1
FL1 Proposal 4.2
Option 1: Keep TR2D_R2D_min open without any agreement. 
Option 2: TR2D_R2D_min is defined such that a device is not require to monitor a R2D transmission earlier than TR2D_R2D_min after the end of a previous R2D transmission to the device, if the case that two different consecutive R2D transmissions to the same A-IoT device exits. 
Please indicate your preference on handling the TR2D_R2D_min.

Scheduling information
For R2D reception  
The agreements related to ID and Message Type made by RAN2#129 can be found in Annex C. 
Overview for R2D reception
Nothing need to be considered in R2D L1 scheduling information.
[5], [9], [10], [14], [20]

Following needs to be indicated in R2D control information  
ID associated with device(s) intended for the reception of R2D or AS ID [4], [8], [12], [22],[23], [25],[30], [31], [35] 
From FL: Based on RAN2 agreements, the Paging ID, Transaction ID, Echoed Random ID, Assigned AS ID and “message type” of R2D Message Type is/are included in the higher layer data and captured in TS 38.391 [38] section 6 of Protocol Data Units, formats and parameters.
TBS: either explicitly or implicitly based on message type indication for messages having a fixed size. [22] [31] 
Reserved bits for forward compatibility [4]

About explicit TBS indication, AI 9.4.3 will discuss it. 
[4]: Compare the overhead of TBS indication vs. postamble size to decide on the method indicating end of PRDCH transmission.
[10], [12]: As RAN2 has already agreed that one field is included in the MAC header for SDU length indication, there is no needed to support R2D post-amble or even physical layer control information for R2D TBS indication, the device can be aware of the end of PRDCH by decoding the MAC header in advance.
[12] proposed to send an LS to RAN2 to inform them that RAN1 relies on the MAC header to indicates the end of R2D transmission when MAC PDU includes one MAC SDU, or multiple MAC PDU if supported by RAN2.
[14]: For scheduling R2D transmission, any scheduling information related to resource allocation that needs to be signaled is indicated by higher-layer signaling via the PRDCH indicated by higher-layer signaling 
[30]: R2D L1 control indicate TBS

PRDCH chip duration
Option 1: Same as clock-acquisition part of the R2D preamble [2], [5], [6], [8], [10], [22], [23], [27], [34] 
No clear motivation and rather it increases device complexity for switching the chip duration and impact on the chip synchronization accuracy.
Option 2: indicated by R2D L1 control 
[30]: If not configured, the R2D data payload assumes the same parameters as R2D L1 control
Option 3: The clock acquisition signal can be transmitted in two parts, the first part contains smaller M value indicating M value used for the L1 control signaling while the second part uses larger M value indicating the M value used in data. 
[4]
Round 1
FL1 Proposal 5.1-1
The R2D chip duration for a PRDCH is the same as the clock-acquisition part of the R2D time acquisition signal immediately preceding the PRDCH.

In case there is any explicit scheduling information agreed for R2D reception, 
On R2D L1 control with separate CRC and higher layer control with Joint CRC  
[4], [8], [15], [22], [23], [30], [31] support R2D L1 control with separate CRC  
[4], [15], [22], [30] discussed the main motivation is for power saving, by allowing a device to early determine whether to continue or terminate R2D reception based on control information. 
[8] discussed another motivation is for different reliability between the R2D control and data.
[7] support higher layer control with Joint CRC  
Power saving by early identification is Not essential for Rel-19 device 1
Prolonged transmission due to additional CRC
Increased device complexity for processing two CRCs and potential additional behaviour depending on two CRC check
Increased specification efforts, potentially including the introduction of multiple 'DCI'.
[15]: Down-select between fixed format L1 control multiplexed with PRDCH data, or a single PRDCH transmission with higher-layer control and data multiplexed together
In addition, [27] proposed to attach a separate CRC to the first part of the PRDCH. It seems imply a separate CRC is attached to the “MAC header”.
To avoid blind detection or introduction of multiple 'DCI', following options proposed for identification of the R2D L1 control information with separate CRC
[15], [22]: The L1 R2D control information should have a fixed size and attached with a separate CRC. 
The R2D control information carrying “ID” of Paging ID, Transaction ID, Echoed Random ID, Assigned AS ID and “message type” of R2D Message Type was agreed to be included in the higher layer data, see TS 38.391 [38] figure 4.2-1 in section 4.2 and section 6 of Protocol Data Units, formats and parameters. 
We can revisit this if explicit scheduling information is agreed upon for R2D reception.

For D2R transmission   
Joint or Separate indication of FEC and block level repetition
Alt.1: Separate indication of FEC and number of repetitions  
[1], [5], [6], [7], [9], [10], [20], [31], [34]: small specification effort and full indication flexibility.
[5], [6], [10], [20]: 1 bit is used to indicate that whether FEC is applied for the D2R transmission and 1 bit is used to indicate the number (1 or 2) of block-level repetitions for D2R. 
Alt 2: joint indication of FEC and number of repetitions [2], [3], [4], [8], [11], [18], [24], [30] 
[2] Support a joint encoding of the indicators for FEC and number of repetitions Rblock to generate the overall rate 1 (Rblock=1, no FEC), overall rate 1/2 (Rblock=1, Rcode=1/2), overall rate 1/3 (Rblock=1, Rcode=1/3), and overall rate 1/6 (Rblock=2, Rcode=1/3).
[3] Code rates and repetitions combinations candidates {1, 1}, {1/2, 1}, {1/3, 1}, {1/3, 2} and candidates {1, 1}, {1/3, 1}, {1/3, 2}, {1/3, 4} are proposed, which require 2 bits for indication.
[8]: 3-bit by following table 
[18] proposed to adopt table 2 for joint indication
[30]: 
Alt1: 2bits for {no FEC, FEC1/2, FEC1/3, FEC1/3+rep2}
Alt2: 2bits for {no FEC, FEC 1/3, FEC 1/3+rep2, FEC 1/3+rep4}
Alt3: 2bits for {no FEC, FEC 1/3, FEC 1/3+rep2, reserved}
Round2/Round 1
FL1 Proposal 5.2-1
Select one option from the following for indicating the the FEC and the number of block-level repetition(s) for PDRCH transmission in the corresponding PRDCH:
Option 1: Separate indication of FEC and number of block-level repetitions
If FEC coding rate supports 1/3 only, 1-bit indication is used; If FEC coding rate supports 1/3 and 1/2, 2-bit indication is used
If the number of values for block-level repetition number is 2, 1-bit indication is used; if the number of values for block-level repetition number is more than 2, 2-bit indication is used 
  
Option 2: 2-bit joint indication of FEC and number of block-level repetitions, down-select one from the following
Alt1: 2bits for (no FEC, Rblock=1), (Rcode=1/3, Rblock=1),  (Rcode=1/3, Rblock=2), (reserved) 
Alt2: 2bits for (no FEC, Rblock=1), (Rcode=1/3, Rblock=1), (Rcode=1/3, Rblock=2), (Rcode=1/3, Rblock=4) 
Alt3: 2bits for (no FEC, Rblock=1), (Rcode=1/2, Rblock=1), (Rcode=1/3, Rblock=1), (Rcode=1/3, Rblock=2) 
From FL: The main motivation for joint indication is signalling overhead reduction, hence 2-bit joint indication proposed here. 

About the TBS indication, no companies against to confirm the working assumption.  
Round 1
FL1 Proposal 5.2-2
Confirm the following working assumption  
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

Round 2
FL2 Proposal 5.2-2a
Confirm the working assumption with following updates   
Working assumption
For indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size after random access:
7 bits for byte-level D2R payload size indication
Regarding the TBS of Msg1 and Msg3 in CBRA, and 1st D2R Message in CFRA
From RAN1 point of view, the allowed value set is {1, 2, 3, …, 124, 125} byte, i.e., all integer numbers from 1 to 125 and the unit is byte
It is up to RAN2 to decide the actual value set and how device knows the actual size during random access procedure

Scheduling information for Msg1
[1] proposed to support the following fields 

[5] proposed to support the following fields

[30] The R2D control to schedule Msg1/Msg3/D2R data have multiple components, as summarized in Table 3.
Table 3 R2D control for PDRCH [30]

Scheduling information for Msg3
[1] proposed to support the following fields  

[5] proposed to support the following fields

Scheduling information for D2R data 
[1] proposed to support the following fields 

[3] To sum up, Table 2 can be considered for D2R scheduling:
Table 2: D2R information field in R2D control information [3]

[5] proposed to support the following fields


Omit some scheduling information for the subsequent Msg3 and/or D2R data transmission 
Frequency domain resource for Msg3 transmission
Companies’ views for above FFS: support option 1 as a default if PRDCH does not provide the indication or based on a rule, are following 
Support option 1 to reduce R2D signaling overhead.
[3], [6], [15], [18], [19], [20], [23], [25], [29], [32]: support option 1 as a default if PRDCH does not provide the indication
[3]: In Option 1, the same FEC code rate and number of block repetitions employed for Msg1 can also be applied for Msg3 transmissions.
[3]: whether and how MAC payload indicate which of the two options to be used can be left to RAN2.
[4], [34]: support option 1 as a default when X=1 (based on a rule) 

[5]: support option 1 as a default if PRDCH does not provide the indication or based on a rule?
Device already knows Y pairs of {R, T_chip} that are used for Msg1.
In separate Msg2 case: this Msg2 only needs to schedule 1 device, so a codepoint way can be used, i.e., use log2(Y) bits to indicate which one pair of {R, T_chip} among the ones for Msg1 is reused for Msg3.
In common Msg2 case: a bitmap way can be considered, which only needs Y bit, where there are N “1”s in the bitmap, and “1” means this resource is to be used for Msg3, “0” means this resource is not to be used for Msg3, and N is the number of scheduled devices in Msg2. 
[9]: The frequency domain resource for Msg3 can be determined based on successfully reception state of Msg1 and predefined frequency resources orders. For example, Msg2 can provide a bitmap where each bit corresponds to reception state of Msg1 in one frequency resource.

Do not support option 1: [1], [7], [10], [13], [22], [28] 
Inefficient resource usage 
Complex the operation as it involves a decision making on whether an explicit indication is provided or not
Additional signaling is needed to inform which option, option 1 or 2 is used for Msg3 transmission 

Other scheduling information  
[1]: D2R scheduling after Msg3 can also support an option of an additional 1 bit indicator to indicate that the scheduling information not specifically configured can follow the same values as that used for Msg3. 
[3]: if the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device, the same FEC code rate and number of block repetitions employed for Msg1 can also be applied for Msg3 transmissions.
[5]: in one paging round, Msg1, Msg3, and other D2R messages should have similar coverage requirement, so Msg3, and other D2R messages can reuse following scheduling information of Msg1 transmission:
Preamble length
Midamble details
Apply FEC or not
Block repetition
{R, }
[9]: If no Msg3 scheduling information is carried by Msg2, Msg3 use the same data rate and chip rate as Msg1.

From FL: check the progress on the signalling design in AI 942 for D2R chip duration and small frequency shift and in AI 943 for amble related information. Then update the following list of D2R scheduling information with the bit length for Msg1, Msg3 and D2R data transmission.   
For Msg1, following D2R scheduling information needs to be indicated in the R2D transmission triggering the contention based random access 
The number of time domain resources for transmission: 1 bit
Amble length 
Amble related information, including the interval in bits for D2R amble insertion, if applicable 
D2R chip duration  
Small frequency shift(s) 
the block repetition number
the channel coding information

For Msg3 or the first D2R message in CFRA, following D2R scheduling information needs to be indicated in the R2D transmission for Msg2 or for triggering the CFRA, assuming the payload size for Msg3 and the first D2R message is the same for all devices participating in the inventory
Amble length 
Amble related information, including the interval in bits for D2R amble insertion, if applicable 
D2R chip duration  
Small frequency shift(s) 
the block repetition number
the channel coding information

For D2R data after random access, following D2R scheduling information needs to be indicated in the R2D transmission scheduling the D2R data 
TBS indication: 7-bit byte level indication 
Amble length 
Amble related information, including the interval in bits for D2R amble insertion, if applicable 
D2R chip duration  
Small frequency shift 
the block repetition number
the channel coding information
   
Proposals for offline discussions
Proposals for May. 20th Offline

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.

FL1 Proposal 3.2.1-1b
Select one option from the following 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.

Option 1-1: Toffset1 is predefined in the spec as one fixed value of 30us 
The fixed value is applicable regardless of the use of FEC. 

Option 2: Toffset1 is derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission triggering random access  
+t1, where a=4, b=20 and t1≥0   
Determine t1 within this meeting considering at least the FEC impact, if applicable

Option 3: Toffset1 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values. 

, the potential range is (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, 27.8, 22,24, 20.8, 13.8, 11.12)us  

FL1 Proposal 3.2.1-2b: Select one option from the following for Toffset2:
Option 1: , where
 is the duration of the 1st Msg1 time domain resource
=0.25 and =1.25

Option 2: Toffset2 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values 
The predefined valuesare {60, 90, 120, 180, 240, 300, 360, 420}us




 and by simplify it, , where te is 10% device clock error as defined in RAN4, then  = 0.222 + 1.222 , 
=1/4=0.25, =5/4=1.25

FL2 Proposal 3.2.2-1a
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.
Toffset3 has the same design [and value set] of Toffset1

FL2 Proposal 3.2.3-1a
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 , from the device perspective. 
Select one option from the following for Toffset4 
Option 1: Toffset4 is predefined in the spec as fixed value(s).   
Toffset4 = 30us when FEC is not used
Toffset4 = 1500us when FEC is used 
Option 2: Derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission  
+t3, where a=4, b=20 and t3≥0   
Determine t3 within this meeting considering at least the FEC impact, if applicable

Option 3: Toffset4 is indicated explicitly in the R2D transmission from a set of predefined values 
The predefined values are {30, 40, 50, 60}us when FEC is not used and {1500, 2000, 2500, 3000}us when FEC is used
If the end of the R2D transmission is defined as before the start of padding, the length of padding is additionally added to Toffset4.

FL2 Proposal 5.2-2a
Confirm the working assumption with following updates   
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
Regarding the TBS of Msg1 and Msg3 in CBRA, and 1st D2R Message in CFRA
From RAN1 point of view, the allowed value set is {1, 2, 3, …, 124, 125} byte, i.e., all integer numbers from 1 to 125 and the unit is byte
It is up to RAN2 to decide the actual value set and how device knows the actual size during random access procedure

TS 23.369 states that ‘The following lengths are supported for the Identification Information in an AIoT Device Permanent Identifier: 96 bits, and 128 bits. In addition to this, there can additional bits configured from the higher layer. 

FL2 Proposal 4.1a
Select one option from the following for TD2R_min:
Option 1: TD2R_min is predefined in the spec as one fixed value of 10us  
Option 2: TD2R_min is derived as TD2R_min= c  ,  is the D2R chip duration indicated in the R2D transmission scheduling the D2R transmission  
Down-select between c=3 and 10 
Option 3: Up to RAN4 to define the value for TD2R_min. 

Agreements achieved in RAN1#121 meeting
TBU

3GPP TSG-RAN WG1 Meeting #121	         R1-2503364  
St. Julian’s, Malta 19 – 23 May, 2025
Agenda Item:	9.4.4
Title:	FL summary#3 on other aspects for Rel-19 Ambient IoT 
Source:	Moderator (vivo)
Document for:	Discussion, Decision

Conclusion 3.1: 
For CFRA and for a new R2D message other than the paging message for A-IoT device determining Msg1 resources, it is up to RAN2 to decide whether and how to support TDMA of X>1 and/or FDMA of Y>1 time-frequency resources for Msg1 transmissions.    

Round 2
FL2 Proposed conclusion 3.1a
For CFRA, 
RAN1 assumes X=1 and Y=1 in the paging message for A-IoT device determining Msg1 resources. 
It is up to RAN2 to decide signaling details for the case of X=2 and/or Y>1 time-frequency resources for Msg1 transmissions if multiple devices are scheduled in CFRA.


FL2 Proposed conclusion 3.1b
For a new R2D message other than the paging message for A-IoT device determining Msg1 resources, down-select from the following:
Alt.1: RAN1 does not see the need to change X and Y value by the new R2D message
Alt.2: it is up to RAN2 to decide whether and how to change X and Y value by the new R2D message

Starting time of time domain resource for Msg1 and Msg3/D2R

For Msg1 transmission  

For X=1 or X=2, the starting time for the first Msg1 time domain resource from the device perspective 
Companies’ views on the “FFS Toffset1 is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Option 1: Predefined in the spec with fixed value(s): [5], [6], [9], [13], [18?], [23], [31]
[5], [23] Predefined as one fixed value
[5]: i.e., 30us; 
[6] Up to RAN4 to determine the exact value
[9], [13] Predefined and account for the worst case, up to 0.26ms is needed 
[4], [31] Different values of Toffset1 are predefined for the Msg.1 with FEC and without FEC.  
Option 2: Predefined equation to derive the , where the equation is based on the  and  for the scheduled D2R transmission [1], [3], [10], [16], [20], [30], [32], [33], [36]
[1], [3], [10], [30]: 
[3], [10], [30] proposed a=[4]; 
[3], [10], [20] proposed b=[20] and [30] proposed b=[10]  
[3]: t equals to [4] us for FEC disabled and [12] us for FEC enabled.
[10]: t equals to 0 for FEC disabled; [0.5]ms for FEC enabled
[30]: t equals to 0 if CRC is not attached to at the end or CRC can be pre-calculated; Otherwise,  with sampling rate 
[20]: MAX(CAP duration, 20TD2R,chip)
[16], [36]: predefined in the spec in terms of a number of chips (i.e., based on the M value of the triggering R2D transmission)
In addition, [10], [30], [33] proposed to clarify for FDMA of Msg1 case, the D2R chip length should be “a reference D2R chip length” or “the D2R chip length corresponding to R=1” or “the D2R chip length corresponding to the smallest R among the FDMA of Msg1s” to align the starting time for Msg1 transmission
Option 3: Indicated explicitly by the R2D transmission triggering random access [2], [7], [8], [12], [15], [21], [22], [24], [28], [34]
Predefine a list of candidate values (absolute time or time unit level indication) and the reader explicitly indicates one of the value
[7]: Following options can be considered to determine the value of Toffset1
Option 1: Define Toffset1 as a number of slots with the Candidate values: {1, 2, 3, 4}.
Option 2: Define Toffset1 as an absolute time expressed in tenths of one millisecond with the  candidate values: {0.2ms, 0.4ms, 0.6ms, 0.8ms}.
Option 3: Define Toffset1 as a number of equivalent D2R symbols with the Candidate values: {3, 6, 9, 12}.
 About the impact of FEC impact for Msg1 transmission, 
[3]: additional time margin t=[4]us for FEC disabled and [12]us for FEC enabled
[5]: FEC has no impact here. Because before receiving paging, device can pre-generate the random ID and pre-calculate the CRC and performs coding. Thus, when FEC is used, the processing time can still be the same as no FEC case, i.e., 30us.
[30]: For Msg1/Msg3/D2R feedback, apply TBS restriction of [up to 12bytes] or use precalculated CRC, .
About the impact of “the end of R2D transmission triggering random access” ,
[5], [10]: If the end for timeline determination refers to the “start of padding”, additional time needs to be added; if the end for timeline determination refers to the “end of padding”, no additional time needs to be added.
[30]:  is counted from the end of the last bit of PRDCH (before the start of the padding) till the start of D2R preamble of corresponding D2R transmission.  
Round 1
FL1 Proposal 3.2.1-1
Select one option from the following 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.
Option 1: Toffset1 is predefined in the spec as one fixed value of [30]us  
FFS whether/how additional time needs to be added when FEC is used
Note: If the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1. 
Option 2: Toffset1 is derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission triggering random access  
+t1, where a=[4], b=[20] and t1≥0   
FFS t1 considering at least the FEC impact, if applicable, and/or R2D padding impact if the end of the R2D transmission is defined as before the start of padding
Option 3: Toffset1 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values 
FFS the set of predefined values     

From FL: 
For option2, some companies suggested clarifying the D2R chip duration for FDMA. My thinking is we can use the same interpretation as that for small frequency shifts in FDMA once agreed in AI 942.
About the FEC impact for Msg1, Msg3 and other D2R data transmissions, separate proposal is made in FL1 Proposal 3.2.3-3. 

Round 2
Following is agreed on Monday online
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.

Based on the online discussions, following questions are asked.
FL2 Question 3.2.1-1a
For CBRA, what is your preferred way on determination of the smallest value for Toffset1?
Option 1: RAN1 defines the smallest value is 30us for Toffset1 and RAN4 can revisit it if they have concern.
Option 2: Up to RAN4 to decide the smallest value for Toffset1. 


FL2 Question 3.2.1-1b
For CBRA, in addition to the smallest value of Toffset1, are there any additional value(s) needed?
If Yes, what is/are the additional value(s) and how to use it?


For X=2, the starting time for the second Msg1 time domain resource from the device perspective
Most companies proposed to confirm the working assumption. In addition, companies’ views on the “FFS Toffset2 is predefined in the spec or derived by a rule or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Toffset2 is predefined in the spec: [14], [34?]
[14]: A set of Toffset2 values corresponds to the data rate are specified for the device. The appropriate value is selected for the second Msg1 transmission according to the indicated Msg1 data rate.
Toffset2 is derived by a rule based on the duration of the 1st Msg1 time domain resource and the gap between the two time domain resource considering the SFO impact: [1], [3], [6], [7], [10], [12], [13], [16?], [18], [23], [30], [31], [36] 
[6], [7], [12], [13], [16?], [20], [28], [30], [31], [36]: The value of Toffset2 can be implicitly derived as+Tgap, where Tgap = (Toffset1+TMsg1)×SFO×2, Tmsg1 is the duration of Msg.1 transmission length determined by 16-bit payload, 6-bit CRC, D2R chip length, FEC, repetition if applied and amble related parameter(s).
From FL: from above, assuming SFO=10%, Toffset2 = Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO  (equation 1), the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) (equation 2), combine equation 1 and equation 2, the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) = (Toffset1 + Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO) ×(1-SFO)  = 1.08 ×(Toffset1 + Tmsg1), which overlaps with the end of the first time domain resource with a slow clock given by (1+SFO)×(Toffset1 + Tmsg1) = 1.1 ×(Toffset1 + Tmsg1)
 
[2], [3], [10], [18]: Toffset2 should be set to prevent the second time domain resource for Msg1 transmission from device with fast clock from colliding with the first time domain resource for Msg1 transmission from device with slow clock at the reader side. Hence,  and by simplify it, , where te is 10% device clock error as defined in RAN4 
Toffset2 is indicated explicitly by the R2D transmission triggering random access: [2], [4], [5], [8], [9], [15], [22], [24], [32], [34]
[5]: Toffset2 is indicated explicitly, and the value set is {60, 90, 120, 180, 240, 300, 360, 420}us
[9]: 9 or 10 bits based on number of bits after FEC (if FEC is applied) and repetition (if repetition is applied) can be used for Toffset2 indication since the time duration of Toffset2 is likely to be less than 100ms.  
Round 3
For Toffset1
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.

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

About the impacts from the R2D padding and FEC, it can be discussed later. Let’s first focus only on the R2D chip length, D2R chip length or D2R bit length. After the predefined values are defined, then  
For R2D padding, if the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1. 
For FEC, if it is used, additional either fixed time or TBS-based time may need to be added.  

, the potential range is (2666.6, 1333.4, 666.6, 333.4, 166.6, 133.32, 83.4, 44.44, 41.6, 30, 22.24, 20.8, 13.8)us

It is unclear how the weight factors are selected for the RFID; it is also unclear whether 30us is sufficient for all R2D and D2R chip duration. 

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.


FL3 Question 3.2.1-1c
If FEC is not used, without considering the R2D padding impact,
If D2R chip length is is {0.69, 1.04, 2.08, 4.17}us, what is the predefined value set?
If D2R chip length is is {8.33, 16.67, 33.33}us, what is the predefined value set?
If D2R chip length is {66.67, 133.33}us, what is the predefined value set?
For FDMA case, the D2R chip length is a reference D2R chip length  corresponding to R = 1, the actual D2R chip duration  = /R.
Note: if the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1 


For Toffse3
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.

FL3 Question 3.2.1-1d
If FEC is not used, without considering the R2D padding impact, whether the same or different value set as for Toffset 1 is used for Toffset3?
If your answer is No, what are the value set for Toffset3?


For Toffset4
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. 
FL3 Question 3.2.1-1e
If FEC is not used, without considering the R2D padding impact, whether the same or different value set as for Toffset 1 is used for Toffset3?
If your answer is No, what are the value set for Toffset4?

FEC impacts
FL3 Proposal 3.2.3-3a
For Msg1 transmission, the processing time at device side is the same regardless of the use of FEC.

FL3 Proposal 3.2.3-3b
For Msg3 transmission, the processing time at device side is 
Opt.1: the same regardless of the use of FEC.
Opt.2: additional time like [70]us is added

FL3 Proposal 3.2.3-3c
For D2R data transmission except for Msg1, Msg3 and the 1st D2R transmission for CFRA, when FEC is used, select one option from the following
Option 1: Add extra processing time TFEC at device side based on the D2R TBS compared to the case when FEC is not used, e.g.,  
TFEC = with reference sampling rate , e.g., 1.92MHz    

Option 2: Add a fixed extra time TFEC at device side regardless of the D2R TBS compared to the case when FEC is not used
The fixed time TFEC is down-selected among [500, 600, 700, 800]us 

Option 3: Add extra processing time TFEC at device side based on the D2R TBS compared to the case when FEC is not used
TFEC = [x]us for TBS<=16 bytes
TFEC = [y]us for 16 bytes 

3GPP TSG-RAN WG1 Meeting #121         						 	R1-2503518
St Julian's, Malta, 19 - 23 May, 2025
Agenda Item:     9.4.4
Source:	Spreadtrum, UNISOC
Title:	Discussion on other aspects for Ambient IoT
Document for:	Discussion and decision

Conclusion
In this contribution, we discuss on frame structure and timing aspects for A-IoT. The following observations and proposals are provided:
Observations:
Observation 1: There are three possible multiple access cases (i.e., TDMA only, FDMA only and TDMA+FDMA) for a certain Msg1 transmission. If all three cases are supported, a unified resource allocation scheme is beneficial for simplifying design.
Observation 2: Device can randomly select one of the time and frequency domain resource among multiple resources for the Msg1.

Proposals:
Proposal 1: Support predefining Toffset1 in the spec and up to RAN4 to determine the exact value.
Proposal 2: Confirm the working assumption to determine the starting time for the second Msg1 time domain resource.
Toffset2 is derived by a rule, i.e., the length of first Msg1 time domain resource plus the gap between these two time domain resource considering SFO.
Proposal 3: For CBRA, always support the same D2R data rate for Msg1 transmission.
Proposal 4: Support Case 3 that the PRDCH for Msg2 transmission and the corresponding Msg3 are sent one by one, e.g., Msg2-Msg3-Msg2-Msg3. 
Proposal 5: The starting time of Msg3 should meet the processing time requirement after the end of the corresponding Msg2, while the processing time requirement can be discussed in RAN4.
Proposal 6: Support option 1 as a default if the corresponding PRDCH does not provide the frequency domain resource for Msg3 transmission. 
Proposal 7: Support different D2R data rate for FDMed Msg3 in response to a PRDCH for Msg2 transmission.
Proposal 8: For the number of Msg1 responses in a PRDCH for Msg2, support following:
For case 1, the number of the Msg1 responses that can be carried within a PRDCH for Msg2 should be Xmax*Ymax.
For case 3, the number of the Msg1 responses that can be carried within a PRDCH for Msg2 should be 1.

Proposal 9: It is unnecessary to define a Msg2 monitoring window.
Proposal 10: Don’t support early identification/termination for R2D reception for device 1.
Proposal 11: The R2D chip duration for a PRDCH is the same as the clock-acquisition part of the R2D time acquisition signal immediately preceding the PRDCH.
Proposal 12: Conform the working assumption that 7 bits for byte-level D2R payload size indication is supported.
Proposal 13: 1 bit is used to indicate that whether FEC is applied for the D2R transmission.
Proposal 14: 1bit is used to indicate the number of block-level repetitions for D2R.

3GPP TSG RAN WG1 #121		R1-2503569 
St Julian’s, Malta, May 19th – 23th, 2025 
Agenda item:	9.4.4
Source:	Samsung
Title:	Views on aspects including multiplexing/multiple access, scheduling information, and timing relationships
Document for:	Discussion and decision
1	

Conclusion
In the previous sections we made the following observation:
Observation 1	Providing R2D control information for PRDCH reception via L1 control information has an advantage of early detecting whether the transmission is addressed to the device or not.
Observation 2	Having different chip lengths for R2D control and R2D data has no clear motivation as well as it will increase device complexity while the chip synchronization accuracy will be impacted.
Observation 3	Indicating a time interval between the scheduling PRDCH and the scheduled PDRCH using the shortest chip length is the most efficient.
Observation 4	It is highly likely that there is a mismatch between the current buffered data size at a device and the indicated payload size for PDRCH transmission.
Observation 5	It has been identified that there is a case where an R2D transmission immediately follows a preceding R2D transmission, i.e., R2D paging and R2D triggering messages.
Observation 6	Given that minimum timing requirements (e.g., TD2R_min and any additional parameters to be agreed in this meeting) involves RF turn-around time, and base band modulation/demodulation time, which is highly dependent on implementation and within RAN4’s expertise, as well as considering that this is the last RAN1 meeting, it might be appropriate to request RAN4 to define these parameters.
Observation 7	Given the required specification effort and flexibility, it is preferable to indicate Toffset1 in the R2D message rather than predefining it to a single fixed value.
Observation 8	Toffset1 can be applied to all the random access rounds triggered by one or more triggering messages in a given paging session, and it doesn’t need to be repeatedly indicated in each triggering message.
Observation 9	The length of time slot Toffset2 depends on various factors such as scheduled transmission parameters for Msg1 as well as guard time required between slots for a given specific situation.
Observation 10	No specification work is needed to support Solution 1 for proximity determination.

Based on the discussion in the previous sections we propose the following:
Proposal 1	The following R2D control information for PRDCH reception is indicated in the corresponding PRDCH
	ID associated with device(s) intended for the reception of R2D
	TBS/payload related information, either explicitly or implicitly based on message type indication for messages having a fixed size.
Proposal 2	Provide R2D control information for PRDCH reception via L1 control information in the corresponding PRDCH, wherein the L1 control information is attached with separate CRC-6.
Proposal 3	The end of PRDCH is determined by a device based on TBS/payload related information provided in the L1 R2D control information.
Proposal 4	The PRDCH chip length is obtained from the preceding R2D preamble signal, i.e., R2D control information does not provide information related to the PRDCH chip length.
Proposal 5	For PDRCH transmission with a fixed and known payload (i.e., TBS-like) size, an explicit indication for the payload size is not provided.
Proposal 6	Confirm the 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. The 7 bits indicates payload size of 1 to 128 bytes.
Proposal 7	The time unit for indicating the time interval between a R2D transmission and the corresponding D2R transmission is the minimum chip length supported for R2D, which corresponds to M=24.
Proposal 8	If the available data size at a device for D2R transmission is smaller than the payload size (i.e., TBS-like) indicated by the reader, the actual transmitted payload size is indicated in the D2R control information.
Proposal 9	TR2D_R2D_min is defined such that a device is not require to monitor a R2D transmission earlier than TR2D_R2D_min after the end of a previous R2D transmission to the device.
Proposal 10	For TR2D, down-select from the following two options:
	Option 1:  TR2D is always indicated by a reader in the preceding PRDCH and do not define any fixed timing relationship in RAN1. The reader ensures that the indicated timing can be handled by the device.
	Option 2: TR2D_nominal is defined for different D2R message types or different PHY processing requirements such as the use of FEC or not. TR2D (≥ TR2D_nominal) can be still indicated by the reader.
Proposal 11	The time interval between a R2D transmission and corresponding D2R transmission following it is determined by one of the following options:
	Option 1: D2R transmission follows R2D transmission after a predefined TR2D_nominal.
	Option 2: D2R transmission timing TR2D following a R2D transmission is determined based on the control information in the preceding R2D transmission, where TR2D ≥ TR2D_nominal.
Proposal 12	Toffset1 is indicated in a PRDCH providing a paging message.
Proposal 13	Confirm the working assumption that, for X=2, the starting time for the second Msg1 time domain resource is derived based on the starting time of the first Msg1 time domain resource plus Toffset2.
Proposal 14	Toffset2 is explicitly indicated in the preceding PRDCH providing the paging message.
Proposal 15	For a multiplexed random access for Msg1 transmission, a device first randomly selects a random access round from a number of random access rounds and, then, randomly selects one resource from a number of TDMA/FDMA resources.
Proposal 16	For a Msg2 corresponds to multiple Msg1s received from different devices, the PRDCH providing Msg2 can be received no earlier than TD2R_min from the end of the last time domain resource for Msg1 transmission.
Proposal 17	For a Msg2 corresponds to a Msg1 received from a device, the PRDCH providing Msg2 can be received no earlier than TD2R_min+TΔ from the end of the last time domain resource for Msg1 transmission, where TΔ is a timing offset determined by the time/frequency resource used for Msg1 transmission.
Proposal 18	The PRDCH providing Msg2 indicates 1) scheduling information to transmit PDRCH providing Msg3, 2) additional data request to be included in the Msg3, and 3) a subsequent command, if applicable.
Proposal 19	The frequency domain resource for Msg3 is always determined based on explicit indication in the PRDCH providing Msg2.
Proposal 20	A PRDCH providing a group signaling for multiple devices is supported.
Proposal 21	Define parameters to facilitate device dormancy including:
	A minimum and a maximum time between two consecutive PRDCHs providing triggering messages.
	A maximum time for a device, during which a device successfully finished inventory is not required to monitor a potential R2D transmission.
	A minimum time required for a device to continuously monitor a potential R2D transmission, when the device transitions into the ON state to guarantee a reachability from a reader to the device.
Proposal 22	Specify the energy status report multiplexing at the A-IoT PHY layer.

3GPP TSG RAN WG1 #121                     	R1-2503611
St. Julians, MT, May 19th – 23rd, 2025

Agenda Item:	9.4.4
Source:	InterDigital, Inc.
Title:	Discussion on multiplexing/multiple access, scheduling information, and timing relationships
Document for:	Discussion and Decision

Conclusion

The following observations are provided for discussion in RAN1#120bis:

Observation 1:	The minimum value for  can be pre-defined based on processing latency requirements for a Rel-19 A-IoT device.
Observation 2:	At least for CBRA, the minimum value for  can be derived from a pre-defined value for the maximum propagation latency between a reader and device in Rel-19 and the transmission latency of Msg1, implicitly determined from modulation and coding information provided by the reader as part of the paging procedure.
Observation 3:	At least for CBRA:
With X=1, the maximum value for  can be derived from a pre-defined value for the counting/time performance requirements for a Rel-19 device.
With X=2, the maximum value for  can be derived from a pre-defined value for the maximum propagation latency between a reader and device in Rel-19, the transmission latency of Msg1, and the counting/timing performance requirements for a Rel-19 device and implicitly determined from modulation and coding information provided by the reader as part of the paging procedure.
Observation 4:	The maximum value for  can be derived from pre-defined values for the maximum propagation latency between a reader and device in Rel-19, processing and timing requirements for the reader, and timing requirements for the device.
Observation 5:	In the case of CFRA, if the Msg1 payload size for each TDM instance cannot be pre-determined, it may be necessary for the reader to signal  and .
Observation 6:	Fixed format L1 control may not significantly increase configuration flexibility for R2D transmissions.
Observation 7:	Fixed format L1 control may reduce the reception latency and energy consumption for a device receiving PRDCH transmission.
Observation 8:	If L1 control is not included, this may limit flexibility of future designs.
The following proposals are provided for discussion in RAN1#120bis:

Proposal 1:	In addition to the indication of X={1,2} TDMA occasions for Msg1 transmission, a reader should explicitly indicate  and  as part of its initial paging message.
Proposal 2:	Whether the values of  and  are explicitly indicated or implicitly determined, their configuration should be subject to the following constraints:
When X= 1:

When X=2:


Proposal 3:	When a frequency resource for Msg3 is not explicitly indicated by the reader to a device, the device assumes the same frequency resource used for Msg1 transmission is reused for Msg3.
Proposal 4:	Down-select between fixed format L1 control multiplexed with PRDCH data, or a single PRDCH transmission with higher-layer control and data multiplexed together.
Proposal 5:	In scenarios when a device cannot transmit a PDRCH as indicated by the reader, the device can indicate its inability in place of a PDRCH transmission.

3GPP TSG RAN WG1#121		R1-2503619
St. Julian's, Malta, May 19th – 23rd, 2025

Source:	Panasonic
Title: 	Discussion on other aspects of A-IoT
Agenda Item:		9.4.4
Document for:	Discussion

Conclusions
In this contribution, we provided our views on physical channels and signaling for A-IoT. We made following proposals:
Proposal 1: For scheduling R2D transmission, any scheduling information related to resource allocation that needs to be signaled is indicated by higher-layer signaling via the PRDCH.
Proposal 2: The variable R2D control information sizes should be supported.
Proposal 3: The fixed-size control size and interpretation field (CSIF) should be introduced and it can be transmitted via higher-layer signaling.
Proposal 4: A set of Toffset2 values corresponds to the data rate are specified for the device. The appropriate value is selected for the second Msg1 transmission according to the indicatedMsg1 data rate.
Proposal 5: A combination of Case 1 and Case 2 should be supported for scheduling FDMed Msg3 transmissions.
Proposal 6: The time offset for all FDMed Msg3 transmissions should be based on the last scheduling Msg2 even when multiple Msg2 are sent before all FDMed Msg3 transmissions.
Proposal 7: The same data rate should be used for all FDMed Msg3 transmissions.

3GPP TSG RAN WG1 #121		R1-2503661
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	9.4.4
Source:	Lenovo
Title:	Discussion on multiple access, scheduling and timing aspects of Ambient IoT in NR
Document for:	Discussion 

Conclusion
In this contribution, we focus on other aspects of Ambient IoT in NR including multiple access, scheduling information, random access and timing relationship with following proposals:

Proposal 1: R2D control information for R2D reception is transmitted in L1-control signaling.
Proposal 2: Separate CRC is attached to L1 R2D control information and R2D data, respectively.
Proposal 3: L1 R2D control information includes some reserved bits for the purpose of forward compatibility.
Proposal 4: L1 control information and data are transmitted using different M values.  
Proposal 5: ID associated with device(s) for reception of R2D is transmitted in L1 R2D control information and could be early detected before the data in PRDCH by the device.
Proposal 6: Compare the overhead of TBS indication vs. postamble size to decide on the method indicating end of PRDCH transmission.
Proposal 7: Support joint indication of FEC and number of repetitions.
Proposal 8: Confirm the working assumption for indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size by using 7 bits for byte-level D2R payload size indication.

Proposal 9: Two values of Toffset1 for could be predefined in the spec, one value is for MSG1 transmission with FEC and the other value is for MSG1 transmission without FEC.
Proposal 10: Toffset2 is indicated explicitly by the R2D transmission triggering random access.
Proposal 11: Support option 1(the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device) as a default when X=1.
Proposal 12: Support Case 2 if Y>1, and support Case 3 and Case 5 if Y=1.
Proposal 13: The transmission/reception of PRDCH transmission carrying MSG4 shall be discussed in RAN1 including:
When the reader transmits the MSG4 to inform the failure of MSG3?
Option 1: The MSG4 is transmitted after all MSG3 time occasions
Option 2: The MSG4 is transmitted after the corresponding MSG3 time occasion.
How to transmit PRDCH carrying MSG4?
Option 1: A PRDCH for MSG4 transmission corresponds to a failed A-IoT MSG3 transmission from one device 
Option 2: A PRDCH for MSG4 transmissions corresponds to multiple failed A-IoT MSG3 transmissions from different devices.
Which device shall monitor the potential transmitted PRDCH carrying MSG4?
Option 1: The device who has transmitted MSG3 may assume that MSG4 may be transmitted to it.
Option 2: In the corresponding PRDCH carrying MSG2 the reader indicates whether the device needs to monitor the PRDCH transmission carrying MSG4.

Observation 1: The reader can checks the proximity of a dedicated AIoT device or reader can check whether any device is nearby in his vicinity. 
Proposal 14: RAN1 can wait until input from higher layers to work on proximity determination.
Proposal 15: Discuss number of power state supported by device 1 as it important to understand whether content such as timers, inventoried state can be preserved:   
2 states – ON, OFF 
3 states – ON, Memory retention state, OFF 

Proposal 16: Discuss whether the device can go to memory retention state within inventory round to save power 
Proposal 17: Discuss how to limit device participating in the inventory round, random access round depending on its availability of stored energy 
Proposal 18: Support energy aware slot selection in an inventory round as opposed to random slot selection.

3GPP TSG RAN WG1 #121          						R1- 2503705
Malta, Malta, May 19th – 23rd, 2025

Source:	Tejas Networks Ltd.
Title:	Discussion on multiple access, scheduling and timing aspects for A-IoT
Agenda item:	9.4.4
Document for:     Discussion and Decision

Conclusion
This work includes the multiplexing/multiple access of UL signals, number of frequency domain resources for D2R scheduling, Msg0 content, etc. We have made the following observations and proposals related to the above-mentioned aspects of A-IoT:
Observation 1: Reusing the Msg1 frequency domain resources does not guarantee efficient resource allocation, as the Msg3 size and Msg1 size can be different.
Proposal 1: We support option 2: The frequency domain resource for Msg3 can be determined based on explicit indication in the PRDCH for Msg2 transmission for one or multiples devices.
Observation 2: As the number of time domain resources for Msg1 and Msg3 are not same, reader need to send minimum two Msg2 signals for X=2 within two R2D triggers to for the devices to identify the time domain resources to transmit Msg3. 
Proposal 2: For CBRA, maximum Y devices can be scheduled within one R2D Msg2, where Y is the number of frequency domain resources.
Proposal 3: The available frequency domain resources (Y) depends on the transmission bandwidth of devices, receiver bandwidth of the reader, and the guard band. Considering channel bandwidth is same as the receiver bandwidth of the reader and the guard band is minimum 20% of the receiver bandwidth, the frequency domain resources for different values of D2R chip length are: 

Observation 3: Toffset1 and TGAP are related to device and reader processing time, respectively. TMsg1 depends on Msg1 size which can be fixed or variable based on information asked by the reader. 
Proposal 4: Toffset1 and TGAP can be predefined in the specification. TMsg1 can be implicitly or explicitly conveyed to the device through Msg0 signal.
Proposal 5: The following information can be explicitly or implicitly conveyed to the device through msg0:
Msg1 timing related information
Msg1 scheduling related information
Msg2 related information
One or multiple msg2 transmission
Proposal 6: The msg0 signal should contain the time domain resources for msg1:
Option 1: List of Time resources (T1 … TX): This field contains the time domain resources either dedicatedly allocated to the device(s) or available time domain resources for the devices to send msg.  
Option 2: Total Time slots: This indicates the total number of time slots that are allocated for sending msg1 for the devices being paged in this msg0. The start time for sending msg1 is from the end of msg0 time + TGap (optional). The device can calculate the start of a time slot as (Tmsg0_end + IndexTime_Slot * TSlot_Duration).
Proposal 7: The msg0 signal should contain the frequency domain resources for msg1:
Option 1: List of frequency resources (F1 … FY): This field contains the frequency domain resources either dedicatedly allocated to the device(s) or available frequency domain resources for the devices to send msg1.
Option 2: Total number of frequency resources: This indicates the total number of frequency resources that are allocated for sending msg1 for the devices being paged in this msg0.

3GPP TSG RAN WG1 #121	R1-2503736
St Julian's, Malta, May 19th - 23rd, 2025

Source:	Ofinno
Title:	Views on other aspects for AIoT
Agenda item:	9.4.4
Document for:	Discussion and Decision

Conclusions
In this paper we make the following observations and proposals: 
Proposal 1: Confirm the working assumption on X=2 start time determination for the second Msg1 time domain resource. 
Observation 1: The values of Toffset1 and Toffset2 should be relatively short in order to avoid too much drift by the device’s clock.
Proposal 2: Support Toffset1 and Toffset2 are predefined in the spec or implicitly determined (e.g., based on triggering R2D information value).  
Proposal 3: Specify TD2R_max - a maximum time the device needs to monitor for R2D transmission. 
Proposal 4: RAN1 to define (Toffset1 and Toffset2) into specification as the time between an end of a R2D transmission and the corresponding D2R transmission following it.
Observation 2: It is beneficial for the reader to know when the device is available or unavailable. 
Proposal 5: RAN1 to discuss potential information related to energy status indication in D2R messages as part of Direction 1 for device unavailability, including criteria to determine the energy status, related capabilities, conditions on how and when to transmit the indication, and associated behaviour of both reader and device. 

3GPP TSG RAN WG1 #121                                                                                     	 R1-2503796
St Julian's, Malta, May 19th – 23rd, 2025
  
Source:             CATT
Title:                  Ambient IoT frame structure, system control and resource allocation
Agenda Item:    9.4.4
Document for:  Discussion and Decision

Conclusion
In this contribution, the multiplexing/multiple access, timing relations and scheduling information for A-IoT are discussed. We have the following observations and proposals:
Proposal 1: The frame structure of A-IoT should be aligned with the slot boundary of the NR system for supporting slot-based PRDCH and PDRCH transmission.
Proposal 2: The following working assumption could be confirmed: 
For indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size:
•	7 bits for byte-level D2R payload size indication
Proposal 3: The TBS tables should be introduced for simple indication of TBS and the corresponding TTI under the different chip duration/data rate, which are aligned with the NR time domain resource assignment, i.e. slot.
Proposal 4: The 3 bits TBS indication table as follows should be considered for PRDCH.

Proposal 5: It should be supported that joint CRC is attached to R2D control information and R2D data.
Proposal 6: The TBS indications and the corresponding DCIs can alternatively be mapped to the R2D control information to improve its transmission performance.
Proposal 7: A common PRDCH format should be designed for paging/R2D message and Msg2.
Proposal 8: Adopt the following table for scheduling information in PRDCH:

Proposal 9: For R2D message, at least following scheduling information should be indicated:
Access type.
Number of time domain resource.
Chip duration/SFS factor.
Proposal 10: The end of the R2D transmission refers to the end of the resource for PRDCH transmission after padding.
Proposal 11: Toffset1 is explicitly included in the control signaling in the PRDCH including Paging, Msg2 and command.
Proposal 12: Following options can be considered to determine the value of Toffset1.
Option 1: Define Toffset1as a number of slots.
Candidate values: {1, 2, 3, 4}.
Option 2: Define Toffset1 as an absolute time expressed in tenths of one millisecond.
Candidate values: {0.2ms, 0.4ms, 0.6ms, 0.8ms}.
Option 3: DefineToffset1 as a number of equivalent D2R symbols.
Candidate values: {3, 6, 9, 12}.
Proposal 13: Toffset2 is implicitly indicated by the TTI length determined according to the TB size, data rate, and guard time.
Proposal 14: When the D2R chip duration is implicitly indicated by deriving from the control signaling of bit duration Tb and SFS factor R, the following three Options for D2R transmission indication should be considered with the Option a-3 being preferable for flexible indication.
Option a-1: The value/index of the bit duration Tb is explicitly indicated based on the pre-defined table, in which it also pre-defines the relationship of the bit duration Tb and corresponding chip duration Tchip and SFS factors R. 
Option a-2: The value/index of the bit duration Tb and the SFS factor R are jointly explicitly indicated for D2R transmission via the control information of PRDCH. The R could be expressed as Rmax for FDMed Msg1 transmission.
Option a-3: The value/index of the bit duration Tb is explicitly indicated and the corresponding subset of the R values is also indicated via the control information of PRDCH or based on the pre-defined table.
Proposal 15: The maximum number of Msg1 responded by one Msg2 is dependent on the gNB implementation.
Proposal 16: In the MA cases shown in the table below, only case 1 and case 3 should be supported.

Proposal 17: No need to support option 1 as a default if PRDCH does not provide the indication or based on a rule.
Option 1: the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device.
Proposal 18: The frequency domain resource for each Msg3 transmission can be indicated in Msg2 by following two options:
Option 1: {bit duration, R}
Option 2: {chip duration, R}
Proposal 19: The start time for Msg3 transmission can be indicated by Msg2 in the same way of Toffset1.
Proposal 20: Collision resolution mechanism of Msg1 transmission needs to be designed to improve the probability of successful random access.
Proposal 21: For the Msg2 transmission in response to multiple Msg1 transmissions, the device would monitor the PRDCHs for Msg2 from the first PRDCH until the one carrying its group ID and/or its device ID.
Proposal 22: The A-IoT device corresponds to the M-th ID in the Msg2 can use the M-th transmission resource indicated by Msg2 if the Msg2 schedules multiple A-IoT devices.
Proposal 23: End of the R2D transmission carrying the Msg2 scheduling the A-IoT device can be used as the reference time for the A-IoT device to determine the starting time for Msg3 transmission.
Proposal 24: It’s not necessary to define the values of TD2R_max, TR2D_R2D_min and TD2R_D2R_min in RAN1 specification.
Proposal 25: When a D2R transmission is segmented, 1 bit of new data indicator in the control information carried by the PRDCH scheduling the D2R transmission is needed to indicate the device to transmit a new segment or retransmit the last segment.

3GPP TSG RAN WG1 #121			R1-2503834
Malta, MT, May 19th–May 23th, 2025

Source: 	CMCC
Title:	Discussion on access, scheduling and timing relationships
Agenda item:	9.4.4
Document for:	Discussion/Decision

Conclusion 
In this contribution, we discussrandom access aspects, timing relations, and also the scheduling related control information. The following proposals and observations are made:
Proposal 1: Toffset1 for starting time of first Msg1 occasion is predefined in the specification.
Proposal 2: The following WA is confirmed, 
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.
Proposal 3: For FDMA of Msg1, the candidate small frequency shift factor R values need to be indicated to devices as parameter of frequency domain resources.
Proposal 4: For FDMA of Msg1, the starting time for Msg1 is Toffset1 after the end of the corresponding R2D transmission triggering random access.
Proposal 5: TD2R_max is defined for X=1 case to make sure device is responded in time.
Proposal 6: For TDMA X=2 case, only case 3: Msg2-Msg3-Msg2-Msg3 pattern is supported.
Proposal 7: Monitoring window for Msg2 or TD2R_max is not supported for TDMA X=2.
Proposal 8: For FDMA with Y>1, case 2, i.e. two PRDCHs for Msg2 Tx in response to two Msg1s followed by FDMed Msg3 is not supported.
Proposal 9：For FDMA case, TD2R_max is defined such that device can expect a Msg2 within [TD2R_min, TD2R_max] after the end of the time domain resource for Msg1 transmission.
Proposal 10: For TDMA X=1, the starting time for Msg3 is Toffset1 after the end of corresponding Msg2.
Proposal 11: For TDMA X=1 case, if no Msg3 scheduling information is carried by Msg2, Msg3 use the same data rate and chip rate as Msg1.
Proposal 12: For TDMA X=2, the starting time for Msg3 is Toffset1 after the end of corresponding Msg2.
Proposal 13: The frequency domain resource for Msg3 can be determined based on successfully reception state of Msg1 and predefined frequency resources orders.
Proposal 14: For FDMA case, when one common Msg2 schedules multiple FDMed Msg3s, the starting time for the Msg3 time domain resource is Toffset1 after the end of the corresponding PRDCH carrying Msg2.
Proposal 15: For FDMA of multiple Msg3 transmissions, support only the same data rate for the FDMed Msg3 transmissions.
Proposal 16: When X>1 and Y>1 are together used for Msg1, the number of frequency resources for FDMed Msg3 should be equal or smaller than Y.
Proposal 17: When X>1 and Y>1 are together used for Msg1, one common Msg2 can schedule at most Y Msg3s.
Observation 1: If scheduling restriction exists for gNB/intermediate UE, e.g., reader perform scheduling every X ms, the inventory process will be inefficient.
Proposal 18: Whether scheduling restriction exists for A-IOT gNB and intermediate UE and how to improve the inefficiency during inventory procedure design in such case needs to be discussed.
Proposal 19: When scheduling decision window exists due to scheduling restriction of gNB or intermediate UE, parallel querying in each scheduling decision window can be adopted to improve inventory efficiency. 
Proposal 20: The following can be considered for resource determination and timing aspects for parallel query way.
Table 2. resource determination and timing aspects for parallel query
Proposal 21: A similar terminology as Toffset1 between Msg2 and Msg3 can also be used to determine Msg3 time resource, with predefined value.
Observation 2: The value of Toffset1 can be affected by payload of R2D and D2R channel, the transmission format applied to D2R channel, the hardware capabilities and implementation, etc.
Observation 3: A large Toffset1 will increase idle time during the slot for Reader, lowering the inventory efficiency.
Proposal 22: For Toffset1, the design should account for the worst case that the device operation spends, including FEC, CRC operations for different payload size and message types. A value for the worst case can be up to 0.26ms. 
Proposal 23: The time duration of Toffset2 is likely to be less than 100ms.
Proposal 24: A TD2R_min should be defined to account for the minimum time for a device to switching from D2R channel transmission to R2D channel reception.
Proposal 25: A TD2R_max can be defined for device to determine a random access failure from physical layer.
Observation 4: The issue that Msg2 fall out of [TD2R_min, TD2R_max] due to timing offset between FDMed devices needs to be studied.
Proposal 26: A larger TD2R_max for FDMA than TD2R_max for basic no multiplexing case can be considered to solve the issue of Msg2 falling out of [TD2R_min, TD2R_max] due to SFO.
Proposal 27: Device’s identification of PRDCH function by message type is not supported by L1.
Proposal 28: Postamble is used for identification of the end of PRDCH transmission.
Proposal 29: Assistance information for Msg2 reception and Msg3 transmission can be considered to reduce device power consumption and implicitly determine Msg3 resource.
Proposal 30: For Toffset2, the indication is based on number of bits after FEC (if FEC is applied) and repetition (if repetition is applied).
Proposal 31: 9 or 10 bits can be used for Toffset2 indication.
Proposal 32: FEC information and repetition number are separately indicated.
Proposal 33: Send LS to RAN2 to include the related information that are carried by higher layer in the message definition

  

3GPP TSG RAN WG1 #121			R1-2503885 
St Julian’s, Malta, May 19th – 23rd, 2025

Source:             Xiaomi
Title:                  Discussion on other aspects for Ambient IoT
Agenda item:    9.4.4
Document for:  Decision

Conclusion
In this contribution, views on other aspects incl. multiplexing/multiple access, scheduling information, and timing relationships have been provided in this tdoc. Based on the discussion, the following observation and proposals are proposed:
Observation
Observation 1: Option 1 can really reduce the Msg2 overhead because the scheduling information should be carried by higher layer signaling, so that the blind decoding issue does not exist.
Option 1: the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device.
Proposals
Proposal 1: For X=1 or X=2, for the first Msg1 time domain resource,  Toffset1 is determined implicitly by the R2D transmission triggering random access.
Proposal 2: Toffset1 can be equal to MAX(CAP duration, 20TD2R,chip), and determined by corresponding R2D message through CAP duration and D2R chip duration.
Proposal 3:  For X=2, for the second Msg1 time domain resource, confirm the following working assumption.
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.
 Proposal 4:  Toffset2 contains the transmission time of the first Msg1 and a guard period, and can be determined implicitly by the R2D transmission triggering random access.
For the transmission time of the first Msg1, it can be determined by D2R scheduling information including the payload size, CRC length, code rate of FEC, repetition number, chip duration, and Manchester coding.
For the guard period, it can be (Toffset1+T1_1)×SFO×2, where T1_1 denotes the transmission time of the first Msg1.
Proposal 5: For FDMed Msg3 transmissions, it is recommended to keep the TBS carried in corresponding Msg2 to be the same.
Proposal 6: For FDMA of multiple Msg3 transmissions in response to a PRDCH for Msg2 transmission, support only the same data rate.
Proposal 7: The resources of Msg3 can be re-scheduled as FDM even when the Msg1 resources are TDM.
Proposal 8: Support option 1 as a default if the PRDCH for Msg2 transmission does not provide the indication.
Option 1: the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device.
Proposal 9: The frequency domain resource for a Msg3 retransmission reuses the frequency domain resource for the last Msg3 (re)transmission, if PRDCH does not provide the indication.
Otherwise, the corresponding PRDCH can re-schedule the resource for Msg3 retransmission.
Proposal 10: For indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size, support 7 bits for byte-level D2R payload size indication.
Proposal 11: For PDRCH transmission in the corresponding PRDCH, separate indication of FEC and number of repetitions is supported.
1 bit can be used for whether FEC is applied.
1 bit can be used for the number of repetitions including 1 and 2.
Proposal 12: For R2D reception, L1 R2D control signaling in PRDCH for Msg2 transmission can be used for carrying ID associated with device(s) and the ID associated with device(s) can be the index of frequency resources for FDMed Msg1 transmissions.

3GPP TSG RAN WG1 #121	R1-2503926
St Julian's, Malta, 19 - 23 May, 2025

Agenda Item:	9.4.4
Source:	NEC
Title:	Discussion on control and other aspects of ambient IoT
Document for:	Discussion and Decision
1	

Conclusion
In this contribution, we give our views on control and other aspects of ambient IoT. We propose that:
Proposal 1: Confirm the following 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.
Proposal 2: Time domain resource indication should include both number of time domain resource and payload size indication.
Option 1: 1-bit for value of X and 7-bit for payload size to form an octet;
Option 2: reuse unused bits in payload size indication for value of X indication.
Proposal 3: For Msg1 TDM when X=2, for the time duration of Msg1 transmission ,
the first Msg1 transmission starts at  after the end of R2D transmission triggered Msg1 transmission; 
the second Msg1 transmission starts at  after the end of R2D transmission triggered Msg1 transmission, i.e., , where  = 5/4.
Proposal 4: For Msg1, TDMed+FDMed transmission can be supported (i.e., X=2, Y>1).
Proposal 5: For the multiplexing schemes of Msg2/Msg3, additional support of Case 3 (separate Msg2 scheduling interleaved Msg3s without FDM) besides Case 1 (one or more common Msg2 scheduling FDMed Msg3s).
Case 2 (continuous separate Msg2 scheduling FDMed Msg3s) is not supported at least in Rel-19;
The case where multiple common Msg2s which scheduling multiple FDMed Msg3 is covered by Case 1.
Proposal 6: When the Msg1 resources are TDMed only (i.e., X=2 with Y=1), Case3 for Msg2/Msg3 multiplexing scheme should be adopted, i.e., 
There are at most two time-interleaved Msg3 resources without FDM corresponding to at most two separate Msg2s.
Proposal 7: When the Msg1 resource(s) are not FDMed (i.e., X=1 or 2 with Y=1), the Option 1 for Msg3 frequency domain resource allocation should be adopted.
Option 1: The frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device.
Proposal 8: When the Msg1 resources are FDMed only (i.e., X=1 with Y>1), Case1 for Msg2/Msg3 multiplexing scheme should be adopted, i.e.,
There are at most Y FDMed Msg3 resources corresponding to only one common Msg2.
Proposal 9: When the Msg1 resources are TDMed+FDMed (i.e., X=2 with Y>1), Case1 for Msg2/Msg3 multiplexing scheme should be adopted, i.e.,
There are at most 2*Y FDMed Msg3 resources and at most two common Msg2s, each Y FDMed Msg3 resources are corresponding to each one of the two common Msg2s.
Proposal 10: When the Msg1 resource(s) are FDMed (i.e., X=1 or 2 with Y>1), 
When the Msg2 PRDCH does not provide the indication for Msg3, Option 1 for Msg3 frequency domain resource allocation should be adopted:
Option 1: The frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device.
Otherwise, Option 2 for Msg3 frequency domain resource allocation is adopted:
Option 2: The frequency domain resource for Msg3 can be determined based on explicit indication in the PRDCH for Msg2 transmission for one or multiples devices;
The candidate values of R for Msg3 should be same to Msg1 which is indicated in A-IoT paging signaling.
Proposal 11: From device perspective, the starting time for the Msg3 time domain resource is T Msg3, offset after the end of the corresponding R2D transmission of Msg2.
To be further decide in RAN1#121 on whether TMsg3, offset is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access;
If it is pre-defined, RAN1 also need to decide whether a value separate from Toffset1 should be defined.
Proposal 12: Whether the TBS indication to determine the Msg3 time duration is required to be indicated by the corresponding R2D transmission of Msg2 should be discussed by other WGs.
Proposal 13: For one common Msg2 transmission to schedule multiple Msg3 in FDMA mode, support compact Msg2 design for the resource indication of Msg3.
Proposal 14: Support device transmitting Msg3 after the corresponding Msg2 reception. 
Proposal 15: RAN1 needs to identify whether the Msg3 payload of devices is the same or not, and try to align the Msg3 transmission of devices. 
Proposal 16: Support joint indication of FEC code rate and repetition number with 3 bits using Table below:

3GPP TSG RAN WG1 #121			R1-2504049
St Julian’s, Malta, May 19th-23th, 2025

Agenda item:		9.4.4
Source:				China Telecom
Title:					Discussion on other aspects for Ambient IoT  
Document for:		Discussion

Conclusions
In this contribution, we have the following observations and proposals:
Observation 1: Case 2 has a smaller time interval between the MSG2 and the corresponding MSG3 compared with case 5.
Proposal 1: Support codepoint indication method for the joint indication of SFS factor, chip duration and raw bit duration.
Proposal 2: Confirm the working assumption that using 7 bits indication for payload size.
Proposal 3: Support a same chip duration between CAP part and data part, and M value is acquired by the CAP part.
Proposal 4: Support a joint indication of FEC and repetition number with the following indication table:
Proposal 5: Support an early indication mechanism where some L1 control information is added in the front of the PRDCH channel, including message type or ID information.
Proposal 6: Support a separate CRC coding scheme for PRDCH channel design.
Proposal 7: Support pre-defining or pre-configuring several Toffset1 values and indicating one Toffset1 value among them.
Proposal 8: Confirm the working assumption of determining the starting time for the second Msg 1 time domain resource.
Proposal 9: Support pre-defining or pre-configuring several Toffset2 values and indicating one Toffset2 value among them.
Proposal 10: Support MSG2 monitoring window for device 1.
Proposal 11: Determining the starting occasion of MSG2 monitoring shall depend on the total number of time domain resources or the interval between the first time domain resource and the starting occasion.
A common starting occasion is supported if a short interval or small resource amount is configured.
Otherwise, a separate starting occasion will be more appropriate.
Proposal 12: Support case 3 with the highest priority for the MSG3 transmission.

3GPP TSG RAN WG1 #121									R1-2504064
St Julian’s, Malta.  19-23 May 2025
Agenda Item 	:	9.4.4
Source 	:	Sony 
Title 	:	Multiple access and timing relationships for Ambient IoT 
Document for 	:	Discussion 

Conclusion 
This document has considered the relationship between messages in the initial access procedure of Ambient IoT. The following proposals are made:
Observation 1 – Selecting the same Msg2 monitoring window for both options may lead to extra delay or unnecessary power consumption at the AIoT Device
Proposal 1 – Include information such as a bit indicator in Msg0/paging message to indicate whether the Msg2 transmission is in response to one device or multiple devices 
Proposal 2 –Associate different Msg2 monitoring windows, i.e., reference time and time duration, to Msg2 transmission corresponding to a Msg1 received from one device or from multiple devices.
Proposal 3: Support association between the selected Msg1 time and frequency resources to its Msg2 time resources. 

Proposal 4: support option 1 as a default if PRDCH does not provide the indication or based on a rule 
Option 1: the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device when X=1.

3GPP TSG RAN WG1 #121	R1- 2504091 
St Julian's, Malta, May 19th – 23rd, 2025

Agenda Item:	9.4.4
Source:	Fujitsu
Title:	Discussion on other aspects of Ambient IoT
Document for:	Discussion

Conclusion
In this contribution, we have the following observations and proposals considering the other aspects of AIoT:
Proposal 1:
Regarding the starting time of Msg.1 time domain resource, i.e., Toffset1 / Toffset2, an explicit indication as control information carried by PRDCH should be supported. 
Observation 1:
The key point to the selection between Option 1 and Option 2 is that the reader does not need to separately indicate the duration of the first Msg.1 which the device can derive by itself according to other information rather than Toffset2.
Option 1 includes redundancy. 
Option 2 can save the signaling overhead for the Toffset2 indication compared with Option 1.
Proposal 2: Toffset2 should be from the end of the first Msg.1 to the start of the second Msg.1.
Observation 2:
In the case FDMA based Msg.3s are transmitted with variable TBS, the reader transmits the subsequent R2D until it completes receiving the Msg.3 with the longest duration in time domain.
If only the same data rate is supported, the larger TBS for Msg.3 results in the longer duration in time domain. The spectrum efficiency is low if significant differences occur on time domain durations among the FDMA based Msg.3s. 
If different data rates are allowed, the reader can allocate a high data rate for large TBS of Msg.3, which can shorten the receiving window for Msg.3s on the reader. In that case, the spectrum efficiency can be improved as well.
Proposal 3:
The different data rates for FDMA based multiple Msg.3 transmissions are supported if the TBS of Msg.3s is variable.
Proposal 4:
To support the different data rates for FDMA based multiple Msg.3 transmissions, the data rate for each Msg.3 transmission can be implicitly or explicitly indicated in Msg.2.
Proposal 5:
Regarding MCS-like scheduling information for D2R transmission, the joint indication (Option 2) of FEC and repetition number is supported.

3GPP TSG RAN WG1 #121	 R1-2504100
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda Item:	9.4.4
Source:	HONOR
Title:	Discussion on L1 control information and L1 procedural aspects
Document for:	Discussion and Decision

Conclusions
In this contribution, we discuss on L1 control information and L1 procedural aspects with the following observations and proposals.
Observation 1: Indicating relevant information in the control information of Msg2 not only can flexibly determine the corresponding Msg2 message but also can save the device's demodulation energy consumption.
Observation 2: The message type allows the device to know as early as possible whether the following information needs to be processed.

Proposal 1: Toffset1 is explicitly indicated by the R2D transmission triggering random access.
Proposal 2: Toffset2 is obtained based on the start time of the first Msg1 time domain resource, the time domain length of Msg1, and the GAP between Msg1. Additionally, the time domain length of GAP reuses the value of Toffset1.
Proposal 3: The control information of Msg2 indicates the relevant information for the device to determine the Msg2 response message.
Proposal 4: Support option 2 as the selection scheme for the starting reference point of Msg2.
Proposal 5: Support Option 2 for the time duration for A-IoT Msg2 monitoring.
Proposal 6: Do not support option 1 for the allocation of Msg3 frequency domain resources.
Proposal 7: Use the same bitmap to indicate the frequency resources for Msg3 of all responding users.
Proposal 8: The control information includes the message type.
Proposal 9: The control information of the unicast message contains the device ID.
Proposal 10: Support L1-control signal to carry control information. 

TDoc file reading error

3GPP TSG-RAN WG1 Meeting #121			R1-2504208
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda item:	9.4.4
Title:	Discussion on other aspects of A-IoT communication
Source:	OPPO
Document for:	Discussion and Decision

1. 

Conclusion
TDMA and FDMA of D2R transmissions
Observation 1: For the case of CFRA, RAN2 so far considers the reader will page only one device at a time. Therefore, there will be no FDMed transmissions from multiple devices at the same time (for both Msg.1 and Msg.3). RAN1 does not need to have further discussion on FDMed transmissions and data rate issues for the case of CFRA, unless RAN2 makes further agreement(s) to support multiple devices for the CFRA case.
Proposal 1:
Same Tb, repetition factor and FEC coding rate are applied to all FDMed Msg.3 transmissions in response to a PRDCH for Msg.2 transmission.
Same Tb, repetition factor and FEC coding rate are applied to all FDMed Msg.1 transmissions (if supported) in response to R2D transmission triggering CFRA.
Proposal 2: The time domain resource of any scheduled D2R is indicated as an offset value w.r.t. the end of corresponding R2D.
Observation 2: The time length for Toffset1 is dependent on both device processing time including FEC for receiving and decoding of a paging message in R2D, and device preparation time for D2R transmission including SFS. These are further dependent on the total payload size of the paging message and the payload size of D2R transmission. At this moment, the payload information for PRDCH and PDRCH is still unclear to determine the exact value for Toffset1.
Proposal 3: Multiple Toffset1 values should be pre-defined and the one to be used is indicated by the R2D control signaling.
Proposal 4: The value of Toffset2 can be derived by a device based on a rule as: 
Toffset2 = Time length of Msg.1 + Guard Interval, where
Time length of Msg.1 is determined by 16-bit payload, CRC, FEC, repetition, D2R chip length
Guard Interval = (Toffset1 + time length of Msg.1) x 0.2
Control and scheduling information
Observation 3: For support of unicast and groupcast in command use cases, device ID or device group ID are needed for the device to identify whether it is the target of the PRDCH.
Proposal 5: For R2D reception, ID associated with device(s) intended for the reception of R2D is explicitly indicated to the device via PRDCH as control information, the ID is mapped to the beginning of PRDCH.
Observation 4: As RAN2 has already agreed that one field is included in the MAC header for SDU length indication, there is no needed to support R2D post-amble or even physical layer control information for R2D TBS indication, the device can be aware of the end of PRDCH by decoding the MAC header in advance.
Proposal 6: Send an LS to RAN2 to inform them that RAN1 relies on the MAC header to indicates the end of R2D transmission when MAC PDU includes one MAC SDU, or multiple MAC PDU if supported by RAN2.
Proposal 7: For Msg.1 scheduling, the length of time domain resources for both 1st and 2nd Msg.1 are NOT explicitly indicated.
Proposal 8: For scheduling of FDMed Msg.1 transmissions, the signaling design in the paging R2D control information should be based on the following:
Indication of Tb, repetition factor, and FEC coding rate (1 or 1/3) (all devices should have the same data rate)
Indication of Y value (total number of allocated SFS frequency positions)
Proposal 9: For scheduling of FDMed Msg.3 transmissions, the signaling design in the Msg.2 R2D control information should be based on the following:
Indication of Tb, repetition factor, and FEC coding rate (1 or 1/3) (all devices should have the same data rate)
Indication of one or multiple of {device ID (RN16), R}
Proposal 10: For D2R scheduling, repetition factor should be indicated.
Proposal 11: Following control information should be included in R2D control information for preamble/midamble indication:
F0: Presence of midamble
F1: Length of preamble and midamble
F2: Interval (in terms of unit of interval)
F3: Midamble at the end
Device (un)availability direction 1
Observation 5: No specification impact is needed to support Direction 1 of device (un)availability, due to
No information signaling is to be exchanged between the BS reader and devices.
It is not necessary for the BS reader to know the (un)availability of a device type 1 since the power consumption is very low (around 1µW).
It can be based on BS reader implementation to signal paging information at appropriate timings / intervals such that a device type 1 can sustain at least one round of inventory / command process.
Proposal 12: for RAN1 conclusion: It is concluded no specification effort will be taken in Rel-19 to support direction 1 as a solution for device (un)availability.
7. 

3GPP TSG RAN WG1 #121						R1-2504246
St. Julien’s, Malta, 19 – 23 May, 2025

Agenda Item:	9.4.4
Source: 	LG Electronics
Title: 	Other aspects for A-IoT
Document for:	Discussion and decision

Conclusions
In this contribution, we discussed other aspects including multiplexing/multiple access, scheduling information such as L1 control information, timing relationships and other L1 procedural aspects for Rel-19 Ambient IoT. For Rel-19, we have the following proposals and observations.
Proposal 1: If MSG2 does not provide explicit indication to the frequency resource index (e.g., frequency shift value) of Msg.3 transmission, when both FDMA of Msg.1 transmission and FDMA of Msg.3 transmission are scheduled, agree that the frequency resource index (e.g., frequency shift value) of Msg.3 transmission is defined to be the same as the frequency resource index of Msg.1 transmission for the same device.
Observation 2.2A: According to WID, only one identifier can be included in A-IoT paging. Thus, if one R2D message triggers CFRA, it is likely that X is always equal to one for the R2D transmission triggering CFRA.
Proposal 2: L2 R2D control information indicates the value of X (X=1 or X=2) time domain resource(s) only for CBRA Msg1 transmission(s). For CFRA Msg1 transmission (i.e. when only one identifier is indicated by a R2D transmission triggering CFRA), the value of X is not explicitly included in the L2 R2D control information of the R2D transmission.
Observation 2.2B: Toffset2 depends on the duration of the first Msg1 time domain resource and device’s SFO requirement. There can be multiple candidate Toffset2 values at least depending on the duration of the first Msg1 time domain resource.
Proposal 3: support multiple candidate Toffset2 values at least depending on the duration of the first Msg1 time domain resource.
Proposal 4: The starting time for Msg2 monitoring is different for TDMed Msg1 resources but common for FDMed Msg1 resources.
Proposal 5: For the time duration for Msg2 monitoring, both options can be specified. Thus, the time duration can be predefined or indicated in the R2D transmission triggering random access. One indicator can be included in the R2D control information to indicate whether the time duration is predefined or indicated by subsequent bits in the control information.
Observation 2.4A: For X=2, if maximum Y is fully used for FDMed Msg1 transmissions on the first/second time resources, Case 1 and 2 cannot provide Msg3 resources to all devices which transmitted Msg1. Thus, at least one or both of Case 3 and Case 5 should be considered.
Observation 2.4B: Case 2 may work only when the second Msg2 transmission indicates a small number of responses leading to a short Msg2 transmission. Thus, usage of Case 2 is more or less restricted.
Observation 2.4C: Case 5 may work when the second Msg2 transmission indicates a small number of responses leading to a short Msg2 transmission and when the first Msg3 transmission is short. Thus, usage of Case 3 is even more restricted.
Proposal 6: Case 3 as well as Case 1 is supported but neither Case 4 nor 5 supported in Rel-19. FFS whether to support Case 2 depending on minimum Msg2 size e.g. responding to only one Msg1.
Proposal 7: The minimum time interval between R2D transmissions TR2D_R2D_min can be considered regardless of whether one or more of the R2D transmissions targets the device or not.
Observation 2.5A: If L1 control information is supported in a PRDCH, a device can terminate processing any R2D transmission not corresponding to the device. Thus, adopting L1 control information in PRDCH can reduce the minimum time interval required between R2D transmissions, especially when a second PRDCH targeting the device follows a first PRDCH not targeting the device.
Proposal 8: Support L1 control information of PRDCH indicating a Msg Type, at least for Msg2, Msg4 and other messages.
Msg Type indicates one of Msg2, Msg4 and other messages including paging and subsequent paging.
L1 control information indicating other messages implicitly indicate ‘broadcast’ PRDCH which all devices are expected to process.
Devices expect that L1 control information indicating Msg2 also includes the number of responses, and a list of Msg1 resource index.
Devices expect that L1 control information indicating Msg4 also includes Device ID.
Observation 2.5B: gNB should be able to understand whether a R2D transmission triggers CBRA or CFRA and whether a R2D transmission triggers transmission of Msg1 or Msg3 (or something else) for one or more devices. If not, it is unclear how gNB can properly allocate time/frequency resources for CBRA, CFRA, Msg1 or Msg3.
Proposal 9: Support L1 control information of PRDCH at least for Msg2 PRDCH where the L1 control information indicates Msg Type 2, the number of responses, and a list of Msg1 resource index for response(s) to Msg1 transmission(s).
For a positive response to a Msg1 in a Msg2, L1 control information indicates the resource index of the Msg1 transmission while L2 control information indicates a random ID acquired from the Msg 1 on the resource index. The resource indexes are listed in L1 control information in the same order of the corresponding random IDs in L2 control information.
Msg1 resource index = (y-1) + Y*(x-1), where y = 1…Y, x = 1…X.
Observation 2.5C: If the maximum number of Msg2 transmissions or the end of Msg2 transmission is known to devices in Case 2, 3 and 5, devices do not need to process any Msg2 transmission after the end of Msg2 transmission.
Proposal 10: For Case 2, 3 or 5, consider one of the following options:
Option 1: The maximum number of Msg2 transmissions for a R2D transmission triggering Msg1 is pre-defined, determined based on a rule (e.g. X value of Msg1) or indicated by Msg2 or the R2D transmission triggering Msg1.
Option 2: A Msg2 transmission in a PRDCH indicates whether this PRDCH corresponds to the end of Msg2 transmission for the R2D transmission triggering Msg1.
Option 3: A Msg2 transmission in a PRDCH indicates whether a next Msg2 will be transmitted for the R2D transmission triggering Msg1.
Option 4: A device processes any detected Msg2 PRDCH until the end of this random access e.g. by reception of Msg4 or a R2D transmission triggering re-access from the device.
Proposal 11: Support L1 control information for identification of PRDCH, i.e. Option 1 for R2D reception.
Proposal 12: Support L1 control information of PRDCH indicating a version or a release for enhanced devices in future releases to avoid unnecessary reception of PRDCH for forward compatibility.
Proposal 13: If RAN1 agrees support of L1 control information for PRDCH, TBS information related to PRDCH is included in L1 control information to indicate the end of TB transmission before potential padding for alignment with the boundary of a OFDM symbol.
Proposal 14: For D2R transmission with a fixed size based on msg type indication in the corresponding R2D control information, e.g. Msg1 for CBRA, TBS-like indication can be omitted in the corresponding R2D control information.
Proposal 15: PDRCH repetition related information such as repetition number is indicated by R2D control information.
Proposal 16: For PDRCH with TB repetitions, PDRCH transmission can be repeated with midamble and, if the number of repetitions is not indicated or the repetition suddenly ends e.g. due to lack of energy, it may ends with midamble.
Proposal 17: ID (e.g. device specific AS ID) can be included in L1 control information for a R2D transmission triggering CFRA or a command message dedicated to one device. A device may determine whether to continue to receive the remaining PRDCH transmission by checking the ID in a front part of the L1 control information.
Proposal 18: There can be only a single ID field, if any, in R2D control information for both PRDCH and PDRCH at least in unicast transmission, i.e. the single ID in the R2D control information is used for R2D reception and D2R scheduling.
Proposal 19: Device states are not defined in Rel-19 A-IoT
Proposal 20: Proximity determination in Rel-19 is up to reader’s implementation. Solution 2 can be discussed for proximity determination in Rel-20.
Observation 2.8: whether/how Rel-19 device can make an access to Rel-20 reader can be discussed in Rel-20, not in Rel-19.
Proposal 21: RAN1 can discuss whether/how Rel-19 readers avoid or control accesses from Rel-20 devices during Rel-19 work.

3GPP TSG RAN WG1 #121			R1-2504299
St Julian’s, Malta, May 19th – 23th, 2025

Agenda Item:	9.4.4
Source:	Google
Title:	Discussion on multiplexing, multiple access, scheduling information, and timing relationships
Document for: 	Discussion

Conclusion
According to the above discussion(s), we have the following observation(s) and/or proposal(s). 
Proposal 1: For FDMA of multiple Msg3 transmissions in response to a PRDCH for Msg2 transmission, support both the same and different D2R data rate(s) for the FDMed Msg3 transmissions. 
Proposal 2: Rel-19 A-IoT, support indicating ID associated with device and message type information in the R2D control information for R2D reception.  
Proposal 3: Support a PDRCH can be used to transmit D2R data only or to transmit both D2R data and D2R control information (if D2R control information is identified as needed).  
Proposal 4: Support D2R control information to indicate whether reception of the R2D command at the device is successful or not. 

3GPP TSG RAN WG1 #121		R1-2504321
St Julian’s, Malta, May 19th – 23th, 2025

Source: 	Apple Inc.
Title:                      On remaining multiple access, scheduling and control aspects for Ambient IoT
Agenda item:	9.4.4
Document for:	Discussion and Decision
1 

Conclusion 
In this contribution, we have presented our views on random access, scheduling and timing aspect for Type-1 Ambient IoT device. We proposed the following: 
Proposal 1: Support a unified solution for Msg1 and Msg3 TDRA by predefining a set of  candidate values for Toffset1, Toffset2  and time offset of Msg3 in specification, and a specific value is selected by reader for each through control information in the paging command and Msg2. 
 Proposal 2: Support a same data rate for FDMed Msg3 transmissions in response to a Msg2 PRDSCH.

3GPP TSG RAN WG1 #121	R1-2504397
St Julian’s, Malta, May 19th – 23th, 2025

Source:	Qualcomm Incorporated
Title:	Discussion on other aspects for Rel-19 Ambient IoT
Agenda Item:	9.4.4
Document for: 	Discussion and Decision		

Conclusion
In summary, we have the following proposals for 9.4.4:

For configuration of TDMA/FDMA:
Proposal 1: For FDMA of multiple CFRA Msg1 or Msg3 transmissions in response to a R2D transmission, RAN1 to decide
Opt1: support same data rate for FDMed D2R transmission with same TBS
Opt2: support different data rate for FDMed D2R transmission with different TBS if supported

Proposal 2: For Msg1 with X=2, RAN1 to down select 
Opt1: support same Msg1 transmission time for 1st and 2nd time domain resource
Opt2: support shorter Msg1 transmission time in the 1st time domain resource than that of 2nd one

Proposal 3: For CBRA Msg1 or CFRA Msg1 with X=2 and Y>1, down-select 
Opt1: same FDMA configuration is configured for 1st and 2nd time domain resource
Opt2: different FDMA configuration can be configured for 1st and 2nd time domain resource

For :
Proposal 4:  is counted from the end of the last bit of PRDCH (before the start of the padding) till the start of D2R preamble of corresponding D2R transmission.
The end of the last bit for PRDCH can be determined based on the TBS indicated in R2D L1 control.

Proposal 5: For D2R with X=1, from device perspective, the starting time for the D2R transmission is  after the end of the corresponding R2D transmission.

Proposal 6: For , it can be implicitly derived based on the R2D chip duration , D2R chip duration , and additional processing time if needed, as

For PDRCH without FEC,  
For PDRCH with FEC, 
Alt1: attach CRC not at the end,  
Alt2: attach CRC at the end, 
For Msg1/Msg3/D2R feedback, apply TBS restriction of [up to 12bytes] or use precalculated CRC,  .
For D2R data transmission,  with D2R preamble time  and processing time for CRC/FEC.
  with sampling rate 

Proposal 7: For Msg1/Msg3 with FDMA, the chip duration  of the smallest frequency shift for the FDMA is used to derive .  

Proposal 8: For , it can be implicitly derived based on  and Msg1 transmission time in the 1st time domain resource as .

Proposal 9: For Msg1 with X=2 and FDMA, the common Msg1 transmission time in the 1st time domain resource is used to derive .

Proposal 10: For Msg1 with X=2,  or  is randomly selected for CBRA Msg1 or indicated for each CFRA Msg1.

For :
Proposal 11: For R2D response associated with a single D2R transmission,  can be counted from the end of the last bit of the D2R transmission till the potential start of the corresponding R2D transmission, where the start of the R2D transmission is the first rising edge of R-TAS.

Proposal 12: For Msg2 corresponding to one or multiple Msg1 transmissions,  can be counted from the end of the last Msg1 transmission resource(s) till the potential start of the corresponding Msg2 transmission.
For Msg1 with X=1 and FDMA, the  in the 1st time domain resource is used to derive the start of  as ).
For Msg1 with X=2 and FDMA, the  in the 2nd time domain resource is used to derive the start of  as ).

Proposal 13: , where  is the chip duration.  
For Msg1/Msg3 with FDMA, the chip duration  of the smallest frequency shift for the FDMA is used to derive .  

Proposal 14: Define  at least for R2D monitoring corresponding to single D2R transmission.  


For R2D L1 control:
Proposal 15:
The Msg type, transaction ID, device ID are indicated in R2D L1 control with separate CRC to enable early indication / termination.

Proposal 16:
The TBS of PRDCH is indicated in L1 control, based on which the device can determine the CRC length and the end of PRDCH before padding if any.

For scheduling information related to resource allocation for D2R transmission, it will be indicated by higher layer. We propose
Proposal 17: For D2R FDRA, the D2R with or without FDMA should be considered, respectively.
For unicast D2R,  no FMDA. FDRA needs to indicate 
: 3bits
: predefined as R=1 for 720kbps and R=2 otherwise. 
For CBRA Msg1:   FDMA can be supported
: 3bits
 and : FFS bitmap, codepoint, Y+Rmin+gap, or Y+Rmax+rule. 
For Msg3 or CFRA Msg1:  FDMA can be supported
: 3bits
 and : FFS bitmap, codepoint, Y+Rmin+gap, or Y+Rmax+rule. 

Proposal 18: For D2R coding and block-level repetition, joint indication is supported. RAN1 to down select one of alternatives
Alt1: 2bits for {no FEC, FEC1/2, FEC1/3, FEC1/3+rep}
Alt2: 2bits for {no FEC, FEC 1/3, FEC 1/3+rep2, FEC 1/3+rep4}
Alt3: 2bits for {no FEC, FEC 1/3, FEC 1/3+rep2, reserved}

Proposal 19: For TBS of PDRCH 
Confirm the following WA for PDRCH with modification:
Working assumption
For indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size for unicast D2R data scheduling: 7 bits for byte-level D2R payload size indication
For CFRA Msg1 and Msg3, TBS with variable size: [4]bits for byte-level D2R payload up to [12]bytes.
Send LS to RAN2 to confirm the TBS of PDRCH.

For D2R TBS for D2R data: 
Proposal 20: For D2R data transmission, the transmitted TBS can be smaller than that of TBS indicated by the reader. 

3GPP TSG RAN WG1 #121                                   R1-2504436
St Julian’s, Malta, May 19th - 23rd, 2025

Source:	Sharp
Title:	Discussion on other aspects
Agenda Item:	9.4.4
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss a few aspects related to multiplexing/multiple access, scheduling information, and timing relationships in A-IoT, and make the following observations and proposals.
On time-domain resource allocation for Msg3 transmission, Case 3 is already supported in order to support retransmission of Msg2.
It should be supported that the following can be multiplexed in a same R2D transmission:
RAR transmissions or retransmissions, and
Explicit R2D failure/success feedback for Msg3.
It is beneficial to support “early termination” in R2D reception at least for saving energy for receiving really intended R2D transmission(s).
For FDMA of multiple Msg3 transmissions in response to a PRDCH for Msg2 transmission, support only same data rate for the FDMed Msg3 transmissions.
At least for a long R2D transmission, a device can receive a first part of a PRDCH in an R2D transmission, and determine (by the MAC layer) whether to continue or abort PRDCH reception by information indicated in the first part of the PRDCH, i.e. reception of an R2D transmission not intended for the device can be “early terminated”.
A separate CRC is attached to the first part of the PRDCH.
The R2D chip duration for a PRDCH is the same as the clock-acquisition part of the R2D time acquisition signal immediately preceding the PRDCH.

3GPP TSG RAN WG1 #121	                      	 R1-2504475
St Julian’s, Malta, May 19th – 23th, 2025

Agenda Item:	9.4.4
Source: 	ASUSTeK
Title:  	Discussion on control information and procedural aspects
Document for:	Discussion and Decision

Conclusion
In this contribution, we have following proposals for A-IoT control information and access procedure:
Proposal 1:  For X=2, when a device selects the first Msg1 time domain resource, the device is not required to monitor a corresponding R2D transmission earlier than Toffset2 + TD2R_min 
after the end of Msg1 transmission from the device.
Proposal 2:  In response to multiple Msg1 transmissions, reader provides PRDCH for Msg2 transmissions following a Msg2 transmission order. 
FFS the Msg2 transmission order is designed directly from indexing Msg1 resources 
or provided from initial PRDCH for Msg2 transmission. 
Proposal 3:  For Msg3, support option 1 as a default if PRDCH does not provide the indication.
Option 1: the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device.
Proposal 4:  For Msg3 or command case, time length of D2R occasion is scheduled by R2D control information.

3GPP TSG RAN WG1 #121			R1-2504504 
St Julian’s, Malta, May 19th – 23th, 2025

Source:	NTT DOCOMO, INC.
Title:	Discussion on other aspects for Ambient IoT
Agenda Item:	9.4.4
Document for: 	Discussion and Decision

Conclusion
Proposal 1: 
The following information is indicated in L1 R2D control for scheduling of R2D reception.
AS ID of device
TBS of R2D data
Proposal 2: 
Support following structure of R2D transmission.
R2D timing acquisition signal immediately precedes L1 R2D control, and L1 R2D control precedes R2D data.
Proposal 3: 
Separate CRC is attached to L1 R2D control information and R2D data.
Proposal 4: 
If AS ID is indicated in L1 R2D control, for R2D paging message, the R2D message introduced for determining MSG1 resources, Msg.2, AS ID field in L1 R2D control is set to a specific value, e.g., all zeros.
Proposal 5: 
For D2R transmission in CBRA/CFRA Msg.1, Msg.3 and step C2 (D2R data transfer after random access), following scheduling information is carried in corresponding R2D transmission. 
Repetition factor.
Whether FEC is enabled. 
If multiple FEC coding rates are supported, FEC coding rate is indicated.
Proposal 6:
For CBRA/CFRA Msg.1 transmission, the scheduling information for repetition and FEC are indicated in A-IoT paging message. 
Proposal 7: 
Scheduling information for repetition and FEC are separately indicated.
Proposal 8: 
For D2R transmission in step C2/data transfer after random access, AS ID of device indicated in L1 R2D control is applied for both scheduling of R2D reception in step C1 and scheduling of D2R transmission. 
Proposal 9: 
The 1-bit indication of X=1 or X=2 is carried in the new R2D message introduced for determining Msg.1 resources.
Proposal 10: 
For X=1 or X=2, for determination of starting time of the first CBRA/CFRA Msg.1 time domain resource, the value of Toffset1 is predefined in spec. 
Proposal 11: 
Different values of Toffset1 are predefined for the Msg.1 transmission with FEC and without FEC. 
Proposal 12: 
The value of Toffset1 can be compatible with T1 in RFID.
Proposal 13: 
Confirm the following working assumption.
Proposal 14: 
For X=2, for determination of starting time of the second CBRA Msg.1 time domain resource, the value of Toffset2 is predefined in spec.
Proposal 15: 
Different values of Toffset2 are predefined for different data rate of Msg.1 transmission. 
The value of Toffset2 can be approximately Tmsg1 + 2 * (Toffset1 + Tmsg1) * SFO, where Tmsg1 is the duration of Msg.1 time domain resource.
Proposal 16: 
For starting time of Msg.3 transmission, time interval between the end of Msg.2 and start of corresponding Msg.3 is explicitly indicated in Msg.2.
The minimum value of time interval which can be indicated by reader can be the same value as Toffset1.
The maximum value of time interval which can be indicated by reader should at least be longer than duration of one Msg.2 and at least longer than duration of one Msg.3. 
Proposal 17: 
For starting time of D2R transmission in step C2 D2R (D2R data transfer after random access), time interval between the start of D2R and end of R2D corresponding to the D2R is explicitly indicated in the R2D corresponding to the D2R.
The minimum value of time interval which can be indicated by reader can be the same value as Toffset1.
The maximum value of time interval which can be indicated by reader should at least be longer than duration of one step C2 R2D and at least longer than duration of one step C2 D2R. 
Proposal 18:
Support , i.e., 
For Msg.2 in response to X=1 Msg.1 transmission, a device is expected to receive a PRDCH for Msg.2 corresponding to the A-IoT Msg.1 transmitted by the device no later than  after the end of the time domain resource for Msg.1 transmission. 
For Msg.2 in response to TDMA of X=2 Msg.1 transmissions, device is expected to receive a PRDCH for Msg.2 corresponding to the A-IoT Msg.1 transmitted by the device no later than  after the end of the last of X time domain resources for Msg.1 transmissions.

TDoc file reading error

3GPP TSG RAN WG1 #121 				                                                                       R1-2504589
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda Item:	9.4.4
Source:	TCL  
Title:	Discussion on multiple access, scheduling information and timing relationships for Ambient IoT
Document for:	Discussion and Decision 

Conclusion
In this contribution, we discuss random access, scheduling and timing relationships for Ambient IoT. We have the following observations.
Observation 1: If TDMA is used for Msg1 is applied, option 1 (i.e., the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device) cannot be used directly.
It is proposed that
Proposal 1: At least for CBRA, for multiple Msg1 transmissions in response to a R2D transmission triggering random access, support only the same data rate for the Msg1 transmissions.
Proposal 2: Clarify each Msg1 time domain resource should include the resource for D2R preamble.
Proposal 3: For TDMA based MSG1, Toffset1 is explicitly indicated by a R2D signaling.
Proposal 4: 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
Toffset2 is predefined in the spec or indicated explicitly by the R2D transmission triggering random access. 
Proposal 5: Consider indicating the combination of {X, Toffset1, Toffset2} or {X, Toffset1} by a R2D signaling to determine MSG1 time domain resources.
Proposal 6: For the MSG1 retransmission, the same information of MSG1 resource set for initial transmission can be used.
Proposal 7: For option 1 and TDMA with X>1 or FDMA based MSG1 transmission, a common time duration (i.e., Msg2 monitoring window) can be defined for MSG2 resources for different devices.
Proposal 8: For Option 1, consider how the device to determine the MSG2 resource location within the common time duration to further saving the device’s power consumption.
Proposal 9: Consider how the information carried by MSG2 to confirm whether the random access for a device is successful:
Random ID as similar as in RFID and NR
ACK/NACK feedback
Proposal 10: For Option 2, consider how the device to determine its own location within a MSG2.
Proposal 11: Further study the retransmission resource of MSG2.
Proposal 12: Support only the same data rate for MSG3. The same chip rate is used for MSG1 and MSG3.
Proposal 13: Support option 1 (i.e., the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device) at least for FDMA based Msg1 transmission.
Proposal 14: The resource size of MSG3 can be indicated by MSG2 and the frequency location of MSG3 can be reused that of MSG1.

3GPP TSG RAN WG1 Meeting #121			R1-2504601
St. Julian's, Malta, May 19th – 23rd, 2025
Source:	CEWiT
Title:	Discussion on multiple access, scheduling and timing aspects for Ambient IoT
Agenda Item:	9.4.4
Document for:	Discussion and Decision

Conclusion
In this document we discussed multiple access, scheduling related, timing relationships and any other L1 procedural aspects for Ambient IoT. The following proposals are made: 
Observation 1: Preamble should be differentiable from the PRDCH/PDRCH. 
Proposal 1: Following options are supported for differentiating the preamble from the PRDCH/PDRCH: 
Preamble followed by a long low voltage or guard time
Preamble followed by a TR2D_R2D_min for PRDCH and TD2R_D2R_min for PDRCH.
Observation 2: Regarding the options for determining the time interval between a R2D transmission and the corresponding D2R transmission following it, 
D2R transmission corresponding to R2D transmission within [TR2D_min, TR2D_max] is the baseline.
Option 2 can be used if the D2R transmission timing is indicated by the reader in the R2D transmission.
Option 2 can be used for contention free access.
 Option 1 can be used for contention-based access. 
Option 2 is more feasible for TDMA of multiple D2R transmissions scheduled by R2D transmission. 

Proposal 2: For the time interval between an R2D transmission and the corresponding D2R transmission following it, both option 1 and option 2 are supported.
Proposal 3: In case of option 2, the scheduling for D2R transmission within [TR2D_min, TR2D_max] is supported.

Proposal 4: For D2R scheduling, the following information potentially is explicitly indicated to the device via corresponding PRDCH:
Time domain resources
Frequency domain resources
MCS information
Chip duration
ID associated with device(s)
Repetitions
Midamble related information

Proposal 5: Support L1-control signaling along with high-layer based transmission of R2D control information for R2D reception and D2R scheduling.

Proposal 6: Consider the following table for R2D control information:

Proposal 7: For D2R, ACK/NACK feedback for PRDCH is supported.
Proposal 8: For TDMA of multiple Msg1 transmissions in response to a R2D transmission triggering random access: 
Based on the slotted aloha in a predefined RACH time window.
Proposal 9: For FDMA of multiple Msg1 transmissions in response to a R2D transmission triggering random access:     
Based on indicated resources in R2D transmission

Proposal 10: Support explicit indication for Toffset1 to determine the starting time of the first Msg1 time domain resource.
It can be indicated in the paging message

Proposal 11: Support explicit indication for Toffset2 to determine the starting time of the second Msg1 time domain resource.
Proposal 12: Convert the following working assumption into an agreement.
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
Proposal 13. Monitoring for Msg2 transmission using a RAR time window after the end of the RACH time window.
The time duration between the end of RACH time window and start of RAR time window is indicated by the TD2R_min.
Proposal 14: The starting time for monitoring Msg.2 should be common for all devices irrespective of the common or separate Msg.2 transmission.  
Proposal 15: Define the value of TD2R_max.
Proposal 16: The duration for monitoring the time window for Msg.2 transmission can be determined in two following ways:
Explicitly indicated through control information
Determined based on a predefined rule

Proposal 17: Define the values of TR2D_R2D_min and TD2R_D2R_min in RAN1 specification.
Proposal 18: Different options for determining the resources for Msg3 transmission are following below:
The time resources indicated in Msg2
Time resources derived from Msg1 transmission

Proposal 19: The predefined resources for Msg3 transmission are applied based on the following references.
End of time domain resource where the device received its own Msg2
End of the last of X time domain resource(s) determined for Msg2 receptions(s)
End of the R2D transmission triggering random access

Proposal 20: The frequency domain resource for Msg3 uses the same frequency domain resource as Msg1 for a device if the explicit indication for frequency domain resources for Msg3 is not provided in the Msg2.  
Proposal 21: Support case 1 and case 2 for Msg3 transmission.

3GPP TSG RAN WG1 Meeting#121		                          R1-2504618
Saint Julian, Malta, May 19th – 23rd, 2025

Source:	WILUS Inc.
Title:	Discussion on multiplexing/multiple access and timing relationships for Ambient IoT
Agenda item:	9.4.4
Document for:	Discussion/Decision

Conclusion
In this contribution, we discussed D2R multiplexing/multiple access and timing relationships for Ambient IoT and summarize our views as the following:
Proposal 1: Further discuss the Common-Msg2 and FDMed Msg3 transmission cases when TDMA (X=2) and FDMA are supported in Msg1 transmission.
Proposal 2: Support one of the following definitions for Toffset1 for the first Msg1
Option 1: Toffset1=Max(A*chip_lengthR2D, B* chip_lengthD2R_R=1)
Option 2: Toffset1= A*chip_lengthR2D
Option 3: Toffset1= B* chip_lengthD2R_R=1
Proposal 3: Support one of the following definitions for Toffset2 for the second Msg1
Option 1: Toffset2=Max(C*chip_lengthR2D, D* chip_lengthD2R_R=1)
Option 2: Toffset2= C*chip_lengthR2D
Option 3: Toffset2= C* chip_lengthD2R_R=1
Proposal 4: Define TD2R_min and TD2R_max for Msg2 monitoring as follows: 
TD2R_min and TD2R_max are defined based on multiple of chip length for D2R transmission when R value is 1:
TD2R_min= D* chip_lengthD2R_R=1 
TD2R_max= E* chip_lengthD2R_R=1 
Reference point for both TD2R_min and TD2R_max are defined as follows:
Starts from Toffset2 when X=2
Starts from the end of Msg1 transmission when X=1
Proposal 5: Define Toffset_msg3 for Msg3 transmission as follows:
Toffset_msg3 is determined in the same manner as Toffset1 and may be set to the same value or different value
Reference point for Toffset_msg3 is the end of Msg2 (or the last Msg2)

3GPP TSG-RAN WG1 Meeting #121	          R1-2504821  
St. Julian’s, Malta 19 – 23 May, 2025
Agenda Item:	9.4.4
Title:	FL summary#4 on other aspects for Rel-19 Ambient IoT 
Source:	Moderator (vivo)
Document for:	Discussion, Decision

Conclusion 3.1: 
For CFRA and for a new R2D message other than the paging message for A-IoT device determining Msg1 resources, it is up to RAN2 to decide whether and how to support TDMA of X>1 and/or FDMA of Y>1 time-frequency resources for Msg1 transmissions.    

Round 2
FL2 Proposed conclusion 3.1a
For CFRA, 
RAN1 assumes X=1 and Y=1 in the paging message for A-IoT device determining Msg1 resources. 
It is up to RAN2 to decide signaling details for the case of X=2 and/or Y>1 time-frequency resources for Msg1 transmissions if multiple devices are scheduled in CFRA.


FL2 Proposed conclusion 3.1b
For a new R2D message other than the paging message for A-IoT device determining Msg1 resources, down-select from the following:
Alt.1: RAN1 does not see the need to change X and Y value by the new R2D message
Alt.2: it is up to RAN2 to decide whether and how to change X and Y value by the new R2D message

Starting time of time domain resource for Msg1 and Msg3/D2R

For Msg1 transmission  

For X=1 or X=2, the starting time for the first Msg1 time domain resource from the device perspective 
Companies’ views on the “FFS Toffset1 is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Option 1: Predefined in the spec with fixed value(s): [5], [6], [9], [13], [18?], [23], [31]
[5], [23] Predefined as one fixed value
[5]: i.e., 30us; 
[6] Up to RAN4 to determine the exact value
[9], [13] Predefined and account for the worst case, up to 0.26ms is needed 
[4], [31] Different values of Toffset1 are predefined for the Msg.1 with FEC and without FEC.  
Option 2: Predefined equation to derive the , where the equation is based on the  and  for the scheduled D2R transmission [1], [3], [10], [16], [20], [30], [32], [33], [36]
[1], [3], [10], [30]: 
[3], [10], [30] proposed a=[4]; 
[3], [10], [20] proposed b=[20] and [30] proposed b=[10]  
[3]: t equals to [4] us for FEC disabled and [12] us for FEC enabled.
[10]: t equals to 0 for FEC disabled; [0.5]ms for FEC enabled
[30]: t equals to 0 if CRC is not attached to at the end or CRC can be pre-calculated; Otherwise,  with sampling rate 
[20]: MAX(CAP duration, 20TD2R,chip)
[16], [36]: predefined in the spec in terms of a number of chips (i.e., based on the M value of the triggering R2D transmission)
In addition, [10], [30], [33] proposed to clarify for FDMA of Msg1 case, the D2R chip length should be “a reference D2R chip length” or “the D2R chip length corresponding to R=1” or “the D2R chip length corresponding to the smallest R among the FDMA of Msg1s” to align the starting time for Msg1 transmission
Option 3: Indicated explicitly by the R2D transmission triggering random access [2], [7], [8], [12], [15], [21], [22], [24], [28], [34]
Predefine a list of candidate values (absolute time or time unit level indication) and the reader explicitly indicates one of the value
[7]: Following options can be considered to determine the value of Toffset1
Option 1: Define Toffset1 as a number of slots with the Candidate values: {1, 2, 3, 4}.
Option 2: Define Toffset1 as an absolute time expressed in tenths of one millisecond with the  candidate values: {0.2ms, 0.4ms, 0.6ms, 0.8ms}.
Option 3: Define Toffset1 as a number of equivalent D2R symbols with the Candidate values: {3, 6, 9, 12}.
 About the impact of FEC impact for Msg1 transmission, 
[3]: additional time margin t=[4]us for FEC disabled and [12]us for FEC enabled
[5]: FEC has no impact here. Because before receiving paging, device can pre-generate the random ID and pre-calculate the CRC and performs coding. Thus, when FEC is used, the processing time can still be the same as no FEC case, i.e., 30us.
[30]: For Msg1/Msg3/D2R feedback, apply TBS restriction of [up to 12bytes] or use precalculated CRC, .
About the impact of “the end of R2D transmission triggering random access” ,
[5], [10]: If the end for timeline determination refers to the “start of padding”, additional time needs to be added; if the end for timeline determination refers to the “end of padding”, no additional time needs to be added.
[30]:  is counted from the end of the last bit of PRDCH (before the start of the padding) till the start of D2R preamble of corresponding D2R transmission.  
Round 1
FL1 Proposal 3.2.1-1
Select one option from the following 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.
Option 1: Toffset1 is predefined in the spec as one fixed value of [30]us  
FFS whether/how additional time needs to be added when FEC is used
Note: If the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1. 
Option 2: Toffset1 is derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission triggering random access  
+t1, where a=[4], b=[20] and t1≥0   
FFS t1 considering at least the FEC impact, if applicable, and/or R2D padding impact if the end of the R2D transmission is defined as before the start of padding
Option 3: Toffset1 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values 
FFS the set of predefined values     

From FL: 
For option2, some companies suggested clarifying the D2R chip duration for FDMA. My thinking is we can use the same interpretation as that for small frequency shifts in FDMA once agreed in AI 942.
About the FEC impact for Msg1, Msg3 and other D2R data transmissions, separate proposal is made in FL1 Proposal 3.2.3-3. 

Round 2
Following is agreed on Monday online
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.

Based on the online discussions, following questions are asked.
FL2 Question 3.2.1-1a
For CBRA, what is your preferred way on determination of the smallest value for Toffset1?
Option 1: RAN1 defines the smallest value is 30us for Toffset1 and RAN4 can revisit it if they have concern.
Option 2: Up to RAN4 to decide the smallest value for Toffset1. 


FL2 Question 3.2.1-1b
For CBRA, in addition to the smallest value of Toffset1, are there any additional value(s) needed?
If Yes, what is/are the additional value(s) and how to use it?


For X=2, the starting time for the second Msg1 time domain resource from the device perspective
Most companies proposed to confirm the working assumption. In addition, companies’ views on the “FFS Toffset2 is predefined in the spec or derived by a rule or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Toffset2 is predefined in the spec: [14], [34?]
[14]: A set of Toffset2 values corresponds to the data rate are specified for the device. The appropriate value is selected for the second Msg1 transmission according to the indicated Msg1 data rate.
Toffset2 is derived by a rule based on the duration of the 1st Msg1 time domain resource and the gap between the two time domain resource considering the SFO impact: [1], [3], [6], [7], [10], [12], [13], [16?], [18], [23], [30], [31], [36] 
[6], [7], [12], [13], [16?], [20], [28], [30], [31], [36]: The value of Toffset2 can be implicitly derived as+Tgap, where Tgap = (Toffset1+TMsg1)×SFO×2, Tmsg1 is the duration of Msg.1 transmission length determined by 16-bit payload, 6-bit CRC, D2R chip length, FEC, repetition if applied and amble related parameter(s).
From FL: from above, assuming SFO=10%, Toffset2 = Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO  (equation 1), the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) (equation 2), combine equation 1 and equation 2, the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) = (Toffset1 + Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO) ×(1-SFO)  = 1.08 ×(Toffset1 + Tmsg1), which overlaps with the end of the first time domain resource with a slow clock given by (1+SFO)×(Toffset1 + Tmsg1) = 1.1 ×(Toffset1 + Tmsg1)
 
[2], [3], [10], [18]: Toffset2 should be set to prevent the second time domain resource for Msg1 transmission from device with fast clock from colliding with the first time domain resource for Msg1 transmission from device with slow clock at the reader side. Hence,  and by simplify it, , where te is 10% device clock error as defined in RAN4 
Toffset2 is indicated explicitly by the R2D transmission triggering random access: [2], [4], [5], [8], [9], [15], [22], [24], [32], [34]
[5]: Toffset2 is indicated explicitly, and the value set is {60, 90, 120, 180, 240, 300, 360, 420}us
[9]: 9 or 10 bits based on number of bits after FEC (if FEC is applied) and repetition (if repetition is applied) can be used for Toffset2 indication since the time duration of Toffset2 is likely to be less than 100ms.  
Round 3
For Toffset1
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.

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

About the impacts from the R2D padding and FEC, it can be discussed later. Let’s first focus only on the R2D chip length, D2R chip length or D2R bit length. After the predefined values are defined, then  
For R2D padding, if the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1. 
For FEC, if it is used, additional either fixed time or TBS-based time may need to be added.  

, the potential range is (2666.6, 1333.4, 666.6, 333.4, 166.6, 133.32, 83.4, 44.44, 41.6, 30, 22.24, 20.8, 13.8)us

It is unclear how the weight factors are selected for the RFID; it is also unclear whether 30us is sufficient for all R2D and D2R chip duration. 

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.


FL3 Question 3.2.1-1c
If FEC is not used, without considering the R2D padding impact,
If D2R chip length is is {0.69, 1.04, 2.08, 4.17}us, what is the predefined value set?
If D2R chip length is is {8.33, 16.67, 33.33}us, what is the predefined value set?
If D2R chip length is {66.67, 133.33}us, what is the predefined value set?
For FDMA case, the D2R chip length is a reference D2R chip length  corresponding to R = 1, the actual D2R chip duration  = /R.
Note: if the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1 


For Toffse3
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.

FL3 Question 3.2.1-1d
If FEC is not used, without considering the R2D padding impact, whether the same or different value set as for Toffset 1 is used for Toffset3?
If your answer is No, what are the value set for Toffset3?


For Toffset4
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. 
FL3 Question 3.2.1-1e
If FEC is not used, without considering the R2D padding impact, whether the same or different value set as for Toffset 1 is used for Toffset3?
If your answer is No, what are the value set for Toffset4?

FEC impacts
FL3 Proposal 3.2.3-3a
For Msg1 transmission, the processing time at device side is the same regardless of the use of FEC.

FL3 Proposal 3.2.3-3b
For Msg3 transmission, the processing time at device side is 
Opt.1: the same regardless of the use of FEC.
Opt.2: additional time like [70]us is added

FL3 Proposal 3.2.3-3c
For D2R data transmission except for Msg1, Msg3 and the 1st D2R transmission for CFRA, when FEC is used, select one option from the following
Option 1: Add extra processing time TFEC at device side based on the D2R TBS compared to the case when FEC is not used, e.g.,  
TFEC = with reference sampling rate , e.g., 1.92MHz    

Option 2: Add a fixed extra time TFEC at device side regardless of the D2R TBS compared to the case when FEC is not used
The fixed time TFEC is down-selected among [500, 600, 700, 800]us 

Option 3: Add extra processing time TFEC at device side based on the D2R TBS compared to the case when FEC is not used
TFEC = [x]us for TBS<=16 bytes
TFEC = [y]us for 16 bytes 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
QC, HW, OPPO, Ericsson, Spreadtrum, ZTE, xiaomi 
Opt2: same as when FEC is not used + TFEC, where TFEC = X, 
DCM, CMCC, Futurewei
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 + 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
Panasonic, Samsung, CMCC, NEC

==
FL’s note (to be removed)
X=166.6us, assume clock speed for CRC calculation is 0.72MHz (actual 178us)
X=133.3us, assume clock speed for CRC calculation is 1.28 (actual 100us) or 1.44MHz (actual 89us) or 1.92MHz (actual 65us)
FL4 Question 3.2.2-1b
For Toffset3, 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

We need to down-select from the options below, please indicate your preferred option and the TFEC value. 
If you prefer option 3, please indicate whether TFEC should be added for the following
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]


We also need to discuss the predefined value(s) 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, from the device perspective. The proposal is formulated in the similar way as we agreed for Toffset3.
FL4 Proposal 3.2.3-1b
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

When FEC is used, down-select from the options below
Opt1: same as when FEC is not used + TFEC, where
TFEC = 2X for TBS <=32bytes
TFEC = 4X for 32bytes1 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

3GPP TSG-RAN WG1 Meeting #121	          R1-2504822  
St. Julian’s, Malta 19 – 23 May, 2025
Agenda Item:	9.4.4
Title:	FL summary#5 on other aspects for Rel-19 Ambient IoT 
Source:	Moderator (vivo)
Document for:	Discussion, Decision

Conclusion 3.1: 
For CFRA and for a new R2D message other than the paging message for A-IoT device determining Msg1 resources, it is up to RAN2 to decide whether and how to support TDMA of X>1 and/or FDMA of Y>1 time-frequency resources for Msg1 transmissions.    

Round 2
FL2 Proposed conclusion 3.1a
For CFRA, 
RAN1 assumes X=1 and Y=1 in the paging message for A-IoT device determining Msg1 resources. 
It is up to RAN2 to decide signaling details for the case of X=2 and/or Y>1 time-frequency resources for Msg1 transmissions if multiple devices are scheduled in CFRA.


FL2 Proposed conclusion 3.1b
For a new R2D message other than the paging message for A-IoT device determining Msg1 resources, down-select from the following:
Alt.1: RAN1 does not see the need to change X and Y value by the new R2D message
Alt.2: it is up to RAN2 to decide whether and how to change X and Y value by the new R2D message

Starting time of time domain resource for Msg1 and Msg3/D2R

For Msg1 transmission  

For X=1 or X=2, the starting time for the first Msg1 time domain resource from the device perspective 
Companies’ views on the “FFS Toffset1 is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Option 1: Predefined in the spec with fixed value(s): [5], [6], [9], [13], [18?], [23], [31]
[5], [23] Predefined as one fixed value
[5]: i.e., 30us; 
[6] Up to RAN4 to determine the exact value
[9], [13] Predefined and account for the worst case, up to 0.26ms is needed 
[4], [31] Different values of Toffset1 are predefined for the Msg.1 with FEC and without FEC.  
Option 2: Predefined equation to derive the , where the equation is based on the  and  for the scheduled D2R transmission [1], [3], [10], [16], [20], [30], [32], [33], [36]
[1], [3], [10], [30]: 
[3], [10], [30] proposed a=[4]; 
[3], [10], [20] proposed b=[20] and [30] proposed b=[10]  
[3]: t equals to [4] us for FEC disabled and [12] us for FEC enabled.
[10]: t equals to 0 for FEC disabled; [0.5]ms for FEC enabled
[30]: t equals to 0 if CRC is not attached to at the end or CRC can be pre-calculated; Otherwise,  with sampling rate 
[20]: MAX(CAP duration, 20TD2R,chip)
[16], [36]: predefined in the spec in terms of a number of chips (i.e., based on the M value of the triggering R2D transmission)
In addition, [10], [30], [33] proposed to clarify for FDMA of Msg1 case, the D2R chip length should be “a reference D2R chip length” or “the D2R chip length corresponding to R=1” or “the D2R chip length corresponding to the smallest R among the FDMA of Msg1s” to align the starting time for Msg1 transmission
Option 3: Indicated explicitly by the R2D transmission triggering random access [2], [7], [8], [12], [15], [21], [22], [24], [28], [34]
Predefine a list of candidate values (absolute time or time unit level indication) and the reader explicitly indicates one of the value
[7]: Following options can be considered to determine the value of Toffset1
Option 1: Define Toffset1 as a number of slots with the Candidate values: {1, 2, 3, 4}.
Option 2: Define Toffset1 as an absolute time expressed in tenths of one millisecond with the  candidate values: {0.2ms, 0.4ms, 0.6ms, 0.8ms}.
Option 3: Define Toffset1 as a number of equivalent D2R symbols with the Candidate values: {3, 6, 9, 12}.
 About the impact of FEC impact for Msg1 transmission, 
[3]: additional time margin t=[4]us for FEC disabled and [12]us for FEC enabled
[5]: FEC has no impact here. Because before receiving paging, device can pre-generate the random ID and pre-calculate the CRC and performs coding. Thus, when FEC is used, the processing time can still be the same as no FEC case, i.e., 30us.
[30]: For Msg1/Msg3/D2R feedback, apply TBS restriction of [up to 12bytes] or use precalculated CRC, .
About the impact of “the end of R2D transmission triggering random access” ,
[5], [10]: If the end for timeline determination refers to the “start of padding”, additional time needs to be added; if the end for timeline determination refers to the “end of padding”, no additional time needs to be added.
[30]:  is counted from the end of the last bit of PRDCH (before the start of the padding) till the start of D2R preamble of corresponding D2R transmission.  
Round 1
FL1 Proposal 3.2.1-1
Select one option from the following 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.
Option 1: Toffset1 is predefined in the spec as one fixed value of [30]us  
FFS whether/how additional time needs to be added when FEC is used
Note: If the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1. 
Option 2: Toffset1 is derived based on the R2D chip duration  and D2R chip duration  indicated in the R2D transmission triggering random access  
+t1, where a=[4], b=[20] and t1≥0   
FFS t1 considering at least the FEC impact, if applicable, and/or R2D padding impact if the end of the R2D transmission is defined as before the start of padding
Option 3: Toffset1 is indicated explicitly in the R2D transmission triggering random access from a set of predefined values 
FFS the set of predefined values     

From FL: 
For option2, some companies suggested clarifying the D2R chip duration for FDMA. My thinking is we can use the same interpretation as that for small frequency shifts in FDMA once agreed in AI 942.
About the FEC impact for Msg1, Msg3 and other D2R data transmissions, separate proposal is made in FL1 Proposal 3.2.3-3. 

Round 2
Following is agreed on Monday online
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.

Based on the online discussions, following questions are asked.
FL2 Question 3.2.1-1a
For CBRA, what is your preferred way on determination of the smallest value for Toffset1?
Option 1: RAN1 defines the smallest value is 30us for Toffset1 and RAN4 can revisit it if they have concern.
Option 2: Up to RAN4 to decide the smallest value for Toffset1. 


FL2 Question 3.2.1-1b
For CBRA, in addition to the smallest value of Toffset1, are there any additional value(s) needed?
If Yes, what is/are the additional value(s) and how to use it?


For X=2, the starting time for the second Msg1 time domain resource from the device perspective
Most companies proposed to confirm the working assumption. In addition, companies’ views on the “FFS Toffset2 is predefined in the spec or derived by a rule or indicated implicitly or explicitly by the R2D transmission triggering random access” are summarized as below:
Toffset2 is predefined in the spec: [14], [34?]
[14]: A set of Toffset2 values corresponds to the data rate are specified for the device. The appropriate value is selected for the second Msg1 transmission according to the indicated Msg1 data rate.
Toffset2 is derived by a rule based on the duration of the 1st Msg1 time domain resource and the gap between the two time domain resource considering the SFO impact: [1], [3], [6], [7], [10], [12], [13], [16?], [18], [23], [30], [31], [36] 
[6], [7], [12], [13], [16?], [20], [28], [30], [31], [36]: The value of Toffset2 can be implicitly derived as+Tgap, where Tgap = (Toffset1+TMsg1)×SFO×2, Tmsg1 is the duration of Msg.1 transmission length determined by 16-bit payload, 6-bit CRC, D2R chip length, FEC, repetition if applied and amble related parameter(s).
From FL: from above, assuming SFO=10%, Toffset2 = Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO  (equation 1), the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) (equation 2), combine equation 1 and equation 2, the start of the second time domain resource with fast clock is (Toffset1 + Toffset2) * (1-SFO) = (Toffset1 + Tmsg1 + 2 × (Toffset1 + Tmsg1) × SFO) ×(1-SFO)  = 1.08 ×(Toffset1 + Tmsg1), which overlaps with the end of the first time domain resource with a slow clock given by (1+SFO)×(Toffset1 + Tmsg1) = 1.1 ×(Toffset1 + Tmsg1)
 
[2], [3], [10], [18]: Toffset2 should be set to prevent the second time domain resource for Msg1 transmission from device with fast clock from colliding with the first time domain resource for Msg1 transmission from device with slow clock at the reader side. Hence,  and by simplify it, , where te is 10% device clock error as defined in RAN4 
Toffset2 is indicated explicitly by the R2D transmission triggering random access: [2], [4], [5], [8], [9], [15], [22], [24], [32], [34]
[5]: Toffset2 is indicated explicitly, and the value set is {60, 90, 120, 180, 240, 300, 360, 420}us
[9]: 9 or 10 bits based on number of bits after FEC (if FEC is applied) and repetition (if repetition is applied) can be used for Toffset2 indication since the time duration of Toffset2 is likely to be less than 100ms.  
Round 3
For Toffset1
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.

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

About the impacts from the R2D padding and FEC, it can be discussed later. Let’s first focus only on the R2D chip length, D2R chip length or D2R bit length. After the predefined values are defined, then  
For R2D padding, if the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1. 
For FEC, if it is used, additional either fixed time or TBS-based time may need to be added.  

, the potential range is (2666.6, 1333.4, 666.6, 333.4, 166.6, 133.32, 83.4, 44.44, 41.6, 30, 22.24, 20.8, 13.8)us

It is unclear how the weight factors are selected for the RFID; it is also unclear whether 30us is sufficient for all R2D and D2R chip duration. 

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.


FL3 Question 3.2.1-1c
If FEC is not used, without considering the R2D padding impact,
If D2R chip length is is {0.69, 1.04, 2.08, 4.17}us, what is the predefined value set?
If D2R chip length is is {8.33, 16.67, 33.33}us, what is the predefined value set?
If D2R chip length is {66.67, 133.33}us, what is the predefined value set?
For FDMA case, the D2R chip length is a reference D2R chip length  corresponding to R = 1, the actual D2R chip duration  = /R.
Note: if the end of the R2D transmission is defined as before the start of padding, additional time needs to be added to Toffset1 


For Toffse3
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.

FL3 Question 3.2.1-1d
If FEC is not used, without considering the R2D padding impact, whether the same or different value set as for Toffset 1 is used for Toffset3?
If your answer is No, what are the value set for Toffset3?


For Toffset4
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. 
FL3 Question 3.2.1-1e
If FEC is not used, without considering the R2D padding impact, whether the same or different value set as for Toffset 1 is used for Toffset3?
If your answer is No, what are the value set for Toffset4?

FEC impacts
FL3 Proposal 3.2.3-3a
For Msg1 transmission, the processing time at device side is the same regardless of the use of FEC.

FL3 Proposal 3.2.3-3b
For Msg3 transmission, the processing time at device side is 
Opt.1: the same regardless of the use of FEC.
Opt.2: additional time like [70]us is added

FL3 Proposal 3.2.3-3c
For D2R data transmission except for Msg1, Msg3 and the 1st D2R transmission for CFRA, when FEC is used, select one option from the following
Option 1: Add extra processing time TFEC at device side based on the D2R TBS compared to the case when FEC is not used, e.g.,  
TFEC = with reference sampling rate , e.g., 1.92MHz    

Option 2: Add a fixed extra time TFEC at device side regardless of the D2R TBS compared to the case when FEC is not used
The fixed time TFEC is down-selected among [500, 600, 700, 800]us 

Option 3: Add extra processing time TFEC at device side based on the D2R TBS compared to the case when FEC is not used
TFEC = [x]us for TBS<=16 bytes
TFEC = [y]us for 16 bytes 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
QC, HW, OPPO, Ericsson, Spreadtrum, ZTE, xiaomi 
Opt2: same as when FEC is not used + TFEC, where TFEC = X, 
DCM, CMCC, Futurewei
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 + 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
Panasonic, Samsung, CMCC, NEC

==
FL’s note (to be removed)
X=166.6us, assume clock speed for CRC calculation is 0.72MHz (actual 178us)
X=133.3us, assume clock speed for CRC calculation is 1.28 (actual 100us) or 1.44MHz (actual 89us) or 1.92MHz (actual 65us)
FL4 Question 3.2.2-1b
For Toffset3, 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

We need to down-select from the options below, please indicate your preferred option and the TFEC value. 
If you prefer option 3, please indicate whether TFEC should be added for the following
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]


We also need to discuss the predefined value(s) 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, from the device perspective. The proposal is formulated in the similar way as we agreed for Toffset3.
FL4 Proposal 3.2.3-1b
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

When FEC is used, down-select from the options below
Opt1: same as when FEC is not used + TFEC, where
TFEC = 2X for TBS <=32bytes
TFEC = 4X for 32bytes