3GPP TSG RAN WG1 Meeting #120bis	R1-2501709
Wuhan, China, April 7 – 11, 2025
Agenda Item:	9.4.4
Source:	Futurewei
Title:	Discussion on multiple access, scheduling and timing aspects for A-IoT
Document for:	Discussion and Decision 

Conclusion
The following observations / proposals were discussed in this contribution.
Timing
Proposal 1. For A-IoT devices, support the timing TR2D_min with the following revision:
Minimum Time between the end of a R2D transmission and the start of the corresponding D2R transmission following it
Proposal 2. For A-IoT devices, support the timing TR2D_max with the following revision:
Define a maximum time TR2D_max between the end of a R2D transmission and the start of the corresponding D2R transmission following it, so that the device starts a transmits D2R transmission within [TR2D_min, TR2D_max].
Proposal 3. For A-IoT devices, support the timing TD2R_min with the following revision:
Minimum Time between the end of a D2R transmission and the start of the corresponding R2D transmission following it.
Proposal 4. For A-IoT devices, support the timing TD2R_max with the following description:
Maximum time between the end of a D2R transmission and the start of the corresponding R2D transmission following it, so that the R2D transmission timing is expected to be within [TD2R_min, TD2R_max] when the corresponding R2D transmission is the expected A-IoT Msg2 response to A-IoT Msg1 for the A-IoT device 
Msg1 / Msg2
Proposal 5: For a A-IoT device supporting X>1 TDMA, support 4 time domain resources.
Observation 1: The maximum number of Msg1 responses that can be carried within a PRDCH for Msg2 is a function of the maximum TBS for reliable reception of Msg2.
Proposal 6: For TDMA, a device that transmitted A-IoT Msg1 monitors a Msg2 transmission that corresponds to a A-IoT Msg1 from the device. If the device does not receive the Msg2 transmission by the next paging message, the device considers the A-IoT Msg1 transmission failed.
Proposal 7: For the agreements for frequency domain resources for Msg3 transmission, drop the FFS.

3GPP TSG-RAN WG1 Meeting #120bis	R1-2501722
Wuhan, China, April 7th – April 11th, 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	Choosing different D2R chip lengths and/or R allow A-IoT devices to shift their transmission frequencies.
Observation 2	Transmission bandwidth and the data rate of the A-IoT devices get impacted based on the D2R chip length and repetition factor R, where R is the chip-level repetition in case of line coding and number of square wave periods when SFS is implemented without line coding.
Observation 3	While scheduling FDMA resources, one of the following approaches can be supported:
Approach 1: Keeping the data rate the same between simultaneously FDMA’ed devices thereby resulting in scheduling frequency resources with the same transmission bandwidth
Approach 2: Support variable data rates as well where FDMA scheduling requires supporting resources with variable BWs
Observation 4	Different D2R messages along with whether variable BWs support might be beneficial for devices participating within the same access round is noted below.

Observation 5	For scheduled FDMA resources to support the same bandwidth, the devices implementing SFS need to keep the product of  to be constant
Observation 6	Supporting X>1 needs to consider two additional design factors.
1.	Devices having to keep track of a counter within the access occasion
2.	Guard bands required between messages to prevent timing overlaps
Observation 7	Overall benefits from X>1 seems limited considering the additional design factors that need to be considered. The inventory time seems to be worser with higher X values when the SFO is 10^5 ppm.
Observation 8	Having a TR2D_min time allows defining a minimum time that the device might take for processing an R2D reception and generating its own D2R response to it. Defining a TR2D_min value within the standard allows setting a minimal processing capability that the A-IoT devices need to support.
Observation 9	Defining TR2D_max in the standard is not necessary since the reader, while scheduling, can always assume guard spaces in time to compensate for SFO. From RAN1 perspective, defining this value in the standard might reduce the resource configuration flexibility for the reader.
Observation 10	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 11	Defining TD2R_max might enable the devices to monitor responses within a certain duration, thereby handling error cases using timeouts. However, pre-defining this value in the standard is infeasible since number of PRDCH transmissions as part of Msg2 is completely dependent on the success/failure within Msg1 occasions, reader’s configurability and other considerations like coverage. Handling timeouts can instead rely on dynamic configuration of TD2R_max using L1 control signalling.
Observation 12	Early identification/termination function of PRDCH is possible for the device only if the R2D control information carrying the message type and/or device ID is self-decodable and is transmitted as a separate PRDCH
Observation 13	Having postamble is not particularly beneficial in reducing blind decodes of R2D messages
Observation 14	R2D control information is beneficial not only to handle the reception monitoring window as stated in Observation 11, but is also useful to reduce the number of blind decodes.
Observation 15	Supporting option 3 where a codepoint based mapping corresponds to one or more R values for FDMA leads to a possibility of creating FDMA resources which have different transmission capabilities as explained in observation 5.
Observation 16	R2D control includes both higher layer control as well as L1 control parameters.
Observation 17	Device (un)availability via Direction 1 does not require any specification update.

Based on the discussion in the previous sections we propose the following:
Proposal 1	For Msg1, it is assumed that all devices transmit with same TBS. Therefore, Msg1 resources need to support resources with the same bandwidth/Tb.
Proposal 2	For Msg3 and further command messages, TBS of different sizes might be supported. Therefore, RAN1 to discuss whether or not to support variable BWs (different Tb) in these cases.
Proposal 3	FDMA resources scheduled in paging message for a set of devices should include resources supporting the same bandwidth and same data rate.
Proposal 4	Scheduling FDMA for Msg1 involves the reader providing implicitly or explicitly a set of tuples containing (D2R chip duration, R) such that their product   remains constant for all the scheduled resources.
Proposal 5	Resource allocation for Msg1 needs to consider only X=1.
Proposal 6	Number of Msg1 responses within a PRDCH for Msg2 should be reader-configurable but within the maximum supported TBS for R2D.
Proposal 7	From RAN1 perspective, there is no need to specify maximum number of Msg1 responses that can be carried within a PRDCH. It is enough to specify the maximum supported TBS for R2D.
Proposal 8	Support separate start time for Msg2 monitoring, at least for the case where there are multiple-Msg2 PRDCH transmissions corresponding to multiple Msg1 responses.
Proposal 9	To enable separate start times for each Msg2 PRDCH transmission, support R2D L1 control information before Msg2 PRDCH transmissions. The L1 control information can contain the individual start times (or offsets) for Msg2 transmissions corresponding to each Msg1.
Proposal 10	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 11	A time monitoring window for monitoring L1 control information preceding Msg2 transmissions may be specified instead of a Msg2 monitoring window
Proposal 12	FDMA resource scheduling for Msg3 within the PRDCH for Msg2 transmission contains at least the chip-level duration and repetition combination for one or multiple devices.
Proposal 13	For supporting frequency domain resource for Msg3 transmission, do not support Option 1 where the frequency domain resource for Msg3 reuses the frequency domain resource for Msg1 for the same device
Proposal 14	Support only Way1 of non-interleaving Msg3 transmissions (e.g., Msg2-Msg2-Msg3-Msg3).
Proposal 15	The timing relations should be supported with the following considerations.

Proposal 16	Message type/command code is already agreed to be part of R2D message within the MAC header. This can be part of R2D control information, but from higher layer perspective than L1 perspective.
Proposal 17	End of identification for a PRDCH can be handled using Option (2) based on R2D control information.
Proposal 18	In addition to R2D control information, discuss whether postamble is beneficial to indicate the end of transmission when SFO is high
Proposal 19	The clock-acquisition part of the R2D time acquisition signal preceding the PRDCH is used to determine the OOK chip duration used for the following PRDCH transmission
Proposal 20	Choose from among option1 (bit map based corresponding to one R value) or option2 (codepoint based corresponding to one R value) at least for Msg1 FDMA scheduling
Proposal 21	Alternately, a codepoint specifying  can be specified to support SFS.
Proposal 22	Support option 1 where the [D2R chip duration]/[D2R information bit duration] is indicated in R2D control information from predefined a set of [D2R chip duration]/[D2R information bit duration] values
Proposal 23	[D2R chip duration]/[D2R information bit duration] can be indicated as an integer multiple/scaled versions of a reference unit time where this unit time can be defined as for example 1/15kHz, where 15kHz is the D2R transmission BW
Proposal 24	RAN1 will not discuss ACK/NACK as L1 D2R control information in Rel-19 A-IoT unless requested by RAN2
Proposal 25	Joint CRC is supported for higher layer control as well as data in a PRDCH transmission. Separate CRC is applicable only for L1 control information which is sent as a separate PRDCH transmission.
Proposal 26	A common L1 control signalling should be supported for scheduling R2D reception, at least for Msg2.
Proposal 27	L1 common control information should be send as a separate PRDCH transmission that precedes Msg2.
Proposal 28	The contents of L1 control signal should contain at least an indicator (for eg:  index to Msg1 transmission occasion) for the devices to see if its R2D response is present or not, and if present a monitoring window specifying where to monitor the R2D response.
Proposal 29	The following information may be carried as part of R2D control signalling for device-specific PDRCH scheduling like Msg3.
	Time domain resources
	MCS-like information- this includes FEC code rate
	 for SFS
	Bit-level Repetition
	Midamble- Number of midambles, Location of midamble (s) (if present)
Proposal 30	If Msg3 scheduling follows a RAR-like scheduling, above R2D control signalling parameters are carried in higher layer payload.
Proposal 31	FFS to discuss the behaviour of device-specific scheduling for messages after Msg3.

3GPP TSG RAN WG1 #120bis          		                                  R1-2501763
Wuhan, China, April 7th – 11th, 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 obervations and proposals are given below:
For TDMA of Msg1 transmissions, to improve access efficiency, any of the X-1 time intervals between X time-domain resources should be less than the time length T required by a R2D transmission that triggers random access. Whereas, when X≥3,  the time interval between the (X-1)th and the Xth time-domain resources exceeds the time length T at data rate of 5 Kbps.
If no preamble is detected in a time-domain resource, the reader can terminate this time-domain resource early for X=1. Whereas, for X>1, each of X time-domain resources (slots) must be reserved and cannot be terminated early, which leads to potential time wastage, especially for low D2R data rate.
The smaller the value of X, the more flexible the dynamic adjustment of Q value in Q-selection algorithm, allowing the reader to send the Q value more promptly to update the number of access resources (slots) for a paging round. 
Using X>1 can result in a larger timing error value for Msg1 transmissions from different devices compared to X=1, which affects the decoding performance of Msg1 at the reader side.
For low or medium data rates (less than or equal to 40 Kbps) in both R2D and D2R transmissions, using TDMA of Msg1 with X>1 does not provide any improvement in access efficiency compared to X=1.
In cases where the data rate does not exceed 80 kbps, TDMA of Msg1 with X>2 virtually provides no gain in access efficiency compared to that of X=2.
According to the Rel-19 study, Device 1 is expected to have the highest SFO and the lowest data rate and complexity among different device types, which is unfavorable for realizing the gain of TDMA for Msg1.
Since TDMA is not supported for Msg3 and the number of frequency-domain resources available in FDMA may not exceed 8 in the A-IoT system, the maximum number of Msg1 responses that a Msg2 can be carried within a Msg2 is 8.
For the transmissions of Msg2 and the corresponding Msg3, Way 1 (e.g., Msg2-Msg2-Msg3-Msg3) results in larger random access latency compared to Way 2 (e.g., Msg2-Msg3-Msg2-Msg3), regardless of whether FDMA is used for Msg3 or not. 
The total duration of Msg2 transmission(s) and the corresponding monitoring window are variable and unpredictable. A device can determine whether access is successful based on the received commands.
RAN2 aims to design a paging message contains one identifier or no identifier.
TDMA of Msg1 transmissions is not considered in Rel-19 A-IoT.
TDMA of multiple Msg3 transmissions in response to a Msg2 is not supported for A-IoT random access.
For FDMA of Msg1 transmissions, the available frequency domain resource set needs to be specified and the relevant indication is transmitted in the R2D transmission, e.g., the paging message.
The duration and potential configurations (such as TBS, coding rate, chip length, the number of repetitions) for Msg1 should be consistent across FDMed multiple Msg1 transmissions.
For the transmissions of Msg2 and the corresponding Msg3, Way 1 (Non-interleaving Msg3 transmissions, e.g., Msg2-Msg2-Msg3-Msg3) is not considered.
The starting time for Msg2 monitoring is the time TD2R_min after the end of the Msg1 that the device transmits. And the Msg2 monitoring window is not needed.
For frequency-domain resource allocation for Msg3, Option 1 can be supported as a default if the PRDCH does not provide the indication.
The duration and potential configurations (such as TBS, coding rate, chip length, and number of repetitions) for Msg3 could be different across FDMed multiple Msg3 transmissions.
The time range [TR2D_min, TR2D_max] can be adopted to define the timing relationship from end of a R2D transmission to the beginning of the corresponding D2R transmission following it.
For the timing of D2R response to R2D, the device is required to transmit the D2R signal within [TR2D_min, TR2D_max] based on its own clock. 
The time  can be determined based on the R2D trigger and Msg1,  the time  can be determined based on Msg2 containing the maximum number of Msg1 responses and Msg3.
The values of  and  can derived from the following expressions:


Wherein, the R2D chip length and D2R chip length are the configured chip lengths for the R2D and D2R transmissions, respectively. The values of a1, b1, a2, b2, t1 and t2 can be further discussed. 
For the timing of R2D response to D2R, the maximum time TD2R_max is not needed.
For the timing of Msg2 response to Msg1, the device may assume a minimum time TD2R_min between the end of its Msg1 and the beginning of the nearest Msg2. TD2R_min is also applicable for the timing of other R2D response to D2R.
The value of  can be derived from  and the applicable values of c and  can be further discussed.
If two consecutive R2D transmissions are supported, a minimum time interval TR2D_R2D_min should be specified.
 should be less than  and can be derived based on .
The timing for consecutive two D2R transmissions from the same device is not considered until the application scenarios are clarified.
Clarify that ‘Time domain resources’ for D2R scheduling is TBS indication.
Clarify that ‘Frequency domain resources’ for D2R scheduling indicates the small frequency shift factor used for D2R scheduling.
For the indication of R values based on a predefined R set, Alt.3: indicating the interval or the number of R values, while the maximum R value is predefined, is preferred to reduce the indication overhead.
Clarify that ‘Chip duration’ for D2R scheduling indicates D2R chip duration corresponds to the chip duration of a predefined R value, for example R=1,2, to reduce indication overhead, at least for Msg 1.
Clarify that ‘MCS-like information’ includes joint indication of CC rate and repetition times.
Amble related information can include at least one of the following:
number of midamble .
P-value if Method#2 is used.
Length of ambles.
Note：
Method#1: Insert one midamble at the end of PDRCH, and uniformly insert (Q-1) midambles in addition to the preamble and the last midamble.
Method#2: Insert one midamble at the Pth-to-last bit position, and uniformly insert other midambles between the preamble and the last midamble.
For D2R scheduling, higher-layer signaling is used for indication of information to the device via corresponding PRDCH.
To sum up, Table 6 can be considered for D2R scheduling:
Table 6: D2R information field in R2D control information
How to convey the ID associated with devices can be determined by RAN2.
Message type indication which used to indicate whether the R2D signaling that is transmitted before Msg1 or after Msg1 can be considered for early termination.
To determine or derive the end of PRDCH transmission, 
using TBS indication in R2D control information, if packet size does not need CRC; 
otherwise, using postamble.
To sum up, Table 8 can be considered for R2D transmission:
Table 8: R2D information field in R2D control information

3GPP TSG RAN WG1 #120b	R1-2501779
Wuhan, China, April 7th - 11th, 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 1: Regarding TDMA for Msg1, support X in { 1, 2}. The value of X is indicated by the reader. 
Proposal 2: For D2R scheduling, time domain resources shall be indicated by signaling in the corresponding PRDCH. 
Observation 1: According to the WID, both TDMA and FDMA are supported for D2R. 
Proposal 3: For D2R scheduling, frequency domain resources shall be indicated by signaling in the corresponding PRDCH. 
Observation 2: 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 4: RAN1 to discuss whether for a given R2D transmission, “ID associated with device(s)” for R2D reception and for D2R scheduling is identical.
Proposal 5: For D2R scheduling, if multiple D2R “amble” configurations are supported and selection between them is up to the reader then amble configuration shall be indicated by signaling in the corresponding PRDCH. 
Proposal 6: D2R scheduling information is indicated by higher layer signaling.
Observation 3: The reader cannot wait until it receives a response D2R message after a transmission of R2D signal requiring the response from the device.
Proposal 7: RAN1 should define a maximum time between a R2D transmission and its corresponding D2R reception so that the reader can decide the failure of either R2D reception at the device or D2R reception at the reader.

3GPP TSG RAN WG1 #120bis		R1-2501809 
Wuhan, China, April 7th – 11th, 2025
Source:	vivo
Title:	Discussion on other aspects for Rel-19 Ambient IoT
Agenda Item:	9.4.4
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on other aspects including resource allocation for multiplexing/multiple access, scheduling information and timing relationships for A-IoT operation. The observations and proposals are summarized as follows.
For Multiplex/Multiple access
Observation 2.1-1: The number of required registers is influenced by data rate and maximum value of X. 
With 10 registers, the occupied ratio of total register is 20% assuming total register numbers is 50. The maximum time duration a device can count is about 0.53ms assuming 1.92MHz sampling rate. The achieved latency reduction gain compared to the case for TDMA of X=1 is:
22.5% for 80Kbps D2R data rate for X=2 
32.3% for 160Kbps D2R data rate for X=3
With 11 registers, the occupied ratio of total register is only 22% and the maximum time duration a device can count is about 1.06ms. The achieved latency reduction gain compared to the case for TDMA of X=1 is:
19.4% for 40Kbps D2R data rate, X=2 
29.4% for 80Kbps D2R data rate, X=3
36.1% for 160Kbps D2R data rate, X=4
With 12 registers, the occupied ratio of total register is 24% and the maximum time duration a device can count is about 2.13ms. The achieved latency reduction gain compared to the case for TDMA of X=1 is:
15.1% for 20Kbps D2R data rate, X=2 
25.2% for 40Kbps D2R data rate, X=3
32.9% for 80Kbps D2R data rate, X=4
Observation 2.2-1: Even if TDMA of X>1 time domain access occasions for Msg1 that is scheduled by a R2D transmission triggering random access is supported, it is questionable that the device 1 can maintain a Msg2 monitoring window since the time length required for maintain a Msg2 monitoring window is much longer than the time length for TDMA of X>1 Msg1. 
Observation 2.2-2: 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 2.1-1: Either do not support X>1 or support X>1 of TDMed time domain access occasion(s) for Msg1 transmission scheduled by a R2D transmission triggering random access for all devices.
Do not support to leave to device implementation on supporting X>1. 
If X>1 is supported, it is necessary to define such maximum time duration e.g., T that device 1 can maintain/count as a requirement. 
Proposal 2.1-2: If X>1 is supported, support up to X=[2 or 3] access occasions in time domain for D2R transmission(s) for Msg1 that determined by a R2D transmission triggering random access, where each D2R transmission for Msg1 occurs in one time domain resource of the two time domain resource(s) in Rel-19.
Proposal 2.1-3: For X (X1) time domain resource(s) for D2R transmission(s) for Msg1 that determined by a R2D transmission triggering random access, 
the starting time TR2D is indicated by the control information in the R2D transmission, where TR2D  TR2D_min (i.e., Option 2)
No need to indicate the time length for PDRCH transmission. It is derived by the Msg1 payload size, i.e., 16bits, D2R chip duration, small frequency shift R, the number of repetitions and FEC if used.
Proposal 2.1-4: For indicating the frequency domain locations for FDMA of Y where Y1 access occasion for Msg1 transmission, following Option 2 and 3 can be down-selected considering R2D overhead and the flexibility for FDMed access occasion(s) indication. 
Option 2: One joint indication of Y and R, that the specification can define the association between the Y and R, based on the number of associations, the field length for the joint indication can be determined. 
Option 3: One indication field in the form of bitmap for the set of candidate R values only, e.g., {Ri}, where each Ri value is associated with one bit location, the bit set to 1 indicates that the Ri is used/present; the bit set to 0 indicates that the Ri is NOT used/absent for frequency domain resource allocation.  
Proposal 2.1-5: For TDMA and/or FDMA of multiple access occasions for D2R transmission(s), it is up to reader to reserve the sufficient gap between the adjacent D2R transmissions in the time and/or frequency domain due to residual SFO of the device.  
Proposal 2.2-1: 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 X*Y.

Proposal 2.2-2: Device 1 should monitor PRDCH for Msg2 transmission no later than the minimum time required for the device to switch from transmission to reception after it transmits Msg1.  
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. 
Proposal 2.3-1: If X>1 is supported and the maximum time duration e.g., T that device 1 can maintain/count as a requirement is defined, support Case 2; Otherwise, do not support Case 2. 
Case 2: FDMA of more than one D2R transmissions for Msg3 is scheduled by the consecutive TDMed PRDCH transmissions for Msg2
Proposal 2.3-2: Support Case 3: the non-consecutive TDMed D2R transmissions of Msg3, with an interleaved time sequence between Msg2 and Msg3.
Proposal 2.3-3: Do not support TDMA of multiple consecutive PDRCH for Msg3 transmissions scheduled by one common PRDCH or multiple separate PRDCH(s) for Msg2 transmission(s).
Proposal 2.3-4:
A PDRCH for Msg3 transmission is scheduled by R2D control information in a PRDCH for Msg2.
Only Option 2 is supported that is the frequency domain resource for Msg3 can be determined based on explicit indication in the PRDCH for Msg2 transmission for one or multiples devices.  

For Scheduling related aspects 
Proposal 3.1-1: For R2D, the clock-acquisition part of the R2D time acquisition signal preceding the PRDCH is used to determine the OOK chip duration used for the following PRDCH transmission.
Proposal 3.2-1: For Msg1 transmission, the following information is explicitly indicated to the device via corresponding PRDCH:
X time domain access occasion(s), where 1X[2]
The starting time for each time domain access occasion
D2R chip duration from predefined a set of D2R chip duration values
Y frequency domain access occasion(s), where 1Y[Ymax]
R related to small frequency shift
MCS-like information, including whether to use FEC and the number of repetitions 
Preamble and/or midamble related information
FFS joint or separate indication of some of the above information  
 
Proposal 3.2-2: For Msg3 and D2R data transmission, the following information is explicitly indicated to the device via corresponding PRDCH:
The starting time for D2R transmission 
D2R chip duration from predefined a set of D2R chip duration values
The payload size (i.e. TBS-like) for PDRCH transmission with variable size 
R related to small frequency shift
MCS-like information, including whether to use FEC and the number of repetitions 
Preamble and/or midamble related information

Proposal 3.2-3: For PDRCH payload size indication, following option 1 and 2 can be down-selected.
Opt.1: 7 bits for byte-level D2R payload size indication
Opt.2: X-bit (X<=7) codepoint based indication, where each codepoint indicates one size from 2x predefined D2R payload sizes.

Proposal 3.3-1: R2D control information for D2R scheduling is carried by higher-layer signaling with one CRC. 

 
For Timing relationships  
Proposal 4-1: It is necessary to define TR2D_min in the specification as the minimum time interval from the end of a R2D transmission to the start of the corresponding D2R transmission from device perspective based on its own clock. 
Device is not required to send the corresponding D2R transmission earlier than TR2D_min after it receives a R2D transmission based on its own clock.
Reader should be ready to receive the corresponding D2R transmission no later than TR2D_min * (1-SFO) after it transmits the R2D.    
Proposal 4-2: It is necessary to define TR2D_max in the specification as the maximum time interval from the end of a R2D transmission to the start of the corresponding D2R transmission from device perspective based on its own clock
Device should transmit before the expire of TR2D_max after it receives a R2D transmission based on its own clock
Reader may stop monitoring the D2R Tx in case the expected response is not received within TR2D_max * (1+SFO) after it transmits the R2D 

Proposal 4-3: It is necessary to define the TD2R_min as the minimum time between a D2R transmission and the corresponding R2D transmission following it from device perspective based on its own clock.
Device should be ready to receive the corresponding R2D transmission no later than TD2R_min after it transmits a D2R.   

Proposal 4-4: From a reader's perspective, defining TD2R_min in RAN1 may not be necessary. 
Proposal 4-5: It is not necessary to define TD2R_max in RAN1.

3GPP TSG RAN WG1#120bis                                                                R1-2501871
Wuhan, China, April 7 – 11, 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: Not only the feature of timing counting to support D2R TDMA needs register, but also other features such as segmentation, CP handling M1-1, etc, need registers as well. 
Observation 2: Supporting Msg1/3 TDMA can potentially reduce inventory time and then improve inventory efficiency.
Observation 3: From marketing perspective, A IoT System and A-IoT Device should have higher capabilities than RFID, thus supporting timing counting is an attractive feature.
Observation 4: If setting the maximum X equal to 2, the length of timing counting can be limited to a small range.
Observation 5: It would be feasible for a device to count the starting position for Msg2 monitoring, and the increased complexity would be acceptable.
Observation 6: Whether it is feasible for a device to count the ending time for Msg2 monitoring may depend on the length of Msg2 monitoring window, and depend on whether the increase in complexity caused by the need for long time counting is acceptable.
Observation 7: There are three possible multiple access situations (i.e., TDMA only, FDMA only and TDMA+FDMA) for a certain Msg1 transmission. If all three situations are supported, a unified resource allocation scheme is beneficial for simplifying design.

Proposals:
Proposal 1: For the first release of A-IoT, the complexity (e.g. Number of register) and the necessity should be carefully and comprehensively evaluated and compared for all features together. Treat differently for different features should be avoided.  
Proposal 2: Time counting for Device1 should be supported for the first release of A-IoT.
Proposal 3: The maximum number of multiple A-IoT Msg1 carried within a PRDCH for Msg2 transmission should no larger than 4.
Proposal 4: From device side, it is at least necessity to define starting position for Msg2 monitoring.
Proposal 5: From reader side, it is necessity to define both starting and ending position for Msg2 monitoring, which means the reader should transmit a/multiple PRDCH for Msg2 within a time range between starting and ending position for Msg2 monitoring.
Proposal 6:
For Msg2 in response to TDMA of X>1 (if supported) Msg1 transmissions initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponding to the A-IoT Msg1 transmitted by the device no earlier than TD2R_min after the end of the last of X time domain resource(s) for Msg1 transmission(s). 
FFS a device is expected to receive a PRDCH for Msg2 corresponding to the A-IoT Msg1 transmitted by the device no later than TD2R_max after the end of the last of X time domain resource(s) for Msg1 transmission(s). 
For Msg2 in response to TDMA of X=1 Msg1 transmission initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponds to the A-IoT Msg1 transmitted by the device no earlier than TD2R_min after the end of the time domain resource for Msg1 transmission.
FFS a device is expected to receive a PRDCH for Msg2 corresponds to the A-IoT Msg1 transmitted by the device no later than TD2R_max after the end of the time domain resource for Msg1 transmission.
Proposal 7: Support TDMA of X>1 and the maximum value of X is 2.
Proposal 8: For Msg1 resource allocation in TDMA, the time domain resource allocation (TDRA) across of the X resources for Msg1 should be same for the same service.
Proposal 9: For Msg1 resource allocation in TDMA and/or FDMA, the resource allocation information carried in the control information of R2D transmission triggering message, and the following options can be considered.
Option 1: R2D carries all necessary information (e.g., gap between resources, and length of one resource).
Option 2: R2D carries an index of the multiple pre-define sets of necessary information
Proposal 10: Device can randomly select one of the time and frequency domain resource among multiple resources for the Msg1.
Proposal 11: Support consecutive TDMed D2R transmissions for Msg3 from multiple devices in response to a PRDCH for Msg2 transmission corresponding to multiple Msg1 during access procedure.
Proposal 12: Support option 1 as a default if PRDCH does not provide the indication 
Proposal 13: For Msg3 time domain resource allocation, the following methods can be considered.
Alt.1: Time domain resource allocation information for Msg3 for is carried in Msg2.
Alt.1-1 Msg2 carries all necessary information (e.g., number of Msg3 resources, gap between resources, length of one resource, etc.).
Alt.1-2 Msg2 carries an index of the multiple pre-define sets of necessary information.
Proposal 14: TR2D_min and TR2D_max should be defined.
Proposal 15: TD2R_min and TD2R_max should be defined.
Proposal 16: For the time interval between a R2D transmission and the corresponding D2R transmission following it, the following option 1 is supported.
Option 1: Define a maximum time TR2D_max between a R2D transmission and the corresponding D2R transmission following it, so that the device transmits D2R transmission within [TR2D_min, TR2D_max].
Proposal 17: A common maximum time (TD2R_max) for different A-IoT devices is supported.
Proposal 18: For TDMA case that multiple Msg1 are transmitted within one slot, the minimum time TD2R_min should be between the end of the last time domain resource for Msg1 and start of the corresponding Msg2 transmission following it.
Proposal 19: Message type indication should be supported in R2D control information.
Proposal 20: “AS ID” discussed in RAN2 should be supported as the ID associated with device (s), and it should be carried in L1 control of R2D transmission for command. 
Proposal 21: The following R2D control information carried in L1 control for D2R scheduling are supported:
Message types
ID associated with device(s)
Time domain resources
Frequency domain resources
MCS-like information
Chip duration
Repetitions
Midamble related information
Proposal 22: Support L1-based ACK/NACK feedback of device in the D2R.

3GPP TSG RAN WG1 #120bis		R1-2501896
Wuhan, China, April 7th – 11th, 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: TDMA only, FDMA only and TDMA+FDMA are supported for D2R transmission.
Proposal 2: R2D control information for R2D reception and D2R scheduling is transmitted in L1-control signaling.
Proposal 3: Separate CRC is attached to L1 R2D control information and R2D data, respectively.
Proposal 4: L1 R2D control information includes some reserved bits for the purpose of forward compatibility.
Proposal 5: L1 control information and data are transmitted using different M values.  
Proposal 6: 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 7: Compare the overhead of TBS indication vs. postamble size to decide on the method indicating end of PRDCH transmission.
Proposal 8: Related to the information carried by R2D control signaling for D2R scheduling, following field need to be supported:
Time domain resources when multiple time domain resources are allocated by reader.
Frequency domain resources to indicate a set of values related to small frequency shift.
MCS-like information indicates the coding rate of FEC and modulation scheme is not needed to be indicated.
Chip duration.
ID associated to device(s)
Repetitions may indicate the type of repetition and/or the times of repetitions.
Midamble related information could indicate the pattern/length/location of D2R midamble.
Proposal 9: D2R postamble immediately follows the PDRCH is to acquire the end of PDRCH transmission.
Proposal 10:  Support X>=1, and the R2D transmission triggering random access could indicate the X time domain resources.
Proposal 11: Gap is reserved between consecutive time domain resources, and the gap is increased in time domain.
Proposal 12:  Support repetition and related indication for device-to-reader transmission, e.g., MSG1 and MGS3
Proposal 13: 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 14: If no support of consecutive TDMed D2R transmissions for Msg3, non-interleaving Msg3 transmissions is supported.
Proposal 15: 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.
The monitoring window of MSG4
Proposal 16: Support multiple TR2D_max values for devices with different energy levels and/or multiple TR2D_max values for devices with varying initial clock accuracies
Proposal 17: RAN1 can wait until input from higher layers to work on proximity determination.
Proposal 18: 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 19: Discuss whether the device can go to memory retention state within inventory round to save power 
Proposal 20: Discuss how to limit device participating in the inventory round, random access round depending on its availability of stored energy 
Proposal 21: Support energy aware slot selection in an inventory round as opposed to random slot selection.

3GPP TSG RAN WG1 #120bis                     	R1-2501922
Wuhan, CN, April 7th – 11th, 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:	A time counting clock will likely be needed to support a variety of device functionalities including variable payload size, midamble insertion rules, and PDRCH repetition.
Observation 2:	Power supply requirements for TDM of Msg1 are significantly less than power supply requirements for FDM.
Observation 3:	Fixed format L1 control may not significantly increase configuration flexibility for R2D transmissions.
Observation 4:	Fixed format L1 control may reduce the reception latency and energy consumption for a device receiving PRDCH transmission.
Observation 5:	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 the case of contention-based access where multiple Msg1 occasions are configured within a slot triggered by a single PRDCH transmission, reader configuration should support X>=1 time domain resources for Msg1 occasions.
Proposal 2:	A reader triggering multiple FDM Msg1 occasions with a single PRDCH transmission, indicates the available frequency resources for those Msg1 indications in the PRDCH transmission triggering them.
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 #120bis                                                                                     	R1-2501995
Wuhan, China, April 7th – 11th, 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:
Observation 1: The time and frequency resources of paging transmission depend on the gNB scheduling and implementation.
Observation 2: Resource efficiency of Msg1 transmission decreases with the increase of maximum X if TDMA is supported.
Observation 3: For SFO at 105 ppm, the maximum guard time for Msg1 transmission supporting TDMA of X=2 is smaller than the gap time needed for Query-like R2D signalling.
Observation 4: SFO would not be the limiting factor for the maximum number of Msg1 time domain resources when SFO is smaller than 105 ppm after the adjustment using the R2D preamble.
Observation 5: For device 1 with 105 ppm SFO, no obvious advantages can be obtained by using TDMA for Msg3.
Observation 6: The latency can be reduced by tens of milliseconds by using TDMA if the residual SFO can be decreased to 104 ppm or lower.
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 R2D chip duration should be defined as that of an OOK chip of OOK-4 signal, which is equal to 1/M of an OFDM symbol length (excluding the CP), where M 1.
Proposal 3: For Device 1, R2D signal should only support following M values: {2, 4, 8, 16}.
Proposal 4: The durations related to the D2R transmission should be clarified as following:
D2R information bit duration: It is defined as the D2R information bit for the D2R transmission before the channel coding.
D2R bit duration: It is defined as the duration of each coded bit after FEC, which is independent from the small frequency shift (SFS) factor.
D2R chip duration: It is defined as the actual transmission duration for the D2R transmission after the SFS, which has the relationship with the D2R bit duration that D2R bit length = 2 * R * chip length. 
Proposal 5: For Device 1, the bit rate of PDRCH without SFS consideration should not be higher than 240kbps with the equivalent M value of 16.
Proposal 6: The bit duration would need to inform the device via the implicit or explicit indication in general, although it is critical for the Msg1 in CBRA procedure for FDMA.
Proposal 7: The three options for D2R transmission indication based on the certain chip duration indication should be specified as following:
Option 1: The D2R chip duration and corresponding SFS factor R values set are predefined. The two-stage D2R transmission indication is carried in PRDCH control information. The D2R bit duration could be obtained via the indicated chip duration and the minimum R value in the R value set. 
Option 2: The D2R chip duration and the SFS factor R are carried in PRDCH control information. The D2R bit duration could be obtained via the indicated chip duration and the minimum R value according to the predefined R value set or TBS related information.
Option 3: The D2R chip duration is implicitly indicated by deriving from the control signaling of coded bit duration and SFS factor R.
Proposal 8: The TBS tables should be introduced for simple indication of TBS and the corresponding TTI, which are aligned with the NR time domain resource assignment.
Proposal 9: Adopt the following TBS tables for PRDCH and PDRCH: 
The TBS table for PRDCH (3 bits TBS indication)
The TBS table for PDRCH (3 bits TBS indication)
Proposal 10: The determination of the resources for the transmission occasion of Msg1 should be carried by R2D control information in initial paging message transmission, i. e. DCI field indication.
Proposal 11: Support X>1 time domain resource(s) for D2R transmission(s) for Msg1 that is determined by a R2D transmission triggering random access.
Proposal 12: X is 2 when SFO is 105 ppm in Rel-19 for A-IoT device 1 and a larger X can be indicated by reader for future release when the SFO could be reduced to be less than 105 ppm.
Proposal 13: In paging R2D control information, support indicating the time duration of an Msg1 transmission occasion, which minimizes the signalling overhead compared with indicating the time duration of guard time.
Proposal 14: Msg1 transmissions from multiple A-IoT devices in FDMA should be transmitted with the same bit rate.
Proposal 15: Following options can be considered to indicate R values in CBRA.
Option 1: A set of SFS factor R values are predefined corresponding to one chip duration. 
Option 2: The maximum SFS factor R is indicated by PRDCH control information. 
Option 3: The D2R chip duration is implicitly indicated by deriving from the control signaling of coded bit duration and SFS factor R.
Proposal 16: The devices should monitor the Msg2 from a common starting time for the Msg2 transmission in response to multiple Msg1 transmissions.
Proposal 17: The information of the time domain resource allocation for the Msg2 should be indicated by the PRDCH for paging, at least including an offset to the common reference point, the length of Msg2 and the number of PRDCHs for the Msg2.
Proposal 18: For Msg2 transmission in response to multiple Msg1 transmissions, the common starting time and the common reference time would be used to simplify the implementation, since the SIP in PRDCH can trigger the PRDCH detection at the A-IoT device.
Proposal 19: The maximum number of Msg1 responded by one Msg2 is dependent on the gNB implementation.
Proposal 20: 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 21: The frequency domain resource for each scheduled Msg3 transmission can be indicated in Msg2 by following two options:
Option 1: {index#1, index#2}, where index#1 points to a D2R chip duration, index#2 points to a value of R in the R value set corresponds to index#1. D2R bit duration can be obtained by the indicated chip duration and the minimum value in the corresponding set of R;
Option 2: {D2R chip duration, R}. D2R bit duration can be obtained by the indicated chip duration and the minimum value in a predefined set of R, or by the bit rate related to TBS indication.
Option 3, the D2R chip duration is implicitly indicated by deriving from the control signalling of coded bit duration and SFS factor R. The coded bit would be the modulation symbol.
Proposal 22: For device 1 with 105 ppm SFO, support X=1 for Msg3.
Proposal 23: For the consistent design with Msg1 scheduling and the backward compatibility with the devices with higher capability for SFO estimation, X>1 can be considered for Msg3.
Proposal 24: Following options can be considered for time domain resource allocation for Msg3:
Option 1: { Toffset, 1, N, Tresource }.
Option 2: { Toffset, 1, N, Tguard }
Toffset, 1: the time period between the start time of the first time domain resource for Msg3 transmission and its reference time.
N: The number of TDMAed time domain resources for Msg3
Tresource: the time duration of one time domain resource, which including the signal length Tsignal and the guard time between two adjacent time domain resources Tguard.
Tguard: the guard time between two adjacent time domain resources.
Proposal 25: OFDM symbol, slot and the minimum value of R2D and D2R chip duration supported by the device can be used as the time unit for indicating Toffset, 1, Tresource and Tguard respectively.
Proposal 26: Collision resolution mechanism of Msg1 transmission needs to be designed to improve the probability of successful random access.
Proposal 27: 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 28: 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 29: It is not necessary to define monitoring time window for A-IoT to receive Msg2.
Proposal 30: The time resource for monitoring msg2, it can be determined by the reference time location, the time offset and the time duration of PRDCH for Msg2.
Proposal 31: 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 32: The corresponding D2R transmission timing TR2D following a R2D transmission is determined based on the control information in the R2D transmission, where TR2D  TR2D_min.
Proposal 33: Considering the processing time required for A-IoT devices to decode PRDCH, one OFDM symbol can be considered as the value of TR2D_min.
Proposal 34: It’s not necessary to define the values of TD2R_min, TD2R_max, TR2D_R2D_min and TD2R_D2R_min in RAN1 specification.
Proposal 35: When Msg3 is segmented, 1 bit of new data indicator in the control information carried by Msg2 is needed to indicate the device to transmit the new data or retransmission.
Proposal 36: It should be supported that joint CRC is attached to R2D control information and R2D data.
Proposal 37: The R2D control information of TBS indication could be mapped to a set of sequences to improve the reliability of R2D control information.
Proposal 38: A common PRDCH format can be designed for Paging and Msg2.
Proposal 39: Adopt the following table for scheduling information in PRDCH:

3GPP TSG RAN WG1 #120-bis          						R1-2502017
China, Wuhan, April 7th – 11th, 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, estimation of optimum M value for R2D signals, scheduling and timing relationships. The work also discusses the msg0. We have made the following observations and proposals related to the above-mentioned aspects of A-IoT:

Observation 1: As R2D signals are transmitted using OOK-4 generated by OFDM modulator, it is important to define the M-value for OOK-4 modulation for all DL message signals.
Proposal 1: we propose the following three options to decide the optimum M value. 
Option 1: Msg0 contains known preamble from which the device can estimate the channel condition and choose an optimum M value from a lookup table stored in the device and convey the same through msg1.
Option 2: Msg1 contains known preamble from which the reader can estimate the channel condition and choose an optimum M value from a lookup table stored in the reader and the M value will be used for subsequent DL transmissions.

Option 3: An optimum value can be decided based on the following parameters:
Received signal strength of the UL message signals received form the device
Block error rate
Data rate and latency
Observation 2: Reusing the Msg1 frequency domain resources does not guarantee efficient resource allocation, as time domain resources also need to be allocated accordingly.
Proposal 2: 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 3: The maximum time duration for Msg1, considered as T1_max depends on the number of devices available, transmission bandwidth of device, and the receiver bandwidth of the reader which indicates the number of frequency domain resources available to the devices to transmit Msg1. 
Proposal 3: RAN1 should define the minimum and maximum time TD2R_min and TD2R_max for transmitting D2R signal Msg1. T1_min = TD2R_min is the Msg1 frame transmission time, which is the minimum time required to transmit Msg1. T1_max = X × T1_min = TD2R_max is the maximum time available to the device to transmit Msg1. T1_min is considered as the slot duration of slotted Aloha. 
Proposal 4: 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: 

Proposal 5: The following information can be explicitly or implicitly conveyed to the device through msg0:
1 bit information for 2-step/4-step CBRA
Msg0 timing related information
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 #120bis			R1-2502025
Wuhan, China, April 7th-11th, 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 proposals:
Proposal 1: Support the scheduling information as L1 control information.
Proposal 2: A potential PRDCH channel can be designed as follows:
The PRDCH channel consists of 2 parts including L1 control information and higher-layer data.
The L1 control information includes multiple control information fields with a specific size, such as TBS-related, time domain resource, frequency domain resource, ID-related, and other necessary fields.
The higher-layer data information can be regarded as the data field of the PRDCH channel.
Proposal 3: Support a separate CRC coding scheme for PRDCH channel design.
Proposal 4: Support placing the ID-association information at the front part of the PRDCH.
Proposal 5: Support a small frequency shift factor indication for D2R transmission based on a pre-defined rule.
Proposal 6: The proper small frequency shift factor indication may depend on the device’s report capability
A device that reports the small frequency shift related capability will be explicitly indicated in the shift factor
A device without small frequency shift related capability will not be indicated or will be indicated a default frequency resource to perform TDMA.
Proposal 7: Support a new frequency domain resource reference point different from the carrier frequency point if needed.
Proposal 8: Support indicating the transmission bandwidth implicitly by the chip duration.
Proposal 9: Support indicating the reference duration, start occasion, and time domain resource duration in the PRDCH for a time domain resource.
Proposal 10: The size indication of a time domain resource shall be related to the device’s capability.
Proposal 11: Support the indication of FEC application, preamble/midamble related information, the repetition, and the random access method in the scheduling information.
Proposal 12: Support a‘separate MSG1 resource indication scheme’ that different PRDCHs indicate different MSG1 resources or MSG1 resource groups in the random access procedure.
Proposal 13: Prefer two time domain access resources for MSG1 transmission in the TDMA procedure.
Proposal 14: Support option 3 that leaves the MSG1 transmission occasion indication scheme for network decision based on the amount of time domain resources.
Proposal 15: Support MSG2 monitoring window for device 1.
Proposal 16: 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 17: The MSG3 frequency domain resource reuses the frequency domain resource for MSG1 for the same device can be supported if the device is a TDMA-only device, otherwise that reuse should not be supported.
Proposal 18: Support only designing a configurable resource set/pool where the network schedules transmissions instead of confirming the specific scheduling method.
Proposal 19: Support the time interval of TD2R_min and TD2R_max
Proposal 20: Using microseconds to define the duration of each interval.
Proposal 21: Support explicitly or implicitly indicating the interval duration to the devices.

3GPP TSG RAN WG1 #120-bis	R1-2502043
Wuhan, China, Apr. 7th - 11th, 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: 
Observation 1: The power consumption for clock counting is significantly less than the power consumption for small frequency shift according to TR 38.769. 
Proposal 1: Support X>=1 time domain resource(s) for D2R transmission(s) for Msg1 based on one R2D transmission triggering random access. 
At least X = 1 and X = 2 are supported. 
FFS: other values of X
Observation 2: Option 1a for Msg2 monitoring increases the reader complexity and complicates resource allocation for AIoT random access. 
Proposal 2: For Msg2 monitoring, support at least 
Option 2: where a PRDCH for Msg2 transmission corresponds to multiple A-IoT Msg1 received from different devices, the starting time for Msg2 monitoring is common for multiple Msg1 resources. 
Proposal 3: RAN1 to discuss A-IoT device monitoring behaviour for Msg2 retransmission(s) including potential additional monitoring window. 
Proposal 4: RAN1 to consider using violation of Manchester coding rule to determine the end of the R2D transmission. 
Proposal 5: Support repetition related information being indicated to the device for D2R scheduling. 
FFS: impact of repetition on preamble of PDRCH
FFS: details of the repetition related information 

Proposal 6: RAN1 to introduce (TR2D_min) into specification as the minimum time between a R2D transmission and the corresponding D2R transmission following it.
FFS impact of padding (if any) on the value of (TR2D_min)
Observation 3: It is beneficial for the reader to know when the device is available or unavailable. 
Proposal 7: 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 #120bis	R1-2502070
Wuhan, China, April 7th – 11th, 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:
Observation 1: For PDRCH, the timing error would depend on transmission time, which is derived based on payload size, repetition number, MCS, and SFO.
Observation 2: D2R midamble sequence could be the D2R midamble related information if multiple D2R midamble sequences are supported.
Observation 3: Length of midamble sequence could be the D2R midamble related information.
Observation 4: Variable-length D2R midamble sequence design is of benefit to support flexible PDRCH scheduling.
Observation 5: Location of D2R midamble could be the D2R midamble related information.
Proposal 1: Support TDMA of X>1, and the maximum value of X should be 2 or 4.
Proposal 2: Two options are discussed to indicate the time domain resource.
Option 1: granularity of one chip, M chip or groups of chips;
Option 2: TB size for device to calculate the time domain resource.
Proposal 3: The time domain resource indication is reused to indicate X time domain resources for Msg1 scheduling.
Proposal 4: For Msg2 transmission with option 1, one extension coefficient parameter may be needed for time domain resource indication of Msg3.
Proposal 5: For Msg2 transmission with option2 to schedule multiple Msg3 in FDMA mode, support compact Msg2 design for the resource indication of Msg3.
Proposal 6: For Msg2 transmission with option2, TDMA mode of Msg3 can also be supported.
Proposal 7: Support device transmitting Msg3 after the corresponding Msg2 reception. 
Proposal 8: D2R scheduling information should contain a field to indicate small frequency offset.
Proposal 9: The bitwidth of the field of small frequency offset depends on the range of frequency resource which the D2R transmission could occupy.
Proposal 10: A minimum gap between two SFS is required, and a minimum gap between a SFS and CW is required.
Proposal 11: For Msg1 or Msg3 scheduling, a common small frequency offset indicates the maximum frequency resource which could be used by device(s).
Proposal 12: Midamble related information includes payload size, repetition number, MCS and SFO, midamble sequence, midamble length and midamble location.
Proposal 13: Midamble can be implicitly indicated by one of the following options:
Option 1: pre-defined chip number/TBS threshold;
Option 2: pre-defined timing error threshold;
Option 3: the boundary of repetition when repetition indicated;
Proposal 14: Support to define a monitoring window for Msg2 reception of device 1.
Proposal 15: For Msg2 monitoring, [TD2R_min, TD2R_max] need to be determined at least base on a reference time of processing TD2R, maximum sampling frequency offset, one OFDM symbol duration.
If Option 3 is adopted, transmission duration of Msg1 and repetition number are needed for determination;
If Option 3 is adopted and X time resources are scheduled for Msg1, X should be considered for determination.
Proposal 16: The device may take a few chips beyond TD2R_max to determine whether R2D transmission exists. 
Proposal 17: TB size determination should be based on chips to convey information bits.
The chips to convey information bits could be obtained by excluding chips of ambles;
If convolution code is used, its code rate should be used to derive the TB size;
If channel code is used, its code rate should be used to derive the TB size.
Proposal 18: Signaling for control information indication should be determined according to the service, capability of the device.

3GPP TSG RAN WG1 #120bis	R1- 2502126
Wuhan, China, April 7th – 11th, 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:
Observation 1: 
Assuming that M Msg.1s need to be transmitted,
Required transmissions/resources:
In the case of X=1, M Msg.0s are required to trigger M Msg.1 transmissions.
In the TDMA case of X=M>1, 1 Msg.0 is required to trigger M Msg.1s and M-1 guard periods are required to split the M Msg.1 transmissions.
The spectrum efficiency of the scheme supporting X=2,3 is higher than that of X=1. 
The total time domain resource required by X/M=2 or 3 is about 10% less than that required by X=1.
The total time domain resource required by X/M=4 is comparable with that required by X=1.
The total time domain resource required by X/M=5 is even larger than that required by X=1.
Proposal 1: 
Support TDMA-based transmission of Msg.1, X is no larger than 2 or 3.
Proposal 2:
To support Msg.1 transmission in TDMA manner, the Msg.1 time domain resource should be allocated/indicated by the reader.
The start of the Msg.1 time domain resource should be indicated in the control information. 
The reference timing can be the end of Msg.0 when the start of time domain resource is indicated.
The payload size of Msg.1 should be fixed and predefined in the specification.
Proposal 3:
In the case that one Msg.0 triggers more than one Msg.1 transmission, the starting time for monitoring Msg.2 should be common among devices which have transmitted Msg.1 for both the separate Msg.2 transmission (option 1) and the common Msg.2 transmission (option 2).
Observation 2:
To accelerate the discussion on Msg.2 monitoring, clarification on whether the definitions of TD2R_min and TD2R_max are from a reader’s perspective or a device’s perspective is necessary.
Proposal 4: 
Clarify/update the definitions of TD2R_min and TD2R_max are from a reader’s perspective.
Proposal 5:
A monitoring window should be a basic assumption for Msg.2 reception at the device side which can save energy for device 1 to receive Msg.2.
Proposal 6:
A monitoring window for Msg.2 reception should be defined with the starting time and the time duration.
Proposal 7:
From a device perspective, the window for Msg.2 monitoring starts no earlier than TD2R_min.
The reference time for determining the start of the window can be the end of time domain resource where Msg. 1 is transmitted for TDMA with X=1 or FDMA. 
The reference time for determining the start of the window can be the end of the last Msg.1 time domain resource among the X Msg.1 time domain resources for TDMA with X>1.
Proposal 8:
An indication carried by control information or a rule predefined in the specification is necessary for devices to determine the duration of the window for monitoring Msg.2. 
In the case of common Msg.2 transmission, the following factors need to be taken into account on duration of the window: 
The duration for Msg.2 transmission, and
The potential uncertainty of the start of the Msg.2 transmission.
In the case of separate Msg.2 transmissions, the following factors need to be taken into account on duration of the window: 
The number of TDMA/FDMA resource for Msg.1 transmissions, 
The duration for Msg.2 transmission, 
The potential uncertainty of the starting time of the first Msg.2 transmission, and 
The gap between two consecutive Msg.2 transmissions, e.g., TR2D_R2D.
Observation 3:
TDMA Msg.3 transmission schemes (X>1) cannot provide better spectrum efficiency than the scheme of X=1.
The size of Msg.3 is obviously larger than Msg.1. Long Msg.3 transmission can cause more obvious accumulated timing error. 
The more obvious accumulated timing error requires a larger guard period between the adjacent time domain resources for Msg.3 transmission to handle timing errors caused by residual SFO.
Proposal 9:
For Msg.3 transmission, 
FDMA can be considered.
TDMA is not supported.
Proposal 10:
If separate Msg2 transmission is supported, Msg.3 transmissions could be:
Alternative 1: Msg.3s can be transmitted after all Msg.2 transmissions are completed. (Non-interleaving Msg.3 transmission given in the FL summary).
Alternative 2: Each Msg.3 is transmitted right after its corresponding Msg.2. The Msg.2 and Msg.3 of one device are after the Msg.2 and Msg.3 of another device. (Interleaving Msg.3 transmission given in the FL summary.)
Observation 4:
If the interleaving Msg.3 transmission scheme given in the FL summary is supported, the Msg.2 monitoring window could be enlarged because both the Msg.2 transmissions and the Msg.3 transmissions should be counted in the window. In this case, the energy consumption of devices may increase due to a longer monitoring period.
Proposal 11: 
Adopt the non-interleaving Msg.3 transmission if the separate Msg.2 transmission scheme is supported.
Observation 5:
The definitions of the timing intervals given in TR38.769 section 6.1.3 should also be further clarified/updated, i.e., whether the time intervals are defined from a reader’s perspective or a device’s perspective.
Proposal 12: 
The definition of the time intervals on AIoT processing timing should be from a reader’s perspective.
A device cannot perceive the timing error due to its internal low-quality clock. On the contrary, a reader can detect and handle the timing error.
The impacts of timing error must be considered when the time intervals are defined, otherwise the potential collision between transmissions from different devices cannot be avoided.
Observation 6:
Regarding the necessity and purpose for the time interval between R2D transmission and the subsequent D2R transmission,
The TR2D_min and TR2D_max are necessary, which can be defined as the earliest and latest start of D2R signal arriving at the reader from the end of R2D signal transmitted by reader.
The TR2D_min /TR2D_max should take into account the following factors: the processing delay of the device on reception of R2D signal and preparation of D2R transmission, the margin for timing error caused by residual SFO on devices.
A device can start to transmit D2R signal no earlier than TR2D_min. The reader monitors the start of D2R signal within [TR2D_min, TR2D_max]. 
Observation 7:
Regarding the necessity and purpose for the time interval between R2D transmission and the subsequent D2R transmission,
The TD2R_min and TD2R_max are necessary, which can be defined as the earliest and latest start of R2D signal transmitted by the reader from the end of D2R signal arriving at the reader.
The TD2R_min /TD2R_max should take into account the following factors: the processing delay of reader on reception of D2R signal and preparation of R2D transmission, the margin for timing error caused by residual SFO on devices.
The reader guarantees the start of R2D signal in the range of [TD2R_min, TD2R_max]. A device can start to monitor the R2D signal no earlier than TD2R_min.
Proposal 13:
For R2D reception, at least the following information should be indicated in the control information:
ID associated with device(s).
Message/command type.
Proposal 14:
A gap in time domain between the control information and the subsequent R2D transmission relevant to the control information should be reserved. 
This can guarantee that devices have enough time to successfully decode the control information and prepare to receive the subsequent R2D transmission according to the control information.
Proposal 15:
The value of R should be indicated in the control information for frequency domain resource allocation.
Proposal 16:
The allocation of D2R time domain resource in the control information at least includes
The start of the allocated time domain resource
TBS for D2R transmission with variable size 
Proposal 17:
No dedicated information for block level repetition is needed.
The block level repetition can be realized by the reader’s implementation and completely transparent to the device.
Proposal 18:
Support the scheduling information for R2D reception carried by the L1 control signaling.
Proposal 19:
Support the separate CRC attached to the L1 control signaling and subsequent R2D data respectively.
Observation 8:
The device may have different behaviors to process the received R2D signal when L1 control signaling is or isn’t involved in it.
The device should be able to identify whether a R2D transmission includes L1 control signaling or not.
Proposal 20:
To let a device be able to identify whether a R2D transmission includes L1 control signaling or not, the following options can be considered:
Option 1: A R2D transmission always contains a predefined zone reserved for the L1 control signaling.
The device can identify whether there is L1 control signaling by checking this predefined zone.
Option 2: An explicit indicator is adopted to inform the device whether L1 control signaling is contained in the R2D transmission.
The explicit indicator can be carried by this R2D transmission or a previous R2D transmission.
Proposal 21:
Support the scheduling information for D2R transmission carried by the high layer signaling.

3GPP TSG RAN WG1 #120bis			R1-2502163
Wuhan, China, April 7th – 11th, 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 discuss the X value for TDMA,  random access aspects, timing relations, and also the scheduling related control information. The following proposals and observations are made:
Observation 1: Increasing the number of sub-slot occasions within one slot for TDMA of Msg1 and Msg3 does not always reduce inventory completion time. When the data rate is R2D=28kbps, D2R=80kbps, introducing 2 or 4 sub-slots within each slot can only provide inventory completion time reduction gain of 7.8% and 3.4%, respectively; When the data rate is R2D=7kbps, D2R=20kbps, introducing TDMA transmission of Msg1 within each time slot will increase the inventory completion time.
Proposal 1: More than 2 sub-slot time occasions is not supported for TDMA case.
Proposal 2: For no TDMA and FDMA case, for the time interval between Msg1 and R2D transmission triggering Msg1, option 1 is supported,
Option 1: Define a maximum time TR2D_max between a R2D transmission and the corresponding D2R transmission following it, so that the device transmits D2R transmission within [TR2D_min, TR2D_max].
Proposal 3: For no TDMA and FDMA case, Msg1 resource is implicitly determined to be within [TR2D_min, TR2D_max] after the end of RACH trigger message.
Proposal 4: 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 5: The maximum number of frequency resources available for Msg1 depends on,
The maximum R value.
Bandwidth of main lobe for each device.
The harmonics orders to be avoided.
SFO of devices
Proposal 6: For FDMA case, Msg1 time resource is implicitly determined to be within [TR2D_min, TR2D_max] after the end of RACH trigger message.
Proposal 7: For TDMA of Msg1, the number of TDMA resources and the corresponding starting time for each time occasion should be provided before the inventory round starts, such as by the paging message.
Proposal 8: For TDMA of Msg1 with X>1, the timing of Msg1 follows option 2,
 Option 2: The corresponding D2R transmission timing TR2D following a R2D transmission is determined based on the control information in the R2D transmission, where TR2D ≥ TR2D_min.
Proposal 9: The time granularity of indication can base on R2D chip duration.
Proposal 10:For Msg2 in response to TDMA of X=1 Msg1 transmission initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponds to the A-IoT Msg1 transmitted by the device no earlier than TD2R_min after the end of the time domain resource for Msg1 transmission.
Proposal 11:For Msg2 in response to TDMA of X=1 Msg1 transmission initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponds to the A-IoT Msg1 transmitted by the device no later than TD2R_max after the end of the time domain resource for Msg1 transmission.
Proposal 12: No explicit resource indication is needed, device can expect a Msg2 within [TD2R_min, TD2R_max].
Proposal 13: For no TDMA or FDMA case, no explicit monitoring window for Msg2 is defined.
Proposal 14: For FDMA with Y>1, case 2, i.e. two PRDCHs for Msg2 Tx in response to two Msg1s followed by FDMed Msg3 can be supported.
Proposal 15: For FDMA case, a common starting time for Msg2 monitoring is adopted.
Proposal 16: For FDMA case, to determine the reference time for the starting time for monitoring Msg2 in response to multiple Msg1 transmissions initiated by a R2D transmission triggering random access, the following option is adopted,
Option 1: End of time domain resource where the device transmitted the Msg1.
Proposal 17: For one common Msg2 followed by FDMed Msg3 case, there is no need to further define monitoring window for Msg2.
Proposal 18: For separate Msg2s followed by FDMed Msg3 case, a monitoring window can be defined, either dynamically determined by device or indicated by the Reader.
Proposal 19: For TDMA transmission of Msg1/Msg3, case 3: Msg2-Msg3-Msg2-Msg3 pattern is supported.
Proposal 20: For TDMA with X>1, there are two cases for Msg2 monitoring, 
Case 1: For Msg2 in response to TDMA of X>1 (if supported) Msg1 transmissions initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponding to the A-IoT Msg1 transmitted by the device no earlier than TD2R_min after the end of the last of X time domain resource(s) for Msg1 transmission(s).
Case 2: For Msg2 in response to TDMA of X>1 (if supported) Msg1 transmissions initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponding to the A-IoT Msg1 transmitted by the device no earlier than TD2R_min after the end of its Msg1 transmission.
Proposal 21: For TDMA Msg2 monitoring case 1, if common Msg2 is transmitted, no additional monitoring window is needed since device is expected to receive Msg2 no later than TD2R_max after the end of the last of X time domain resource(s) for Msg1 transmission(s).
Proposal 22: For TDMA Msg2 monitoring case 1 with interleaving Msg2-Msg3-Msg2-Msg3 transmission or for Msg2 monitoring case 2, a monitoring window can be defined.
Proposal 23: For TDMA, when monitoring window of Msg2 is defined, it can be indicated with a fix length or with variable length depending on number of successful Msg1s. 
Proposal 24: For no TDMA and FDMA case, option 1 is supported for the timing between Msg2 and Msg3,
Option 1: Define a maximum time TR2D_max between a R2D transmission and the corresponding D2R transmission following it, so that the device transmits D2R transmission within [TR2D_min, TR2D_max].
Proposal 25: For no TDMA and FDMA case, Msg3 resource is implicitly determined to be within [TR2D_min, TR2D_max] after the end of PRDCH for its Msg2.
Proposal 26: The frequency domain resource for Msg3 can be determined based on successfully reception state of Msg1 and predefined frequency resources orders.
Proposal 27: For FDMA case, the following options can be further studied for the timing of Msg3 when Msg2 is transmitted by option 1,
Option 1-1: Starting time of Msg3 is based on [TR2D_min, TR2D_max] taking the end of last PRDCH for Msg2 as reference time;
Option 1-2: The starting time of Msg3 is indicated by Msg2.
Proposal 28: For FDMA case, when Msg2 is transmitted by option 2, the starting time of Msg3 is based on [TR2D_min, TR2D_max] taking the end of PRDCH for Msg2 transmission as reference time.
Proposal 29: For TDMA case of multiple Msg1 transmissions initiated by a R2D transmission triggering random access, if Msg2-Msg3-Msg2-Msg3 pattern is used, the starting time of Msg3 is based on [TR2D_min, TR2D_max] taking the end of PRDCH for Msg2 transmission as reference time
Proposal 30: Case 4: Common Msg2, Msg3, Msg3 and case 5: Msg2, Msg2, Msg3, Msg3 are not supported.
Proposal 31: The following table can be a starting point for resource determination and monitoring aspects of RACH messages.
Table 5 Summary of resource determination and monitoring aspects for Msg1/2/3
 
Observation 2: If scheduling restriction exists for gNB/intermediate UE, e.g., reader perform scheduling every X ms, the inventory process will be inefficient.
Proposal 32: 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 33: 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 34: The following can be considered for resource determination and timing aspects for parallel query way.
Table 7. resource determination and timing aspects for parallel query
Proposal 35: When X>1 and Y>1 are together used for Msg1, the number of frequency resources for FDMA Msg3 should be equal or smaller than Y.
Proposal 36: When X>1 and Y>1 are together used for Msg1, one common Msg2 can schedule at most Y Msg3s.
Proposal 37: TR2D_min is defined to represents the shortest switching and processing time for devices.
Proposal 38: TR2D_max is defined to represents the longest processing time and the weakest device capabilities.
Observation 3: The value of TR2D_max can be affected by payload of R2D and D2R channel, the transmission format applied to D2R channel, the hardware capabilities and implementation, etc.
Observation 4: A large TR2D_max will cause long waiting time of empty slot for Reader, reducing the inventory efficiency.
Proposal 39: Definition of TR2D_min and TR2D_max does not consider SFO effect.
Observation 5: SFO effect can be considered by the Reader when detecting D2R channel after a R2D channel.
Proposal 40: 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 41: A TD2R_max can be define for device to determine a random access failure from physical layer.
Observation 6: The issue that Msg2 fall out of [TD2R_min, TD2R_max] due to timing offset between FDMed devices needs to be studied.
Proposal 42: 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 43: Device’s identification of PRDCH function by message type is not supported by L1.
Proposal 44: Postamble is used for identification of the end of PRDCH transmission.
Proposal 45: Assistance information for Msg2 reception and Msg3 transmission can be considered to reduce device power consumption and implicitly determine Msg3 resource.
Proposal 46: For sub slot TDMA case or parallel querying case, indication is needed for
The starting time of candidate time occasions for Msg1, and 
The time offset between Msg2 and Msg3 if case 2 separate Msg2 with FDMed Msg3 are supported.
Proposal 47: The indication of time domain resource for Msg1/3 can be high layer signalling.
Proposal 48: When FDMA is applied during inventory, the candidate small frequency shift factors needs to be indicated by Reader.
Proposal 49: Reader can directly indicates a set of small frequency shift factors, for example, with a bitmap method.
Proposal 50: Reader should indicate the number of repetitions and whether FEC is used for D2R link.
Proposal 51: Reader should indicate at least the number of midamble, and as long as midamble exists, one midamble will be placed at the end of PRDCH, other midambles (if exist) are inserted evenly into PDRCH.
Proposal 52: Control information for D2R scheduling and transmission can be carried by high layer signalling.
Proposal 53: Send LS to RAN2 to include the related information that are carried by higher layer in the message definition
  

3GPP TSG RAN WG1#120bis		R1-2502205
Wuhan, China, April 7th – 11th, 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: TDM with X equal to 2 or 4 should be supported for Msg 1 transmissions.
Proposal 2: The TR2D_min, TR2D_max, and TD2R_min, timing values should be defined for the device. The TD2R_max should be defined depending on RAN2 decision on the need of subsequent transmission of R2D like ACK/NACK. 
Proposal 3: There is no need to define the starting time of the window for Msg2 reception in Rel. 19.
Proposal 4: The need to define the ending time of the window for Msg2 reception depends on RAN2 discussion.

3GPP TSG-RAN WG1 Meeting#120bis                                        R1-2502236
Wuhan, China, April 7-11, 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 observations and proposals:
Observation 1: Transmitting the D2R grant using L1-control signaling requires the device to be aware of the location of these resources beforehand, which would require additional PRDCH formats and the device to perform blind detection, while at the same time, reducing the flexibility and resource utilization efficiency.
Observation 2: Using a higher layer, i.e. MAC, control element to transmit the D2R grant avoids physical layer design, specification, and implementation effort, while at the same time offering flexibility in terms of the size of the grant.
Observation 3: The necessity of each timing is summarized as below:

Proposal 1: At least when a device is expecting a unicast R2D transmissions, when a CRC is present, it is masked by the AS ID.
Proposal 2: Support R2D provides following scheduling information for corresponding D2R transmissions:
For the Y frequency resources of Msg1 resource, their frequency bandwidth is the same.
For each Y value, define a table where each row is Y pairs of {R, } for a possible transmission bandwidth, and row index is indicated in Msg0.
For frequency domain resource for Msg3 transmission, 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
For frequency domain resource for Msg3 transmission, regarding Option 2
In separate Msg2 case: a codepoint way is supported, i.e., use bits to indicate which one pair of {R, } among the ones for Msg1 is reused for Msg3.
In common Msg2 case: a Y-bit bitmap is used, 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. 
The scheduled device determines its random number RN order in MAC (assume its RN order is k-th), and use the frequency resource corresponds to the k-th "1" in the bitmap.
Proposal 3: R2D control information is carried only in MAC.
Proposal 4: For the time interval between a R2D transmission and the corresponding D2R transmission following it:
(1st preference) support that device transmits D2R transmission within [TR2D_min, TR2D_max];
(2nd preference) support that the timing of the corresponding D2R transmission TR2D is determined based on the control information in the R2D transmission if provided by the reader and supported by the device, where TR2D_min TR2D  TR2D_max. Otherwise, the device transmits D2R transmission within [TR2D_min, TR2D_max]
Proposal 5: Support defining following timing relationships, and corresponding value and time unit:
Proposal 6: Support X=1 and X>1 time domain resource(s) for D2R transmission(s) for Msg1 that determined by a R2D transmission triggering random access, where each D2R transmission for Msg1 occurs in one time domain resource of the X time domain resource(s) in Rel-19.
The maximum value of X is down-selected between 2 and 4.  
It is up to device implementation to support X>1
Proposal 7: 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 8: Interleaved Msg3 between different Msg2 (e.g., Msg2-Msg3-Msg2-Msg3) is supported.

3GPP TSG-RAN WG1 Meeting #120bis			R1-2502276
Wuhan, China, April 7th – 11th, 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 time counting of one Msg.1 length of 16 bits (not taking into account of [TR2D_min TR2D_max], SFO error, a required guard interval and preamble/midamble(s)), assuming device sampling frequency is 2Mps, the required additional register memory size is 16 bits.
Observation 2: For time counting of one Msg.3 length of 400 bits (not taking into account of [TR2D_min TR2D_max], SFO error, a required guard interval and preamble/midamble(s)), assuming device sampling frequency is 2Mps, the required additional register memory size is 20 bits.
Observation 3: When X=1, it offers the following benefits:
Time counting is not required for Device 1 (meaning no additional hardware and register memory)
Both Msg.1 and Msg.3 can be transmitted within a pre-defined time bound [TR2D_min, TR2D_max]
Only need to define a minimum time bound for R2D Msg.2 monitoring (TD2R_min)
TD2R_max Is not required since power saving is not critical for Device 1. It is assumed Device 1 always in a power-ON state until it depletes energy in storage.
Easy and direct mapping of frequency domain resource for Msg.3 transmission, which reuses the frequency domain resource for Msg.1 for the same device.
Requires the least amount of specification effort!
For Msg.1 and Msg.3 transmission, not required to define and use TR2D, hence, no signaling is required either.
The timing reference point for Msg.2 monitoring is always at the end of Msg.1 transmission.
Not required to define TD2R_max.
No explicit signaling in the PRDCH Msg.2 transmission is required for indicating frequency domain resources for Msg.3 transmissions.
Observation 4: When X>1 (e.g., X=2) and Msg.2/Msg.3 are sequentially transmitted, the following is observed:
If the 1st time domain resource is allowed to be always selected based on device implementation (for a device that does not perform time counting), device transmits Msg.1 within [TR2D_min, TR2D_max]. But this scheme has the following drawbacks:
For all Msg.1’s received in the 1st time domain resource, the reader would need to correspondingly schedule them in the 1st time domain resource for Msg.3  scheduling restriction.
This naturally imply a device that performs or capable of time counting should choose the 2nd time domain resource for Msg.1 transmission to avoid/reduce collision (since it does not know how many time counting incapable devices will try to access).
When number of time counting incapable/capable devices is not 50/50 split in a system, this natural time domain resource selection restriction will increase collision probability for either the 1st or 2nd time domain resource, also cause imbalanced use of Msg. 1 time domain resources and complicate the scheduling at the reader significantly in the end.
For a Device 1 that performs time counting and selected the 2nd time domain resource for Msg.1 transmission, it would be likely scheduled by the reader to transmit Msg.3 also in the 2nd time domain resource. The required time counting would consist of:
For Msg.1 in 2nd time domain resource (Figure 2): A + Msg.1 resource length + B
where B (guard interval for Msg.1) can be self-determined by device as: 
(A+ Msg.1 resource length) x 20%
For Msg.3 in 2nd time domain resource (Figure 2): D + Msg.3 resource length + E
where E (guard interval for Msg.3) can be self-determined by device as:
(D+ Msg.3 resource length) x 20%
For R2D Msg.2 monitoring,
Same as the X=1 case, only define a minimum time bound for R2D Msg.2 monitoring (TD2R_min). TD2R_max is not required.
Reference timing for TD2R_min is from end of transmitted Msg.1 time domain resource.
For Msg.3 transmission,
the 1st time domain resource for Msg.3 should be within [TR2D_min, TR2D_max] from the end point of the last R2D Msg.2 from the reader.
an indication in R2D Msg.2 is needed to indicate any subsequent R2D Msg.2 from the reader such that the device is able to determine the end point of the last R2D Msg.2 from the reader, which then should be the reference timing (starting point) for TR2D_min.
Observation 5: When X>1 (e.g., X=2) and Msg.2/Msg.3 transmissions are interleaved, the following is observed:
For Msg.1 TX,
if the 1st time domain resource is allowed to be always selected based on device implementation (for a device that does not support or perform time counting), device transmits Msg.1 within [TR2D_min, TR2D_max].
same time domain resource selection imbalance problem exists (as described in Observation 4)
For Msg. 2 RX,
Same as the X=1 case, only define a minimum time bound for R2D Msg.2 monitoring (TD2R_min). TD2R_max is not required.
Reference timing for TD2R_min is from end of transmitted Msg.1 time domain resource.
For Msg. 3 TX,
When Msg.2 and Msg.3 transmissions are interleaved, all Msg.3 are transmitted within [TR2D_min, TR2D_max] after a scheduling R2D Msg.2 is received from the reader  NO time counting is required.
The reader has full flexibility of scheduling any Device 1 in any R2D Msg.2.
Comparing to scenario 2, these are two major benefits of interleaved transmission over the sequential transmission of Msg.2 and Msg.3.
Proposal 1: Regardless whether X=1 or X>1, it is not required to define TD2R_max for Msg.2 monitoring.
Proposal 2: At least when X=1 is indicated by the reader, the frequency domain resource for Msg.3 transmission should be, by default, reuses the frequency domain resource for Msg1 for the same device.
Proposal 3: If X>1 is supported (e.g., X=2), the following is proposed:
The transmissions of Msg.2 and Msg.3 should be performed in an interleaved manner (Msg.2 Msg.3 Msg.2 Msg.3) as shown in the above Scenario 3 (Figure 3).
I.e., not in a sequential manner (Msg.2 Msg.2 Msg.3 Msg.3) shown in Scenario 2.
Proposal 4: If X>1 is supported (e.g., X=2), it is not necessary to introduce / define TR2D for scheduling Msg.1 and Msg.3 transmissions.
In the 1st time domain resource (for both Msg.1 and Msg.3), device based on its implementation performs D2R transmission within [TR2D_min, TR2D_max].
In the 2nd time domain resource (for Msg.1 only), it is sufficient to use [TR2D_min, TR2D_max] and the indicated D2R resource/payload size to determine the starting time.
Proposal 5: Overall, X=1 offers a simpler operation and requires the least specification effort, it is therefore our preference. If X>2 is supported, maximum value of X is limited to 2, and should be supported by all Device 1 in Rel-19.
Control and scheduling information
Observation 6: 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.
Observation 7: In contrast to post-amble, it is more reliable and efficient to indicate TBS with control information.
Proposal 6: Physical layer control information is supported to indicate R2D data transmission, the control information is separately encoded and appended with separate CRC, and the control information includes at least device(s) ID, TBS information or message type.
Proposal 7: Control information for D2R scheduling is transmitted as either physical layer signaling or higher layer signaling.
Proposal 8: For D2R scheduling, time domain resources are NOT indicated.
Proposal 9: For D2R scheduling, frequency domain resources or chip duration are indicated as small frequency shift factor, the reference chip length is to be associated with part of the corresponding PRDCH.
Proposal 10: For D2R scheduling, repetition factor should be indicated.
Proposal 11: For D2R scheduling, mid-amble and post-amble related information are not indicated.
Proposal 12: When R2D and D2R are on different carriers, further study the impact of the uncertainty of ongoing D2R termination time to new D2R scheduling.
Proposal 13: Complexity and power consumption for R2D control information reception should be minimized.
Device (un)availability direction 1
Observation 8: 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 14 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 #120bis								R1-2502320
Wuhan. PR China.  7-11 April 2025
Agenda Item 	:	9.4.4
Source 	:	Sony 
Title 	:	Multiplexing, multiple access and timing relationships for Ambient IoT 
Document for 	:	Discussion 

Conclusion 
This document has considered duplexing and multiplexing / multiple access aspects of Ambient IoT. The following proposals are made:
Observation 1: Including a length field in R2D control information allows devices to sleep and conserve their energy store while monitoring PRDCH.

Proposal 1: The R2D header contains a length field, indicating the length of the R2D packet.
Proposal 2: The R2D header is transmitted reliably, either through the use of a header CRC or through use of a robust modulation format for the header (e.g. OOK-4 with M=1 or 2).
Proposal 3: Worst case time counting and small frequency shift clock inaccuracies are defined in the specifications. For device type 1, a worst case inaccuracy of 105 PPM is specified.
Proposal 4: An R2D slot trigger signal that marks the slot boundaries of a slotted ALOHA scheme is supported in Ambient IoT.
Proposal 5: Support association between the selected Msg1 time and frequency resources to its Msg2 time resources. 

Proposal 6: 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 #120bis		R1-2502371 
Wuhan, China, April 7th – 11th, 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, which saves device’s energy.
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	There is no motivation to provide R2D control information for D2R scheduling via L1 control information.
Observation 4	Indicating a time interval between the scheduling PRDCH and the scheduled PDRCH using the shortest chip length is the most efficient.
Observation 5	Signaling design for indicating D2R scheduling information, if provided via higher layer signaling in R2D data, is up to RAN 2.
Observation 6	The ACK/NACK feedback for PRDCH reception is beneficial for a reader to determine the need for retransmission
Observation 7	There is no clear motivation or use case to define maximum and minimum time for TD2R_D2Rn.
Observation 8	It is appropriate to define multiple Msg2 windows to mitigate the monitoring burden on devices and allow different devices to be assigned different Msg2 windows.
Observation 9	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.
Message type
Reader ID
Proposal 2	Provide R2D control information for PRDCH reception via L1 control information in the corresponding PRDCH, wherein the L1 control information has a fixed size and attached with a separate CRC.
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	The following D2R scheduling indicated in the corresponding PRDCH
Time domain resources, e.g., transmission timing indication, time slot indication for TDMA
Frequency domain resources, e.g., small frequency shift factor indication
Chip duration
ID associated with device(s), which is the same as the device ID for receiving PRDCH and can be skipped.
Repetitions
Midamble (if supported) related information
TBS/payload related information, wherein the indication can be either explicit or implicit based on message type
Message type
Proposal 6	The D2R scheduling information is provided as a R2D data in the corresponding PRDCH, except the scheduled device ID for D2R transmission, which is the same as the device ID for receiving the PRDCH and can be skipped.
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 the largest OOK-4 M value defined.
Proposal 8	Support ACK/NACK feedback in D2R for PRDCH reception via higher-layer signaling.
Proposal 9	Provide transmitting device ID in the D2R control information via L1 signaling.
Proposal 10	If the available data size at a device for D2R transmission is smaller than the TBS indicated by R2D control information, the actual transmitted TBS/payload size is indicated in the D2R control information.
Proposal 11	For TR2D, down-select from the following two options:
Option 1: TR2D_min and TR2D_max are defined.
Option 2: TR2D_nominal and frequency tolerance range are defined.
Proposal 12	For TD2R, TD2R_min and TD2R_max are defined.
Proposal 13	For TD2R, only TR2D_R2D_min is defined.
Proposal 14	The timing of the corresponding D2R transmission TR2D is determined based on one of the following options, with TR2D ≥ TR2D_max:
Option 2: the timing of the corresponding D2R transmission TR2D is determined based on the control information in the R2D transmission, where TR2D ≥ TR2D_max.
Option 3: the timing of the corresponding D2R transmission TR2D is determined based on the control information in the R2D transmission if provided, where TR2D ≥ TR2D_max. Otherwise, the device transmits D2R transmission within [TR2D_min, TR2D_max].
Proposal 15	Support TDMA with X≥1 time domain resource(s) for D2R transmission(s) for Msg1, with the maximum value X=2.
Proposal 16	The PRDCH triggering random access indicates a number of time slot(s), X, for Msg1 transmission.
Proposal 17	The PRDCH triggering random access provides additional information related to random access including 1) access control parameters, 2) information to prevent a duplicated response from a device, 3) count for the remaining random access rounds, and 4) parameters facilitating the device dormancy.
Proposal 18	A-IoT devices are assigned a default frequency resource for A-IoT paging reception.
Proposal 19	The default frequency resource for A-IoT paging reception is stored in NVM of the devices.
Proposal 20	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 21	Support a collision handling mechanism to improve the success rate of the tags with collision, including preamble/sequence for reader to identify the collision.
Proposal 22	For a Msg2 corresponds to multiple Msg1s received from different devices, the PRDCH providing Msg2 can be received no earlier than TD2R_min and no later than TD2R_max from the end of the last time domain resource for Msg1 transmission.
Proposal 23	For a Msg2 corresponds to a Msg1 received from a device, the PRDCH providing Msg2 can be received no earlier than TD2R_min+TΔ and no later than TD2R_max+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.
Note: The monitoring timing is based on device perspective, which may be inaccurate due to timing imperfections. It is up to the reader to accommodate such timing imperfection.
Proposal 24	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 25	The frequency domain resource for Msg3 is always determined based on explicit indication in the PRDCH providing Msg2.
Proposal 26	The time domain resource for Msg3 is determined based on indication in the PRDCH providing Msg2. Otherwise, Msg3 is transmitted within [TR2D_min, TR2D_max] from the Msg2 reception timing.
Proposal 27	A PRDCH providing a group signaling for multiple devices is supported.
Proposal 28	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 29	Specify the energy status report multiplexing at the A-IoT PHY layer.

3GPP TSG RAN WG1 #120bis			R1-2502444 
Wuhan, China, April 7th – 11th, 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 observations and proposals are proposed:
Observations
Observation 1: It is beneficial to support X=2 in some cases to reduce the overall inventory completion time.
The specific cases may depend on the chip rate of R2D/D2R, the payload size of the R2D trigger message, the payload size of Msg1, the preamble length, and the values of TR2D and TD2R.
Observation 2: According to the outcome of SI phase, time counting can be supported for Device 1.
However, long-term time counting will increase the register size, which will have a negative impact on the complexity and power consumption of the device.
Observation 3: As X increases, more durations for time domain resources and the gaps b/w them need to be reserved, which may lead to reduced resource efficiency and unnecessary latency.
Observation 4: 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.
Observation 5: For R2D reception, whether scheduling information is required depends on whether higher-layer signaling and/or L1 R2D control signaling is used for carrying ID associated with device(s).
Observation 6: For D2R scheduling information, the payload size, CRC length, code rate of FEC, repetition number, chip duration, and Manchester coding, sequence length and/or number of X-amble(s) are used to determine the time domain resources.
Observation 7: If not only one final code rate is agreed, the final code rate should be contained in the MCS-like information.
Observation 8: The chip duration can be calculated by the time duration Tb and the Manchester codeword repetition number R.
Observation 9: When the ID associated with device(s) is fixed, it is more appropriate to be carried by the L1-control signalling of PRDCH.
Proposals
Proposal 1: For frequency resource set signalling for FDMed Msg1, at least one repetition number of Manchester codeword should be supported explicitly or implicitly.
Proposal 2: Support TDMA of X>1 in Rel-19 A-IoT, and the maximum value of X is 2.
Proposal 3:  The one or two time domain resources (within one access occasion) for Msg1 transmission can be indicated by a single or separate starting offset.
The granularity of the indication should be the chip duration before small-frequency-shift operation (i.e., the value corresponding to R0 or FS0);
The reference timing of the starting offset is the end time of the corresponding R2D command.
Proposal 4: For contention-based access, the reader can indicate up to two time domain resources represented by a single or separate {Starting offset} values within an access occasion target for multiple devices, and each device selected this occasion for access may need to further select one time domain resource for Msg1 transmission when X=2.
How to select the exact time domain resource needs to be further discussed in RAN2.
Proposal 5: Using 1bit to indicate whether Case a) or Case b) is executed, this indicator can be carried by A-IoT paging or R2D trigger message, Case C) is not supported.
Case a) A PRDCH for Msg2 transmission corresponds to one A-IoT Msg1 received from one device, multiple Msg2 transmission in one access occasion is required;
Case b) A PRDCH for Msg2 transmission corresponds to all the Msg1s received from different devices within one access occasion, only one Msg2 transmission in one access occasion is required;
Case c) A PRDCH for Msg2 transmission corresponds to a subset of the Msg1s received from different devices within one access occasion, multiple Msg2 transmission in one access occasion is required.
Proposal 6: How to perform monitoring for a device is up to device implementation in Rel-19 A-IoT.
How to determine the starting time, time duration and the reference time is unnecessary to be further discussed in RAN1;
Whether to define Msg2 monitory window is related to device re-access procedure and should be decided by RAN2.
Proposal 7: Using 1bit to indicate whether the following Option 1 or Option 2 is executed, this indicator can be carried by A-IoT paging or R2D trigger message.
Option 1: Msg2 case a) + Msg3 case 3, where one Msg2 transmission corresponds to one A-IoT Msg1, the multiple Msg2s and the corresponding multiple Msg3s are interleaved in time domain;
Option 2: Msg2 case b) + Msg3 case 1, where one Msg2 transmission corresponds to multiple A-IoT Msg1s, there is a single common Msg2 and the corresponding multiple Msg3s are FDMed.
Proposal 8: The resources of Msg3 can be re-scheduled as FDM even when the Msg1 resources are TDM.
Proposal 9: 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 10: 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 11: From RAN1 perspective, a R2D command like “QueryAdjust” in RFID can also be introduced and include the scheduling information to adjust the number of candidate frequency/time domain resources in a single access occasion. 
The design details of the aforementioned R2D command depends on RAN2 discussion.
Proposal 12: For contention-free access, the reader can indicate separate time/frequency domain resource(s) associated with the ID(s) of device(s) for the D2R time/frequency resource indication and determination.
The definition of time/frequency domain resources in contention-based access can be reused.
This mechanism can be applied to Msg1, Msg3, and can also be applied to other D2R transmission during command procedure.
Proposal 13: Within one access occasion, TDMed and FDMed resources can be allocated simultaneously to further improve the access and resource efficiency.
Proposal 14: For the time domain resources determination, the sequence length of preamble should be supported.
The sequence length and number of midamble are also supported optionally.
The CRC length is FFS.
Proposal 15: For the frequency domain resources determination, the time duration Tb and the Manchester codeword repetition number R should be supported.
Proposal 16: For the MCS-like information, whether FEC is applied should be contained.
Proposal 17: For chip duration determination, no further information is required.
Proposal 18: The ID associated with device(s) should be determined by other WG(s).
Proposal 19: For repetitions information, the repetition number should be supported for block level repetition.
Proposal 20: For scheduling information for D2R scheduling, the following should be supported:
For time domain resources
Sequence length of preamble  
The sequence length and number of midamble(optionally)
For frequency domain resources and Chip duration
The time duration Tb 
The Manchester codeword repetition number R
For MCS-like information
whether FEC is applied
For repetitions
The block level repetition number
FFS: The ID associated with device(s)
Proposal 21: The following scheduling information for D2R scheduling should be signalled by higher-layer of corresponding PRDCH.
For time domain resources
Sequence length of preamble  
The sequence length and number of midamble(optionally)
For frequency domain resources and Chip duration
The time duration Tb 
The Manchester codeword repetition number R
For MCS-like information
whether FEC is applied
For repetitions
The block level repetition number
Proposal 22: For PRDCH, there may be three formats can be supported:
Format 0: L1 control information only;
Format 1: R2D data only;
Format 2: L1 control information+ R2D data.
Proposal 23: The first two bits of PRDCH transmission which are immediately transitted after preamble can be used for the PRDCH format indication.
Proposal 24: There is no need to further discuss whether processing time is common or different for different A-IoT devices during Rel-19 since only device 1 is within the WI scope. 
Proposal 25: From RAN1 perspective, separate processing time for different traffic types/command types (e.g., DT or DO-DTT) and/or different use case (e.g., Inventory or Command) can be supported.
Further detailed discussion requires other groups to define all command types in A-IoT first.
Proposal 26: At least for the case where TDM is NOT performed within one access occasion, an additional parameter for the maximum time b/w two a R2D transmission and a subsequent D2R transmission can be defined, i.e.:
TR2D_max for a reader to issue a subsequent command if it does not observe a device reply within this time.
Proposal 27: TD2R_max is unnecessary to be introduced as least in Rel-19.
Proposal 28: For the timing relationship parameters b/w two A-IoT transmission, the starting reference time should be the last raising/falling edge of the first transmission, and the ending reference time should be the raising/falling edge of the second transmission.
Proposal 29: To determine the exact values of the timing relationship parameters b/w two A-IoT transmission, the values of T1~T7 defined in RFID can be used as references.
The granularity of TR2D_min, TR2D_max and TR2D_R2D_min could be ms, µs, or OFDM symbol length;
A reference chip duration should be defined as the granularity of TD2R_min, TD2R_max and TD2R_D2R_min.
Proposal 30: For TD2R_min, TD2R_max and TD2R_D2R_min, the value should be defined with a  to address the ambiguity b/w BS and device caused by SFO impacts.

3GPP TSG RAN WG1 #120bis						R1-2502477
Wuhan, China, 7 – 11 April, 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.
Proposal 2: For TDMA of Msg1 transmissions, support X > 1 and down-select the maximum value of X between 2 and 4.
Proposal 3: Agree the following solutions for FDMA transmission timing of D2R transmission for Msg.3:
If different Msg.2 payloads for different devices can be transmitted by using different PRDCHs, the reader can provide different transmission timings of Msg.3 per each device expecting Msg. 2 reception.
If different Msg.2 payloads for different devices can be transmitted by using single PRDCH, the reader can provide a transmission timing of Msg. 3 which is common for the devices expecting Msg. 2 reception.
Proposal 4: If a PRDCH for Msg2 transmission corresponds to an A-IoT Msg1 received from one device, agree option 1a, i.e. the starting time for Msg2 monitoring is separate for each Msg1 resource. 
In this case, different Msg.2 payloads for different devices can be transmitted by using different PRDCHs.
The reader can provide different transmission timings of Msg.3 per each device expecting Msg. 2 reception.
Proposal 5: For a PRDCH for Msg2 transmission corresponds to one or multiple A-IoT Msg1 received from one or multiple devices, L1 control information indicates the number of Msg2 responses and each Msg1 corresponding to one of the responses in the PRDCH.
Proposal 6: 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.
Proposal 7: Support all the following cases for Msg2 and Msg3 transmissions:
Case 1: Common Msg2 is followed by FDMed Msg3 transmissions
Case 2: Separate Msg2 transmissions are followed by FDMed Msg3 transmissions
Case 3: Interleaved TDMed Msg2, Msg3, Msg2 and Msg3
Case 4: Common Msg2 is followed by TDMed Msg3 transmissions
Case 5: Separate Msg2 transmissions are followed by TDMed Msg3 transmissions
Proposal 8: The reader can provide the device with the information on whether the next Msg.2 PRDCH will be transmitted or not, via previous Msg.2 PRDCH control information.
Proposal 9: The reader can provide the number of Msg.2 PRDCHs to be transmitted within the Msg. 2 PRDCH monitoring window.
Proposal 10: For the device starting transmitting D2R transmission within [TR2D_min, TR2D_max], the maximum time TR2D_max and/or the minimum time TR2D_min can be indicated by R2D control information and/or pre-defined in the specification. The maximum time TR2D_max can be different for different A-IoT devices.
Proposal 11: If the timing of the corresponding D2R transmission TR2D is determined based on the control information in the R2D transmission, maximum time TR2D_max can be defined and common to all devices, so that the reader can perform another PRDCH/PDRCH transmission/reception.
Proposal 12: Support L1 control information for PRDCH, i.e. Option 1 for R2D reception and D2R scheduling.
Proposal 13: If RAN1 agrees support of L1 control information for PRDCH, TBS information related to PRDCH is included in L1 control information.
Proposal 14: For D2R transmission with a fixed size based on command type indication in the corresponding R2D control information, e.g. Msg1, 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. 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 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.

3GPP TSG-RAN WG1 Meeting #120bis	      R1-2502498 
Wuhan, China, April 7th – 11th, 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: RAN1 does not specify TD2R_max as a requirement for device
TD2R_max refers to the maximum time interval from the end of a D2R transmission to the start of the corresponding R2D transmission following it.

Detailed values
[3]: The value of  can be derived from  and the applicable values of c and  can be further discussed.
[5]: RAN1 should discuss whether we use the fixed timing values or use the RFID approach that defining the timings based on the counterpart analogous to Tpri = 1/BLF.  
[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.
Given above, following question is asked.
[Low] FL1 Question 4.2-3
If the timing of TD2R_min and/or TD2R_max need to be specified for an A-IoT device, which option should be adopted for specifying the timing(s) in RAN1?
Option 1: fixed values 
Option 2: based on OOK chip duration.
FFS the OOK chip duration. 
Note if Option 2 is preferred, what is your views for above FFS chip duration in Option 2, for example, the shortest R2D chip duration in the specification, or the R2D and/or D2R chip duration used for the corresponding transmissions etc.   

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.
[3], [5] proposed to keep this parameter open for now, maybe RAN1 needs to wait RAN2’s progress on message type and check whether there is valid scenario or not.
[7], [22] proposed it is necessary 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. 
In addition, [3], [22] proposed that there is no need to define TR2D_R2D_max, given that R2D transmission can occur at any time.    
Based on above, FL proposed to keep this parameter open for now and suggest companies to check whether there is valid scenarios for specifying this timing or not.
[Low] FL1 Question 4.4-1
If applicable, under what scenarios should TR2D_R2D_min be specified?
TR2D_R2D_min is the minimum time between two different consecutive R2D transmissions to the same A-IoT device.

For the time interval between two different consecutive D2R transmissions from the same A-IoT device, TD2R_D2R_min is defined as minimum time between two different consecutive D2R transmissions from the same A-IoT device. 
[3], [5], [7], [22], [34] are unable to identify any scenarios related to TD2R_D2R_min.
Maybe no need to make agreement or conclusion in the WI for something that we do not support.  
Scheduling information
For R2D reception  
The agreements related to ID and Message Type made by RAN2#129 can be found in Annex B RAN2#129. 
As observed by [27] that the “ID(s) associated with one or more devices” may be of different types in different R2D transmissions based on RAN2#129 meeting agreements, and as such it cannot be handled as L1 control information. For example, RAN2 current assumption for paging identifier is it is transparent to the A-IoT MAC Layer and carried by upper layer. An “AS ID” after contention is resolve can be used in an R2D transmission for scheduling a D2R transmission for a device. Therefore, for ID and Message type, RAN2 will continue the discussion and these aspects will be deprioritized for this RAN1 meeting. 

PRDCH chip duration
Option 1: Same as clock-acquisition part of the R2D preamble [1], [3], [5], [7], [9], [10], [21], [22], [23], [24]
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
[31]: For flexibility, CAP indicates M for R2D L1 control and R2D L1 control indicates M value for R2D data.
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]
Considering above, following proposal can be considered 
[High] 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.

End identification of PRDCH
As coordinated with AI 9.4.3 FL, the options on determining the end of PRDCH will be discussed in AI 9.4.3. 


For D2R transmission   
The discussions on frequency domain resource allocation is summarized in section 3.2.2 and section 3.2.3.
Many companies provide the signaling details without differentiating D2R transmission types, such as Msg1, Msg3 or D2R data.
While [5] proposed scheduling indication separately for Msg1, Msg3 or D2R data as below.
Scheduling information in [5] for Msg1 transmission

Scheduling information in [5] for Msg3 transmission

Scheduling information in [5] for Msgs except Msg1 and Msg3 transmission


[30]: Discussed separate or common fields for D2R Msg1, Msg3 and D2R data
Table 4.1 R2D control for R2D/D2R scheduling [30]

[10] observed that for the same field e.g., small frequency shift, different design can be considered for different D2R transmission types, e.g., bitmap-based small frequency shift for Msg1 and code-point based small frequency shift for Msg3 and other D2R transmissions.  
Less companies share the views on other PDRCH scheduling except Msg1 and Msg3 transmission, whether the scheduling information always re-use the ones used for Msg1 transmission, if some scheduling information for other PDRCH transmission always reuse the ones used for Msg1, then the indication for the scheduling information is not needed in the PRDCH.  
[Medium] FL Question 5.2-1
For other PDRCH scheduling except Msg1 and Msg3 transmission, for the following information except the PDRCH payload size that needs to be indicated, which option do you prefer? 
D2R chip duration
Frequency domain resource
FEC related information 
Number of Repetitions
Midamble related information, if any 

Option 1: all above information is indicated by the corresponding PRDCH. 
Option 2: all above information always re-use the ones for Msg1, no indication is needed in the corresponding PRDCH.
Option 3: some information is indicated by the corresponding PRDCH, while some always re-use the ones for Msg1. 
For Option 3, please indicate which information needs indication and which reuse the ones for Msg1 transmission. 
 
Following agreement was made in RAN1#120 meeting.
[3], [5], [7], [8], [10], [18], [22], [24], [25], [30], [31] proposed to support TBS indication with the following details:
[5], [10] considers 7 bits for byte-level TBS indication to cover 1000 bits.
[7] proposed 3-bit indication with which TBS is jointly coded with TTI and M, as shown in Table 6.
Table 6: The TBS table for PDRCH (3 bits TBS indication) in [7]

[10] proposed X-bit (X<=7) code-point based indication, where each code-point indicates one size from 2x predefined D2R payload sizes for indicating the typical TBS sizes, to save overhead and with better TBS granularity.     
Based on above, the following proposal is made.
[Medium] FL1 Proposal 5.2-2 
Down-select from the following options for indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size: 
Option 1: 7 bits for byte-level D2R payload size indication
Option 2: X-bit (1<=X<=7) codepoint based indication, where each codepoint indicates one size from 2x predefined D2R payload sizes.
For above proposal, please also indicate which option you prefer to facilitate the down-selection. 

The indication for the following fields depend on the progress in AI 9.4.1, 9.4.2 and 9.4.3. Depending one the progress, we can decide to discuss those fields during this meeting.  
Enable/disable the use of FEC and the supported coding rate in AI 9.4.2 
The supported number of Repetitions in AI 9.4.2  
Preamble/Midamble details including the amble length/configurations and location(s) in AI 9.4.3

For reference, companies’ views on above parameters are briefly captured as following. 
Enable/disable the use of FEC and the supported coding rate
[3], [5], [7], [9], [10] proposed 1-bit indication on whether apply FEC
[1], [3], [4], [34] proposed indication of code rate
[3] joint indication of CC rate and repetition times as shown in Table 5 and consider that indication of repetition can be part of MCS
Table 5: Code rates and repetitions table (2 bits indication) in [3]


Information related to Repetitions
[3], [4], [5], [6], [7], [9], [10], [12], [16], [20], [25], [28], [31], [34] proposed that repetition times is provided to device
[10] [24] only support block level repetition, no need to indicate type
[16] suggest to further discuss if/how the preamble should be repeated when the PDRCH is repeated.

Information related to Midamble and Preamble
[3] [5] If multiple lengths of preamble are supported, the length of preamble should be indicated
Can be jointly indicated with midamble information [3]
[3], [4], [5], [6], [9], [10], [11], [18], [20], [22], [23], [25], [28], [31] proposed to indicate the midamble information with the following details:
[3], [9], [20] number of midambles
[3], [4], [18], [20] Length of midambles
[4], [10], [18],[23] Location of midamble
Alternatively, [4], [18] proposed to introduce predefined rules for determining the midamble:
[18]
Option 1: pre-defined chip number/TBS threshold (aforementioned every K chips/bits/symbols insertion)
Option 2: pre-defined timing error threshold; 
Option 3: the boundary of each repetition when repetition indicated;
[4]: a criteria on determining how to place midamble in D2R transmission may be indicated by reader. Wherein, the criteria, for example, may be a length threshold of D2R transmission, which is defined as that each segment of D2R transmission is no longer than the length threshold.  
 

[Low] FL1 Proposal 5.2-3 
Down-select from the following options for indicating the the FEC and the number of repetition(s) for PDRCH transmission in the corresponding PRDCH:
Option 1: Separate indication of FEC and number of repetitions  
Option 2: joint indication of FEC and number of repetitions  
For above proposal, please also indicate which option you prefer to facilitate the down-selection. 

Container of R2D Control information
For transmission of R2D control information for R2D reception and D2R scheduling, following was agreed in RAN1#118bis meeting.
 
For D2R scheduling, the scheduling information should be carried by
High layer signaling: supported by [1], [3], [5], [9], [10], [11], [12], [20], [22], [23], [24], [31] 
No compelling reason to support R2D L1 control since device transmits PDRCH after fully reception of PRDCH, early preparation of PDRCH is not needed  
Avoids physical layer design, specification, and implementation effort, while at the same time offering flexibility in terms of the size of the grant.
R2D L1 control signaling: supported by [4], [25], [28], [36]
Early preparation of PDRCH  
Some scheduling information such as time/frequency domain resource are conveyed via L1 signaling, while fields such as D2R chip duration, repetition, amble related information are conveyed via higher-layer signaling: supported by [32]
Considering above, following proposal can be considered 
[High] FL1 Proposal 5.3-1 
For D2R scheduling, higher-layer signaling is used to indicate at least the following information to the device via corresponding PRDCH.
Payload size (i.e. TBS-like) for PDRCH transmission with variable size
D2R chip duration
Frequency domain resource
FEC related information 
Number of Repetitions
Midamble related information, if any  

[9] proposed to send LS to RAN2 to include the related information that are carried by higher layer. Therefore, following question is asked.    
[High] FL1 Question 5.3-2 
Do you support to send LS to RAN2 to include the related information for D2R scheduling that are carried by higher layer?


For R2D reception, 
[10] does not see any R2D control information is needed for PRDCH reception, given MAC header indicates message type, length for SDU and variable part(s) 
[20] observed that whether scheduling information is required depends on whether higher-layer signaling and/or L1 R2D control signaling is used for carrying ID associated with device(s).
[27] observed whether scheduling information is required depends on whether R2D TBS is indicated by R2D control information. 
In case there is any explicit scheduling information agreed for R2D reception, 
On Separate CRC vs. Joint CRC for the scheduled information, 
[6], [8], [12], [15], [19], [21], [22], [23], [30], [31], [34] support separate CRC 
[6], [15], [21], [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], [12?], [19] discussed another motivation is for different reliability between the R2D control and data.
While [1], [10], [27] observed that the R2D control information of “ID” and “message type” that included as part of higher layer (see Annex B RAN2#129 agreement), the device still needs to receive the entire PRDCH, hence the functionality of “early identification or termination” during R2D reception is not a compelling reason to support defining L1 R2D control information. 
[1] proposed to support L1 common control information that sent as a separate PRDCH transmission that precedes Msg2 to achieve the early detection and termination purpose. 
[2], [3?], [5], [7] support joint CRC, and observed following drawbacks for separate CRC: 
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'.

To avoid blind detection or introduction of multiple 'DCI', following options proposed for identification of the R2D L1 control information with separate CRC
[8]: The L1 control information includes multiple control information fields with a specific size.
[15], [22], [24]: The L1 R2D control information should have a fixed size and attached with a separate CRC. 
[24] An explicit indicator by this R2D transmission or a previous R2D transmission is adopted to inform the device whether L1 control signaling is contained in the R2D transmission.
Besides PRDCH TBS determination (R2D postamble vs. Indicated by R2D control information), it is not clear at this stage whether there is any other explicit scheduling information needed for R2D reception that within RAN1’s expertise/scope (Note that ID(s) associated with one or more devices, Transaction ID, message type etc should be decided by RAN2). 
[Medium] FL1 Question 5.3-3 
Besides the PRDCH TBS determination (R2D postamble vs. R2D control information), which will be decided in AI 9.4.3, is there any other scheduling information within RAN1’s expertise/scope needed for R2D reception? 


D2R Control information 
ACK/NACK feedback
[6], [22], [26], [30], [31], [32], [36]: Support ACK/NACK feedback in D2R for correctly or incorrectly receiving the PRDCH reception.
[6]: carrying ACK/NACK in L1 control can save decoding time, although there is not much difference between carrying it in L1 control or high-layer signaling. 
[22]: ACK/NACK feedback in D2R is via higher-layer signaling.
[31]: FFS whether the ACK/NACK feedback is L1 D2R information or higher layer D2R information. 
[1], [10]: RAN1 will not discuss ACK/NACK as L1 D2R control information in Rel-19 A-IoT unless requested by RAN2  
The objective of “data (re-)transmission for failure handling” is within RAN2’s scope (RP-243326)

As we discussed in the last RAN1#120 meeting, RAN2 should lead the discussion and make the decision for failure handling. Considering other more important RAN1 issues and the limited time, the discussion on ACK/NACK feedback is deprioritized for this meeting. 

Other D2R control information
D2R control information indicating the Actual TBS of D2R transmission
[22], [30] discussed that case where device may transmit a smaller TBS than the allocated resource when reader may not have precise information on the buffered data volume at the device [22], or when device has no sufficient power to complete the D2R transmission indicated by R2D [30]. To inform the reader of the actual transmitted PDRCH, the following two alternatives can be studied:
Alt1: explicitly indicate transmitted TBS within allocated PDRCH resources [22], [30]
Alt2: implicitly indicate transmitted TBS by the number of data blocks. Device divides the D2R data into multiple blocks, each with a separate CRC [30]

“ID” indication in D2R control information
[22] proposed that device provides the transmitting device ID and the intended receiving reader ID for a reader to identify the intended transmission and reception.

“Inability” indication in D2R control information
[15]: 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.

Others 
Device availability/ un-availability and Proximity determination are deprirotized for this meeting. 
Additionally,
[4] proposed to discuss the monitoring window for Msg4 reception considering the Msg3 multiplexing cases. 
[7]: proposed 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.
[7]: proposed the segment information, such as segment IDs, or a bitmap, should be included in the MAC layer of R2D signal scheduling the retransmission of Msg3 if the Msg3 is segmented.
[9] proposed parallel querying in each scheduling decision window can be adopted to improve inventory efficiency when scheduling decision window exists due to scheduling restriction of gNB.
[9] proposed one R2D message (Msg4) informing the ACK/NACK information of all the Msg3 occasions can be studied.
[12] proposed to conclude
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.
No specification effort will be taken in Rel-19 to support direction 1 as a solution for device (un)availability.
[20] proposed following:
Introduce a R2D command like “QueryAdjust” in RFID from RAN1 perspective and include the scheduling information to adjust the number of candidate frequency/time domain resources in a single access occasion.  
For contention-free access, the reader can indicate separate time/frequency domain resource(s) associated with the ID(s) of device(s) for the D2R time/frequency resource indication and determination.
[22] proposed the PRDCH triggering random access provides additional information related to random access including 1) access control parameters, 2) information to prevent a duplicated response from a device, 3) count for the remaining random access rounds, and 4) parameters facilitating the device dormancy.  
[22] proposed A-IoT devices are assigned a default frequency resource for A-IoT paging reception and the default frequency resource for A-IoT paging reception is stored in NVM of the devices.
[25]: proposed following for forward compatibility consideration: 
whether/how Rel-19 device can make an access to Rel-20 reader can be discussed in Rel-20, not in Rel-19.
RAN1 can discuss whether/how Rel-19 readers avoid or control accesses from Rel-20 devices during Rel-19 work.

Proposals for offline discussions

Proposals for April 8 Offline

Encourage companies to check the evaluation results summarized in section 3.1.1.  
FL suggestion:
Option 2: Only support X=1 time domain resource for D2R transmission for Msg1 that determined by a R2D transmission triggering random access in Rel-19. 

[High] FL1 Proposal 3.1-2a 
Down-select from the following options
Option 1: Support X=1 and X=2 time domain resource(s) for D2R transmission(s) for Msg1 only that determined by a R2D transmission triggering random access, where each D2R transmission for Msg1 occurs in one time domain resource of the X time domain resource(s) in Rel-19.
FFS the maximum time that device 1 is able to count as an requirement. 

Option 2: Only support X=1 time domain resource for D2R transmission for Msg1 that determined by a R2D transmission triggering random access in Rel-19. 

Option 3: Support X=1 and X=2 time domain resource(s) for D2R transmission(s) for Msg1 only that determined by a R2D transmission triggering random access, where each D2R transmission for Msg1 occurs in one time domain resource of the X time domain resource(s) in Rel-19.
It is up to device implementation to support X>1
For device that is not capable of supporting X>1, it always selects the 1st time domain resource for Msg1 transmission.
For device that is capable of supporting X>1, it randomly selects one time domain resource between the two time domain resources for Msg1 transmission  


[High] FL1 Proposal 3.3-1a
After the minimum Tx-to-Rx time of the Msg1 transmission, the device starts  the PRDCH for Msg2.


R2D transmission/response timing

[High] FL1 Proposal 4.3-1a
TD2R_min is specified as the minimum time interval from the end of a D2R transmission to the start of the corresponding R2D transmission following it, from device’s perspective.
A device is not expected to  a corresponding R2D transmission earlier than TD2R_min after the end of  a D2R transmission. 
After TD2R_min of the end of a D2R transmission, the device shall  the corresponding R2D transmission.



Timing relations 
[High] FL1 Proposal 4.1-1
If any timing requirement(s) need to be specified from device perspective, the timing(s) do not include the impacts of SFO from the RAN1 perspective.
Whether 3GPP needs to specify some requirement on device’s SFO is up to RAN4 discussion.


D2R transmission/response timing

[High] FL1 Proposal 4.2-1a
T1 is specified as the maximum time interval from the end of a R2D transmission to the start of the corresponding D2R transmission following it, from device perspective.
The device starts the corresponding D2R transmission no later than T1 after it receives a R2D transmission.
Note whether T1 is named as TR2D_max or TR2D_nominal or others is up to editor.

Samsung: better to use another terminology different from T1
HW: separate the discussion for option 1 and option 2
QC and others: first bullet and second bullet have some conflict. 

For option 1 that define a maximum time TR2D_max between a R2D transmission and the corresponding D2R transmission following it, so that the device transmits D2R transmission within [TR2D_min, TR2D_max], 
TR2D_max is specified as the maximum time interval from the end of a R2D transmission to the start of the corresponding D2R transmission following it, from device perspective.
The device starts the corresponding D2R transmission no later than TR2D_max after it receives a R2D transmission.

For option 2 that the corresponding D2R transmission timing TR2D following a R2D transmission is determined based on the control information in the R2D transmission, where TR2D  TR2D_min
TR2D_min is specified as the minimum time interval from the end of a R2D transmission to the start of the corresponding D2R transmission following it, from device perspective.
A device is not expected to be indicated to start a corresponding D2R transmission earlier than TR2D_min after the end of a R2D transmission.


[High] FL1 Proposal 5.3-1a 
For D2R scheduling, if a scheduling information is explicitly indicated, it is carried by higher layer signalling instead of L1 R2D control signalling.
[e.g., The payload size (i.e. TBS-like) for PDRCH transmission with variable size, D2R chip duration etc.]

[High] FL1 Proposal 3.4-1a
At least support case 3 of interleaved Msg3 transmissions between different Msg2 (e.g., Msg2-Msg3-Msg2-Msg3), where the PRDCH for Msg2 transmission and the corresponding Msg3 are sent one by one. 

Agreements achieved in RAN1#120bis meeting

3GPP TSG-RAN WG1 Meeting #120bis	     R1-2502499 
Wuhan, China, April 7th – 11th, 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: RAN1 does not specify TD2R_max as a requirement for device
TD2R_max refers to the maximum time interval from the end of a D2R transmission to the start of the corresponding R2D transmission following it.

Detailed values
[3]: The value of  can be derived from  and the applicable values of c and  can be further discussed.
[5]: RAN1 should discuss whether we use the fixed timing values or use the RFID approach that defining the timings based on the counterpart analogous to Tpri = 1/BLF.  
[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.
Given above, following question is asked.
[Close][Low] FL1 Question 4.2-3
If the timing of TD2R_min and/or TD2R_max need to be specified for an A-IoT device, which option should be adopted for specifying the timing(s) in RAN1?
Option 1: fixed values 
Option 2: based on OOK chip duration.
FFS the OOK chip duration. 
Note if Option 2 is preferred, what is your views for above FFS chip duration in Option 2, for example, the shortest R2D chip duration in the specification, or the R2D and/or D2R chip duration used for the corresponding transmissions etc.   

For 2nd Round discussion
[Open][High] FL2 Proposal 4.3-1a
A device is not expected to monitor a corresponding R2D transmission earlier than TD2R_min after the end of  a D2R transmission from the device. 
For other D2R transmission except for Msg1, after TD2R_min of the end of a D2R transmission from a device, the device shall monitor the corresponding R2D transmission.
For Msg1 transmission, 
Option 1: after TD2R_min of the end of a D2R transmission from a device, the device shall monitor the corresponding R2D transmission.
Option 2: after TD2R_min of the end of the last D2R time domain resource, the device shall monitor the corresponding R2D transmission.
Note: Whether device starts monitoring start of R2D earlier than TD2R_min after the end of the last D2R time domain resource(s) is up to device implementation. 
Option 3: for device that is not capable of supporting X>1, support option 1; for device that capable of supporting X>1, support option 2. 




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.
[3], [5] proposed to keep this parameter open for now, maybe RAN1 needs to wait RAN2’s progress on message type and check whether there is valid scenario or not.
[7], [22] proposed it is necessary 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. 
In addition, [3], [22] proposed that there is no need to define TR2D_R2D_max, given that R2D transmission can occur at any time.    
Based on above, FL proposed to keep this parameter open for now and suggest companies to check whether there is valid scenarios for specifying this timing or not.
[Low] FL1 Question 4.4-1
If applicable, under what scenarios should TR2D_R2D_min be specified?
TR2D_R2D_min is the minimum time between two different consecutive R2D transmissions to the same A-IoT device.

For the time interval between two different consecutive D2R transmissions from the same A-IoT device, TD2R_D2R_min is defined as minimum time between two different consecutive D2R transmissions from the same A-IoT device. 
[3], [5], [7], [22], [34] are unable to identify any scenarios related to TD2R_D2R_min.
Maybe no need to make agreement or conclusion in the WI for something that we do not support.  
Scheduling information
For R2D reception  
The agreements related to ID and Message Type made by RAN2#129 can be found in Annex B RAN2#129. 
As observed by [27] that the “ID(s) associated with one or more devices” may be of different types in different R2D transmissions based on RAN2#129 meeting agreements, and as such it cannot be handled as L1 control information. For example, RAN2 current assumption for paging identifier is it is transparent to the A-IoT MAC Layer and carried by upper layer. An “AS ID” after contention is resolve can be used in an R2D transmission for scheduling a D2R transmission for a device. Therefore, for ID and Message type, RAN2 will continue the discussion and these aspects will be deprioritized for this RAN1 meeting. 

PRDCH chip duration
Option 1: Same as clock-acquisition part of the R2D preamble [1], [3], [5], [7], [9], [10], [21], [22], [23], [24]
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
[31]: For flexibility, CAP indicates M for R2D L1 control and R2D L1 control indicates M value for R2D data.
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]
Considering above, following proposal can be considered 
[Close][High] 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.

End identification of PRDCH
As coordinated with AI 9.4.3 FL, the options on determining the end of PRDCH will be discussed in AI 9.4.3. 


For D2R transmission   
The discussions on frequency domain resource allocation is summarized in section 3.2.2 and section 3.2.3.
Many companies provide the signaling details without differentiating D2R transmission types, such as Msg1, Msg3 or D2R data.
While [5] proposed scheduling indication separately for Msg1, Msg3 or D2R data as below.
Scheduling information in [5] for Msg1 transmission

Scheduling information in [5] for Msg3 transmission

Scheduling information in [5] for Msgs except Msg1 and Msg3 transmission


[30]: Discussed separate or common fields for D2R Msg1, Msg3 and D2R data
Table 4.1 R2D control for R2D/D2R scheduling [30]

[10] observed that for the same field e.g., small frequency shift, different design can be considered for different D2R transmission types, e.g., bitmap-based small frequency shift for Msg1 and code-point based small frequency shift for Msg3 and other D2R transmissions.  
Less companies share the views on other PDRCH scheduling except Msg1 and Msg3 transmission, whether the scheduling information always re-use the ones used for Msg1 transmission, if some scheduling information for other PDRCH transmission always reuse the ones used for Msg1, then the indication for the scheduling information is not needed in the PRDCH.  
[Close][Medium] FL Question 5.2-1
For other PDRCH scheduling except Msg1 and Msg3 transmission, for the following information except the PDRCH payload size that needs to be indicated, which option do you prefer? 
D2R chip duration
Frequency domain resource
FEC related information 
Number of Repetitions
Midamble related information, if any 

Option 1: all above information is indicated by the corresponding PRDCH. 
Option 2: all above information always re-use the ones for Msg1, no indication is needed in the corresponding PRDCH.
Option 3: some information is indicated by the corresponding PRDCH, while some always re-use the ones for Msg1. 
For Option 3, please indicate which information needs indication and which reuse the ones for Msg1 transmission. 
 
Following agreement was made in RAN1#120 meeting.
[3], [5], [7], [8], [10], [18], [22], [24], [25], [30], [31] proposed to support TBS indication with the following details:
[5], [10] considers 7 bits for byte-level TBS indication to cover 1000 bits.
[7] proposed 3-bit indication with which TBS is jointly coded with TTI and M, as shown in Table 6.
Table 6: The TBS table for PDRCH (3 bits TBS indication) in [7]

[10] proposed X-bit (X<=7) code-point based indication, where each code-point indicates one size from 2x predefined D2R payload sizes for indicating the typical TBS sizes, to save overhead and with better TBS granularity.     
Based on above, the following proposal is made.
[Close][Medium] FL1 Proposal 5.2-2 
Down-select from the following options for indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size: 
Option 1: 7 bits for byte-level D2R payload size indication
Option 2: X-bit (1<=X<=7) codepoint based indication, where each codepoint indicates one size from 2x predefined D2R payload sizes.
For above proposal, please also indicate which option you prefer to facilitate the down-selection. 

The indication for the following fields depend on the progress in AI 9.4.1, 9.4.2 and 9.4.3. Depending one the progress, we can decide to discuss those fields during this meeting.  
Enable/disable the use of FEC and the supported coding rate in AI 9.4.2 
The supported number of Repetitions in AI 9.4.2  
Preamble/Midamble details including the amble length/configurations and location(s) in AI 9.4.3

For reference, companies’ views on above parameters are briefly captured as following. 
Enable/disable the use of FEC and the supported coding rate
[3], [5], [7], [9], [10] proposed 1-bit indication on whether apply FEC
[1], [3], [4], [34] proposed indication of code rate
[3] joint indication of CC rate and repetition times as shown in Table 5 and consider that indication of repetition can be part of MCS
Table 5: Code rates and repetitions table (2 bits indication) in [3]


Information related to Repetitions
[3], [4], [5], [6], [7], [9], [10], [12], [16], [20], [25], [28], [31], [34] proposed that repetition times is provided to device
[10] [24] only support block level repetition, no need to indicate type
[16] suggest to further discuss if/how the preamble should be repeated when the PDRCH is repeated.

Information related to Midamble and Preamble
[3] [5] If multiple lengths of preamble are supported, the length of preamble should be indicated
Can be jointly indicated with midamble information [3]
[3], [4], [5], [6], [9], [10], [11], [18], [20], [22], [23], [25], [28], [31] proposed to indicate the midamble information with the following details:
[3], [9], [20] number of midambles
[3], [4], [18], [20] Length of midambles
[4], [10], [18],[23] Location of midamble
Alternatively, [4], [18] proposed to introduce predefined rules for determining the midamble:
[18]
Option 1: pre-defined chip number/TBS threshold (aforementioned every K chips/bits/symbols insertion)
Option 2: pre-defined timing error threshold; 
Option 3: the boundary of each repetition when repetition indicated;
[4]: a criteria on determining how to place midamble in D2R transmission may be indicated by reader. Wherein, the criteria, for example, may be a length threshold of D2R transmission, which is defined as that each segment of D2R transmission is no longer than the length threshold.  
 

[Close][Low] FL1 Proposal 5.2-3 
Down-select from the following options for indicating the the FEC and the number of repetition(s) for PDRCH transmission in the corresponding PRDCH:
Option 1: Separate indication of FEC and number of repetitions  
Option 2: joint indication of FEC and number of repetitions  
For above proposal, please also indicate which option you prefer to facilitate the down-selection. 

Container of R2D Control information
For transmission of R2D control information for R2D reception and D2R scheduling, following was agreed in RAN1#118bis meeting.
 
For D2R scheduling, the scheduling information should be carried by
High layer signaling: supported by [1], [3], [5], [9], [10], [11], [12], [20], [22], [23], [24], [31] 
No compelling reason to support R2D L1 control since device transmits PDRCH after fully reception of PRDCH, early preparation of PDRCH is not needed  
Avoids physical layer design, specification, and implementation effort, while at the same time offering flexibility in terms of the size of the grant.
R2D L1 control signaling: supported by [4], [25], [28], [36]
Early preparation of PDRCH  
Some scheduling information such as time/frequency domain resource are conveyed via L1 signaling, while fields such as D2R chip duration, repetition, amble related information are conveyed via higher-layer signaling: supported by [32]
Considering above, following proposal can be considered 
[Close][High] FL1 Proposal 5.3-1 
For D2R scheduling, higher-layer signaling is used to indicate at least the following information to the device via corresponding PRDCH.
Payload size (i.e. TBS-like) for PDRCH transmission with variable size
D2R chip duration
Frequency domain resource
FEC related information 
Number of Repetitions
Midamble related information, if any  

[9] proposed to send LS to RAN2 to include the related information that are carried by higher layer. Therefore, following question is asked.    
[Close][High] FL1 Question 5.3-2 
Do you support to send LS to RAN2 to include the related information for D2R scheduling that are carried by higher layer?


For R2D reception, 
[10] does not see any R2D control information is needed for PRDCH reception, given MAC header indicates message type, length for SDU and variable part(s) 
[20] observed that whether scheduling information is required depends on whether higher-layer signaling and/or L1 R2D control signaling is used for carrying ID associated with device(s).
[27] observed whether scheduling information is required depends on whether R2D TBS is indicated by R2D control information. 
In case there is any explicit scheduling information agreed for R2D reception, 
On Separate CRC vs. Joint CRC for the scheduled information, 
[6], [8], [12], [15], [19], [21], [22], [23], [30], [31], [34] support separate CRC 
[6], [15], [21], [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], [12?], [19] discussed another motivation is for different reliability between the R2D control and data.
While [1], [10], [27] observed that the R2D control information of “ID” and “message type” that included as part of higher layer (see Annex B RAN2#129 agreement), the device still needs to receive the entire PRDCH, hence the functionality of “early identification or termination” during R2D reception is not a compelling reason to support defining L1 R2D control information. 
[1] proposed to support L1 common control information that sent as a separate PRDCH transmission that precedes Msg2 to achieve the early detection and termination purpose. 
[2], [3?], [5], [7] support joint CRC, and observed following drawbacks for separate CRC: 
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'.

To avoid blind detection or introduction of multiple 'DCI', following options proposed for identification of the R2D L1 control information with separate CRC
[8]: The L1 control information includes multiple control information fields with a specific size.
[15], [22], [24]: The L1 R2D control information should have a fixed size and attached with a separate CRC. 
[24] An explicit indicator by this R2D transmission or a previous R2D transmission is adopted to inform the device whether L1 control signaling is contained in the R2D transmission.
Besides PRDCH TBS determination (R2D postamble vs. Indicated by R2D control information), it is not clear at this stage whether there is any other explicit scheduling information needed for R2D reception that within RAN1’s expertise/scope (Note that ID(s) associated with one or more devices, Transaction ID, message type etc should be decided by RAN2). 
[Close][Medium] FL1 Question 5.3-3 
Besides the PRDCH TBS determination (R2D postamble vs. R2D control information), which will be decided in AI 9.4.3, is there any other scheduling information within RAN1’s expertise/scope needed for R2D reception? 

For 2nd Round discussion
Summary for the 1st Round discussion 
Samsung, HW think based on RAN2’s agreements, no further information will be needed for R2D reception. 
QC, LG, ZTE, HONOR think it is RAN1’s expertise/scope to discuss what/whether to include the information for early indication/termination, and whether to use a CRC separate from MAC PDU.  
@all, please check the agreements made in RAN2#129 meeting on MAC PDU format design, paging ID, AS ID, Transaction ID, pasted in the Annex B.
[Open][High] FL2 Question 5.3-3a 
Is it essential for device 1 to achieve early identification/termination for R2D reception? 
If your reply is Yes, please explain the reason and how RAN1 can achieve the early identification/termination with taking into account RAN2’s agreement.  
If your reply is No, please explain the reason. 


D2R Control information 
ACK/NACK feedback
[6], [22], [26], [30], [31], [32], [36]: Support ACK/NACK feedback in D2R for correctly or incorrectly receiving the PRDCH reception.
[6]: carrying ACK/NACK in L1 control can save decoding time, although there is not much difference between carrying it in L1 control or high-layer signaling. 
[22]: ACK/NACK feedback in D2R is via higher-layer signaling.
[31]: FFS whether the ACK/NACK feedback is L1 D2R information or higher layer D2R information. 
[1], [10]: RAN1 will not discuss ACK/NACK as L1 D2R control information in Rel-19 A-IoT unless requested by RAN2  
The objective of “data (re-)transmission for failure handling” is within RAN2’s scope (RP-243326)

As we discussed in the last RAN1#120 meeting, RAN2 should lead the discussion and make the decision for failure handling. Considering other more important RAN1 issues and the limited time, the discussion on ACK/NACK feedback is deprioritized for this meeting. 

Other D2R control information
D2R control information indicating the Actual TBS of D2R transmission
[22], [30] discussed that case where device may transmit a smaller TBS than the allocated resource when reader may not have precise information on the buffered data volume at the device [22], or when device has no sufficient power to complete the D2R transmission indicated by R2D [30]. To inform the reader of the actual transmitted PDRCH, the following two alternatives can be studied:
Alt1: explicitly indicate transmitted TBS within allocated PDRCH resources [22], [30]
Alt2: implicitly indicate transmitted TBS by the number of data blocks. Device divides the D2R data into multiple blocks, each with a separate CRC [30]

“ID” indication in D2R control information
[22] proposed that device provides the transmitting device ID and the intended receiving reader ID for a reader to identify the intended transmission and reception.

“Inability” indication in D2R control information
[15]: 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.

Others 
Device availability/ un-availability and Proximity determination are deprirotized for this meeting. 
Additionally,
[4] proposed to discuss the monitoring window for Msg4 reception considering the Msg3 multiplexing cases. 
[7]: proposed 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.
[7]: proposed the segment information, such as segment IDs, or a bitmap, should be included in the MAC layer of R2D signal scheduling the retransmission of Msg3 if the Msg3 is segmented.
[9] proposed parallel querying in each scheduling decision window can be adopted to improve inventory efficiency when scheduling decision window exists due to scheduling restriction of gNB.
[9] proposed one R2D message (Msg4) informing the ACK/NACK information of all the Msg3 occasions can be studied.
[12] proposed to conclude
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.
No specification effort will be taken in Rel-19 to support direction 1 as a solution for device (un)availability.
[20] proposed following:
Introduce a R2D command like “QueryAdjust” in RFID from RAN1 perspective and include the scheduling information to adjust the number of candidate frequency/time domain resources in a single access occasion.  
For contention-free access, the reader can indicate separate time/frequency domain resource(s) associated with the ID(s) of device(s) for the D2R time/frequency resource indication and determination.
[22] proposed the PRDCH triggering random access provides additional information related to random access including 1) access control parameters, 2) information to prevent a duplicated response from a device, 3) count for the remaining random access rounds, and 4) parameters facilitating the device dormancy.  
[22] proposed A-IoT devices are assigned a default frequency resource for A-IoT paging reception and the default frequency resource for A-IoT paging reception is stored in NVM of the devices.
[25]: proposed following for forward compatibility consideration: 
whether/how Rel-19 device can make an access to Rel-20 reader can be discussed in Rel-20, not in Rel-19.
RAN1 can discuss whether/how Rel-19 readers avoid or control accesses from Rel-20 devices during Rel-19 work.

Proposals for offline discussions

Proposals for April 8 Offline

Encourage companies to check the evaluation results summarized in section 3.1.1.  
FL suggestion:
Option 2: Only support X=1 time domain resource for D2R transmission for Msg1 that determined by a R2D transmission triggering random access in Rel-19. 

[High] FL1 Proposal 3.1-2a 
Down-select from the following options
Option 1: Support X=1 and X=2 time domain resource(s) for D2R transmission(s) for Msg1 only that determined by a R2D transmission triggering random access, where each D2R transmission for Msg1 occurs in one time domain resource of the X time domain resource(s) in Rel-19.
FFS the maximum time that device 1 is able to count as an requirement. 

Option 2: Only support X=1 time domain resource for D2R transmission for Msg1 that determined by a R2D transmission triggering random access in Rel-19. 

Option 3: Support X=1 and X=2 time domain resource(s) for D2R transmission(s) for Msg1 only that determined by a R2D transmission triggering random access, where each D2R transmission for Msg1 occurs in one time domain resource of the X time domain resource(s) in Rel-19.
It is up to device implementation to support X>1
For device that is not capable of supporting X>1, it always selects the 1st time domain resource for Msg1 transmission.
For device that is capable of supporting X>1, it randomly selects one time domain resource between the two time domain resources for Msg1 transmission  


[High] FL1 Proposal 3.3-1a
After the minimum Tx-to-Rx time of the Msg1 transmission, the device starts  the PRDCH for Msg2.


R2D transmission/response timing

[High] FL1 Proposal 4.3-1a
TD2R_min is specified as the minimum time interval from the end of a D2R transmission to the start of the corresponding R2D transmission following it, from device’s perspective.
A device is not expected to  a corresponding R2D transmission earlier than TD2R_min after the end of  a D2R transmission. 
After TD2R_min of the end of a D2R transmission, the device shall  the corresponding R2D transmission.



Timing relations 
[High] FL1 Proposal 4.1-1
If any timing requirement(s) need to be specified from device perspective, the timing(s) do not include the impacts of SFO from the RAN1 perspective.
Whether 3GPP needs to specify some requirement on device’s SFO is up to RAN4 discussion.


D2R transmission/response timing

[High] FL1 Proposal 4.2-1a
T1 is specified as the maximum time interval from the end of a R2D transmission to the start of the corresponding D2R transmission following it, from device perspective.
The device starts the corresponding D2R transmission no later than T1 after it receives a R2D transmission.
Note whether T1 is named as TR2D_max or TR2D_nominal or others is up to editor.

Samsung: better to use another terminology different from T1
HW: separate the discussion for option 1 and option 2
QC and others: first bullet and second bullet have some conflict. 

For option 1 that define a maximum time TR2D_max between a R2D transmission and the corresponding D2R transmission following it, so that the device transmits D2R transmission within [TR2D_min, TR2D_max], 
TR2D_max is specified as the maximum time interval from the end of a R2D transmission to the start of the corresponding D2R transmission following it, from device perspective.
The device starts the corresponding D2R transmission no later than TR2D_max after it receives a R2D transmission.

For option 2 that the corresponding D2R transmission timing TR2D following a R2D transmission is determined based on the control information in the R2D transmission, where TR2D  TR2D_min
TR2D_min is specified as the minimum time interval from the end of a R2D transmission to the start of the corresponding D2R transmission following it, from device perspective.
A device is not expected to be indicated to start a corresponding D2R transmission earlier than TR2D_min after the end of a R2D transmission.


[High] FL1 Proposal 5.3-1a 
For D2R scheduling, if a scheduling information is explicitly indicated, it is carried by higher layer signalling instead of L1 R2D control signalling.
[e.g., The payload size (i.e. TBS-like) for PDRCH transmission with variable size, D2R chip duration etc.]

[High] FL1 Proposal 3.4-1a
At least support case 3 of interleaved Msg3 transmissions between different Msg2 (e.g., Msg2-Msg3-Msg2-Msg3), where the PRDCH for Msg2 transmission and the corresponding Msg3 are sent one by one. 
Proposals for April 9 Offline

[High] FL2 Proposal 3.1-2b 


The starting time for a D2R transmission 


[High] FL2 Proposal 4.2-1c

if X=1 time domain resource only for Msg1 transmission is supported, 


if X=1 and X=2 time domain resources for Msg1 transmissions are supported, 




[High] FL2 Proposal 4.3-1a
A device is not  to monitor a corresponding R2D transmission earlier than TD2R_min after the end of  a D2R transmission from the device. 











“Only support X=1 time domain resource for D2R transmission for Msg3 in response to a PRDCH for Msg2 transmission.”


[High] FL2 Proposal 3.4-1a
At least support case 3 of interleaved Msg3 transmissions between different Msg2 (e.g., Msg2-Msg3-Msg2-Msg3), where the PRDCH for Msg2 transmission and the corresponding Msg3 are sent one by one. 

Agreements achieved in RAN1#120bis meeting

3GPP TSG RAN WG1 Meeting #120bis	      R1-2502500 
Wuhan, China, April 7th – 11th, 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 4.1-1
If any timing requirement(s) need to be specified from device perspective, the timing(s) do not include the impacts of SFO from the RAN1 perspective.
Whether 3GPP needs to specify some requirement on device’s SFO is up to RAN4 discussion.
 specify

[High] FL2 Proposal 4.3-1a
A device is not required to monitor a corresponding R2D transmission earlier than TD2R_min after the end of  a D2R transmission from the device. 

For today’s offline 
[High] FL3 Proposal 3.1-4:
se 1 bit indicate the value of X (X=1 or X=2) time domain resource(s) for Msg1 transmission(s).


[High] FL3 Proposal 3.1-5:
For X=1 or X=2 , the starting time forthe first Msg1 time domain resource is the end of the R2D transmission triggering random access  .
FFS Toffset1 is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access.



[High] FL3 Proposal 3.1-6:
For X=2 indicated in a R2D transmission triggering random access, the starting time for the second Msg1 time domain resource is determined by at least following options: 
Option 1: derived based on the first Msg1 time domain resource after Toffset2.
FFS details of Toffset2, including the reference time point for Toffset2 and Toffset2 is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access
Option 2: Toffset3 indicated directly by the R2D transmission triggering random access, where the Toffset3 is the time interval between the end of the R2D transmission triggering random access and the start of the second Msg1 time domain resource   

from the end of Toffset1, the starting time is derived based on the length of first Msg1 time domain resource plus Toffset2

[High] FL3 Proposal 3.2-1a
For FDMA of multiple Msg1 transmissions in response to a R2D transmission triggering random access, support only the same data rate for the FDMed Msg1 transmissions. 
For FDMA of multiple Msg3 transmissions in response to a PRDCH for Msg2 transmission, FFS same or different data rate(s) for the FDMed Msg3 transmissions. 

[High] FL3 Proposal 5.2-2 
Down-select from the following options for indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size: 
Option 1: 7 bits for byte-level D2R payload size indication
Option 2: X-bit (1<=X<=7) codepoint based indication, where each codepoint indicates one size from 2x predefined D2R payload sizes.

[High] FL3 Proposal 5.2-3 
Down-select from the following options for indicating the the FEC and the number of repetition(s) for PDRCH transmission in the corresponding PRDCH:
Option 1: Separate indication of FEC and number of repetitions  
Option 2: joint indication of FEC and number of repetitions  

 
Agreements achieved in RAN1#120bis meeting
Agreements made in 944
Agreement
For scheduling D2R transmission, any scheduling information related to resource allocation that needs to be signaled is indicated by higher-layer signaling via the corresponding PRDCH.

Agreement
For Msg 1 transmission determined by one R2D transmission triggering random access, support X=1 and X=2 time domain resource(s) for D2R transmission(s) for Msg1 only, where each D2R transmission for Msg1 occurs in one time domain resource of the X time domain resource(s) in Rel-19.
All devices support the above
Note: the impact of specification support (at least including signalling overhead) for X=2 to a reader supporting only X=1 should be minimized
Only support X=1 time domain resource for D2R transmission for Msg3 in response to a PRDCH for Msg2 transmission

Agreements related to 944
Agreement
For the initial values of the shift register of the CC encoder, the initial values of the shift register of the CC encoder are set to the values corresponding to the last (K-1) information bits defined in TS 36.212.
Note: K is the constraint length.
For discussion on timing relationships in 9.4.4, the entire processing time for encoding (including finishing CRC encoding) should be taken into account

TDoc file reading error

3GPP TSG RAN WG1 #120bis		R1-2502608
Wuhan, China, April 7th – 11th, 2025

Source: 	Apple Inc.
Title:                     On multiple Access, scheduling and control 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: To determine the frequency-domain locations of Msg1 with a small frequency offset, the following parameters are provided in paging command:
A chip duration; 
A ‘R’ value indicating the repetition number of a Manchester codeword within a chip duration, 
The number of FDMed Msg1 in a single occasion. 
Proposal 2: To support TDMA for Msg1 transmissions, at least the following is indicated in paging command: 
Starting of a first Msg1 transmission. 
A timing offset value. 
Proposal 3: Support both common and separate montoring window for Msg2 reception. 
Proposal 4: The Msg2 monitoring window configuration (i.e., common or seperate) is indicated by the Msg0 that triggers the RACH procedure.      
Proposal 5: The R2D timing acquisition part preceding the PRDSCH indicates the OOK chip length used for the following PRDCH transmission.  
Proposal 6: Separate CRCs are attached to L1 R2D control information and R2D data. FFS: Same or different CRC lengths for control information and R2D data. 

3GPP TSG RAN WG1 #120-bis                               R1-2502674
Wuhan, China, February 7th - 11th, 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.
RAN1 needs to make a decision on the supported value(s) of X (i.e. number of time domain resources for D2R transmission(s) for Msg1 triggered by one R2D transmission) in RAN1#120-bis.
Timeout for Msg2 monitoring can be handled by higher layers if deemed necessary.
The following “Way 2” is used at least to support retransmission of Msg2 which was already agreed during the SI phase:
Way 1: Non-interleaving Msg3 transmissions (e.g., Msg2-Msg2-Msg3-Msg3), where Msg3 transmissions are FDMed and follows all PRDCHs for Msg2 transmissions. 
Way 2: interleaving Msg3 transmissions (e.g., Msg2-Msg3-Msg2-Msg3), where the PRDCH for Msg2 transmission and the corresponding Msg3 are sent one by one.
It should be supported that the following can be multiplexed in a same R2D transmission:
RAR scheduling Msg3 transmissions, 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).
Decision on “early termination” during R2D reception can only be made by higher layers.
The functionality of “early termination” during R2D reception is not a compelling reason to support defining L1 R2D control information.
The functionality of determining the end of PRDCH transmission is not a compelling reason to support defining L1 R2D control information.
If Option 1 (TBS information via implicit/explicit L1 R2D control information) is used for determining the end of PRDCH transmission, a reasonably small number (e.g. ~3) of bits should be strived for the size of the “TBS information”.
One R2D transmission carrying a paging message determines one corresponding time domain resource for Msg1, after which more short R2D transmission(s), if any, can each determine one additional time domain resource for Msg1.
Each triggering R2D transmission is followed by a corresponding time domain resource for Msg1.
In case a PRDCH for Msg2 transmission is in response to multiple Msg1 transmissions which are initiated by a R2D transmission triggering random access, the “multiple Msg1 transmissions” are on a same time resource.
A device is expected to receive a PRDCH for a corresponding Msg2 no earlier than TD2R_min after the end of the time resource for its Msg1 transmission.
It is supported that a device can receive a first part of a PRDCH in an R2D transmission, and determine 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”.
The decision on “early termination” during R2D reception is made by higher layers.

3GPP TSG RAN WG1 #120bis	 R1-2502692
Wuhan, China, April 7th – 11th, 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.
Observation 3: Since the processing time of the analog front end is very short, the conversion time between R2D and D2R can be approximated as the baseband processing time.
Observation 4: Support the definition of the switching time between R2D and D2R based on the reference clock cycle of the D2R link, e.g., 10 times the reference clock cycle.
Observation 5: The timing relationship between D2R and R2D can still use the Option1 scheme.

Proposal 1: Supports two steps for Msg1 Frequency domain resources allocation in which paging message indicate the maximum value of Y and RA trigger R2D message indicate the detail R values could be used for small frequency shift.
Proposal 2: Supports configuration of X=2 time domain resources and configuration of frequency domain resources at the same time.
Proposal 3: Support configuring guard periods between time domain access resources to resolve timing errors of adjacent time domain resources caused by residual SFO in devices.
Proposal 4: The control information of Msg2 indicates the relevant information for the device to determine the Msg2 response message.
Proposal 5: Support option 2 as the selection scheme for the starting reference point of Msg2.
Proposal 6: Support Option 2 for the time duration for A-IoT Msg2 monitoring.
Proposal 7: Do not support option 1 for the allocation of Msg3 frequency domain resources.
Proposal 8: Use the same bitmap to indicate the time-frequency resources for Msg3 of all responding users.
Proposal 9: The control information includes the message type.
Proposal 10: The control information of the unicast message contains the device ID.
Proposal 11: Support L1-control signal to carry control information.
Proposal 12: Adopt the control information and its characteristics in Table 2.
Proposal 13: Support option 1 for the timing transmission of D2R.

3GPP TSG RAN WG1 #120bis				                                                                       R1-2502699
Wuhan, China, April 7th – 11th, 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.
Observation 2: Device may select unavailable sub-channel if reader do not indicate that before, which brings resource waste and reduce the reliability of inventory.
Observation 3: TR2D_min will be impacted by the device’s processing time of a R2D transmission and the preparation time of the corresponding D2R transmission including device’s transition time, i.e., RXTX.
Observation 4: TD2R_min will be impacted by the device’s transition time, i.e., TXRX.
Observation 5: For TR2D_R2D_min and TD2R_max, it can avoid the device to continuous reception, which can save device’s power consumption.
Observation 6: The devices should response to reader within TR2D_max after R2D transmission.
Observation 7: When multiple devices transmit simultaneously D2R transmission to reader using FDMA, reader needs to check different devices to determine as near based on their device ID.
Observation 8:  Based on the scope of the WID, small specification impact will be introduced for device (un)availability direction 1.
It is proposed that
Proposal 1: Support TDMA with X>1 for MSG1 transmission and the maximum number of X is 4 can be considered.
Proposal 2: Further consider the combination of TDMA and FDMA for MSG1 transmission to further improve the efficiency of random access.
Proposal 3: Support a MSG1 resource set including MSG1 multiple resources indicated by a R2D signaling.
Proposal 4: The time interval of the R2D signaling and the corresponding MSG1 resource set should be within [TR2D_min, TR2D_max] or the device select a resource within [TR2D_min, TR2D_max].
Proposal 5: Consider whether the guard time is included in the MSG1 resource or not.
Proposal 6: Based on the MSG1 resource set, further study how R2D signaling indicates specific resource for device(s) for contention-free based random access.
Proposal 7: For the MSG1 retransmission, the same information of MSG1 resource set for initial transmission can be used.
Proposal 8: For the design of random ID, clarify that in which group (RAN1 or RAN2) should it be discussed.
Proposal 9: 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 10: 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 11: 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 12: For Option 2, consider how the device to determine its own location within a MSG2.
Proposal 13: Further study the retransmission resource of MSG2.
Proposal 14: 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 15: MSG2 can indicate the resource size of MSG3 and the frequency location can be determined by MSG1.
Proposal 16: Consider whether/how to delay MSG3 scheduling based on original configuration. 
Proposal 17: Consider backoff scheme for improving the reliability of inventory for D2R FDMA because of sideband modulation/harmonic/intermodulation interference, etc. 
Proposal 18: Specify the value of TR2D_min, TD2R_min, TR2D_R2D_min, TD2R_max, and TR2D_max. 
Proposal 19: Study general processing time to be compatible with all types of devices and the processing time between T R2D_min and T D2R_min.
Proposal 20: For D2R transmission, the other scheduling information can be carried by PRDCH
Coding scheme and coding rate
Time/frequency resource
number of repetitions
Target device(s) to trigger random access, e.g., device ID, group ID, all devices
L1 control information is considered
Proposal 21: For R2D transmission, the following L1 control information can be considered
the end of PRDCH/the length of PRDCH
MCS related information such as coding scheme/modulation
device associated ID
Proposal 22: For R2D L1 control information if supported, discuss whether indication information could be used for one whole inventory process. 
Proposal 23: For PRDCH, separate CRC for R2D control part and R2D data part is preferred.
Proposal 24: Consider D2R sequence or pattern design for proximity determination at reader side.
Proposal 25: Support energy status indication by device for device (un)availability direction 1.

3GPP TSG RAN WG1 #120bis                                                       R1-2502707
Wuhan, China, April 7th – 11th, 2025
 
Agenda item:	9.4.4
Source: 	MediaTek Inc.
Title: 	A-IoT – Other aspects
Document for:	Discussion and decision

Conclusion 
In this contribution, we have the following proposals. 
Proposal 1: Support that one Msg2 can contain responses to multiple Msg1 transmissions from multiple devices. FFS: timeline restrictions
Proposal 2: To determine or derive the end of PRDCH transmission, support TBS information via implicit/explicit R2D control information.
Proposal 3: For D2R control information, support that devices send NACK/ACK to indicate un/successful reception of an R2D command.
Proposal 4: For TDM’ed D2R transmissions, support guard intervals between consecutive D2R transmissions from different devices. FFS: guard interval values
Proposal 5: For FDM’ed D2R transmissions, support that devices can select frequency resources randomly or based on their calculation aiming for distinguishing from other devices.

TDoc file reading error

3GPP TSG RAN WG1 #120bis	                      	 R1-2502753
Wuhan, China, April 7th – 11th, 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:  R2D transmission triggering random access procedure provides X={1,2} time domain resource(s) and Y>=1 small frequency shift(s) for D2R transmission(s).
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:  R2D control information for Msg1 indicates the number of available repetition numbers R for small frequency shifts and the number of available access occasions (i.e. X). 
Proposal 4:  R2D control information for Msg1 indicates either one of time length of access occasion and MCS-like information. 
Proposal 5:  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 6:  For Msg3 or command case, time length of D2R occasion is scheduled by R2D control information.
Proposal 7:  D2R transmission cannot exceed the scheduled D2R occasion with timing errors due to residual SFO.
Proposal 8:  A-IoT device can finish its D2R transmission without utilizing all scheduled D2R resource.

3GPP TSG RAN WG1 #120bis			R1-2502769 
Wuhan, China, April 7th – 11th, 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.
ID associated with device(s)
Chip duration of R2D data
Proposal 2: 
Following options can be considered on “ID associated with device(s)” and “cast type” in R2D control.
Alt.1: Cast type (i.e., broadcast or unicast) is not indicated. ID is indicated for both unicast R2D Tx and broadcast R2D Tx. A specific ID is assigned for broadcast R2D Tx.
Alt.2: One field X in R2D control indicates cast type (i.e., broadcast or unicast), and another field Y in R2D control indicates ID for unicast. If cast type is indicated as broadcast by field X, field Y is reserved.
Proposal 3: 
Support following structure of R2D transmission.
R2D timing acquisition signal immediately precedes L1 R2D control, and L1 R2D control precedes R2D data.
Further discuss whether a gap is needed between L1 R2D control and R2D data. 
Proposal 4: 
Separate CRC is attached to L1 R2D control information and R2D data.
Proposal 5: 
For D2R transmission in step C2/D2R data transfer after random access, support scheduling information of D2R transmission in R2D higher layer signaling. 
Proposal 6: 
For D2R transmission in Msg3, scheduling information is carried in higher layer payload of Msg2. 
Proposal 7: 
For D2R transmission in Msg3 and D2R transmission in step C2/D2R data transfer after random access, following scheduling information is carried in higher layer payload of corresponding R2D transmission as well as frequency domain resource/chip duration/payload size. 
Repetition factor.
Whether FEC is enabled.
Presence of D2R midamble and gap between two D2R x-ambles.
Proposal 8: 
For D2R transmission in step C2/data transfer after random access, ID associated with device(s) indicated in L1 R2D control is applied for both scheduling of R2D reception in step C1 and scheduling of D2R transmission. 
Proposal 9:
Clarify the scheduling of segment of D2R.
One segment is transmitted in one PDRCH.
Each segment is scheduled by a corresponding R2D respectively.
Proposal 10:
Support ACK/NACK feedback in D2R transmission in step C2/D2R data transfer after random access corresponding to R2D reception in step C1.
Further discuss whether the ACK/NACK feedback is L1 D2R information or higher layer D2R information. 
Observation 1:
Compared to X=1, a R2D triggering random access determining X>1 time domain resources for Msg1 has the following benefits.
Lower overhead of R2D triggering random access. 
Shorter inventory completion time. 
Proposal 11:
Support R2D triggering random access determines X=2 time domain resources of Msg1 Tx.
Each R2D transmission can determine X=2 time resources of Msg1, where the initial R2D triggering RA can be “A-IoT paging”, and the design of subsequent R2Ds triggering RA can be further discussed, e.g., “query-rep-like” or a simple “R-TAS”.
Proposal 12:
Support of X>1 cannot be up to device implementation.
Proposal 13:
For D2R transmission timing, option 1 or option 2 can be supported with adding the following clarification in red text. 
Option 1: Define a maximum time T_R2D_max between a R2D transmission and the corresponding D2R transmission following it, so that the device transmits D2R transmission within [T_R2D_min, T_R2D_max]. 
 and , where T can be a fixed value. 
Option 2: The corresponding D2R transmission timing T_R2D following a R2D transmission is determined based on the control information in the R2D transmission, where T_R2D ≥ T_R2D_min.
Timing drift due to SFO is handled by RAN4 requirement
Proposal 14:
For Msg2 in response to TDMA of X>1 (if supported) Msg1 transmissions initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponding to the A-IoT Msg1 transmitted by the device no earlier than  after the end of the last of X time domain resource(s) for Msg1 transmission(s). 
The value of  should consider Tx-Rx switching time at device. 
 Proposal 15:
For Msg2 in response to X=1 Msg1 transmission initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponding to the A-IoT Msg1 transmitted by the device no earlier than  after the end of the time domain resource for Msg1 transmission. 
The value of  should consider Tx-Rx switching time at device. 
Proposal 16:
Support , i.e., 
For Msg2 in response to TDMA of X>1 (if supported) Msg1 transmissions initiated by a R2D transmission triggering random access device is expected to receive a PRDCH for Msg2 corresponding to the A-IoT Msg1 transmitted by the device no later than  after the end of the last of X time domain resource(s) for Msg1 transmission(s).
For Msg2 in response to X=1 Msg1 transmission initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponding to the A-IoT Msg1 transmitted by the device no later than  after the end of the time domain resource for Msg1 transmission. 

3GPP TSG RAN WG1 Meeting #120bis    	            R1-2502842
Wuhan, China, April 7th – 11th, 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 D2R multiplexing/multiple access, 
Proposal 1: Support X>=1 D2R TDMA. 
The maximum value of X is dependent on the D2R transmission time and the guard intervals for SFO tolerance. 
FFS: D2R transmission time restriction to support X=2 or 3.

Consider short R2D transmission for timing to reduce the guard intervals between adjacent TDMA resources.


Proposal 2: For D2R FDMA, 
To have sufficient guard band for large SFO, the frequency shifts at R*Df with Df=BW and R={2, 8, 16, 32, …} can be used. 
FFS: selection/indication of the FDMA frequency shifts
To enhance spectrum efficiency, scalable data rates for higher frequency shifts of D2R FDMA can be considered to further improve the spectrum efficiency. 

Proposal 3: Further consider the TDMA/FDMA patterns with same or scalable data rate.

For scheduling and timing relationships, 
Proposal 4: For TR2D between a R2D transmission and the corresponding D2R transmission following it,
TR2D is determined for each X time-domain resource based on the control information in the R2D transmission (Option 2).
FFS: reference D2R chip rate for Y>1 FDMA
TR2D_min <=TR2D <= TR2D_max, where TR2D_max/TR2D_min are based on TR2D and the SFO tolerance.

Proposal 5: for TD2R between D2R Msg1 transmission and the corresponding R2D Msg2 transmission
TD2R_min and TD2R_max can be defined with TD2R_min <= TD2R <= TD2R_max, determined based on the control information in the R2D transmissions.
FFS: reference D2R chip rate for TD2R_min and TD2R_max in case of Y>1 FDMA
FFS: TD2R_max for one or multiple Msg2 transmissions.

Proposal 6: For Msg2 monitoring
The device is NOT expected to monitor TMsg2_start earlier than TD2R_min after the end of the Msg1 transmission. 
The device is expected to monitor TMsg2_start no later than TD2R_min after the end of the last Msg1 time domain resource(s).
Note: Whether device starts monitoring TMsg2_start earlier than TD2R_min after the end of the last Msg1 time domain resource(s) is up to device implementation. 
The device is expected to monitor TMsg2_start no later than TD2R_max (if defined) after the end of the last Msg1 time domain resource(s)
Otherwise, TD2R expires (if reaches TD2R_max)

For R2D control design, 
Proposal 7: For R2D control
The message type, transaction ID, ID associated with devices, resource allocation information for R2D can be indicated via R2D L1 control with separate CRC for early indication/termination. 
The resource allocation information for D2R Msg1/Msg3 can be included in R2D MAC PDU.
The resource allocation information for D2R response can be included in R2D L1 control to support (un)successful detection of R2D data reception.

For D2R control design, 
Proposal 8: For D2R data transmission, the transmitted TBS can be smaller than that of TBS indicated in the R2D control.
Alt1: explicitly indicate transmitted TBS 
Alt2: implicitly indicate transmitted TBS 

Proposal 9: Further consider D2R control carried in MAC PDU or L1 control for different D2R message.

3GPP TSG RAN WG1 #120bis			R1-2502890
Wuhan, China, April 7th – 11th, 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 Msg2 transmission in response to multiple Msg1 transmissions, which is initiated by a R2D transmission triggering random access, support the starting time for Msg2 monitoring is common for multiple Msg1 resources. 
Proposal 2: For transmission of R2D control information for R2D reception and D2R scheduling, support Option 1
Option 1: L1-control signaling  
Proposal 3: Rel-19 A-IoT, support indicating ID associated with device and message type information in the R2D L1 control information for R2D reception.  
Proposal 4: Support a PDRCH can be used to transmit D2R data only or to transmit both D2R data and D2R L1 control (if D2R L1 control is identified as needed).  
Proposal 5: Support L1 D2R control information to indicate whether reception of the R2D command at the device is successful or not.  

3GPP TSG RAN WG1 Meeting #120bis		                                                     R1-2502916
Wuhan, China, April 7th – 11th, 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: R2D trigger used to determine the start of the RACH time window for transmission of MSG1 is supported.
The time duration between the reception of R2D trigger and the start of RACH time window is indicated by the TR2D_min.
Proposal 10: For FDMA of multiple Msg1 transmissions in response to a R2D transmission triggering random access:     
Based on indicated resources in R2D transmission
Proposal 11. 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 12: The starting time for monitoring Msg.2 should be common for all devices irrespective of the common or separate Msg.2 transmission.   
Proposal 13: For Msg2 in response to TDMA of X>1 and X=1, Msg1 transmissions initiated by a R2D transmission triggering random access, a device is expected to receive a PRDCH for Msg2 corresponding to the A-IoT Msg1 transmitted by the device no earlier than TD2R_min after the end of the last of X time domain resource(s) for Msg1 transmission(s).
Proposal 14: Define the value of TR2D_min, TD2R_min, TD2R_max, and TR2D_max .
Proposal 15: 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 16: 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 17: 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 18: 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 19: Support non-interleaving Msg3 transmissions for separate PRDCH for Msg2 transmission corresponding to one or multiple Msg1.

3GPP TSG RAN WG1 Meeting#120bis		R1-2502928
Wuhan, China, April 7th – 11th, 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: Support TDMA of X>1 and if supported, the maximum value of X is 2.
Proposal 2: Further discuss the Common-Msg2 and FDMed Msg3 transmission cases when TDMA and FDMA is supported in Msg1 transmission.
Proposal 3: If the difference between [TR2D_min, TR2D_max] is large when the X time domain resource is 1, support option 2, otherwise support option 1.
Proposal 4: Supports the same size of the guard time of time domain resources on the same BTx_D2R and different sizes of the guard time on different BTx_D2R.
Proposal 5: Suggest that the transmission method of Msg2 and Msg3 should be decided first and the starting time should be decided later

TDoc file unavailable

3GPP TSG-RAN WG1 Meeting #120bis	     R1-2503104  
Wuhan, China, April 7th – 11th, 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
For any timing requirement that needs to be specified from device perspective by RAN1, the timing(s) do not include the impacts of SFO from the RAN1 perspective.
Whether 3GPP needs to specify some requirement on device’s SFO is up to RAN4 discussion.
Note: RAN1 will not specify TR2D_min or TR2D_max in Rel-19
Note: SFO may still be considered when discussing time-domain resources for Msg1 when X=2

Agreement
Use 1 bit to indicate the value of X (X=1 or X=2) time domain resource(s) for Msg1 transmission(s).
Agreement
For X=1 or X=2, from device perspective, the starting time for the first Msg1 time domain resource is Toffset1 after the end of the corresponding R2D transmission triggering random access.
FFS Toffset1 is predefined in the spec or indicated implicitly or explicitly by the R2D transmission triggering random access.
FFS detailed value(s) of Toffset1, considering at least the device processing time including FEC impact
FFS: how to define the end of the R2D transmission in 9.4.1

Working assumption
For X=2, from device perspective, for determination of the starting time for the second Msg1 time domain resource: 
Derived based on the starting time of the first Msg1 time domain resource plus Toffset2
FFS Toffset2 is predefined in the spec or derived by a rule or indicated implicitly or explicitly by the R2D transmission triggering random access.

Agreement
At least for CBRA, for FDMA of multiple Msg1 transmissions in response to a R2D transmission triggering random access, support only the same data rate for the FDMed Msg1 transmissions.
Working assumption
For indicating the payload size (i.e. TBS-like) for PDRCH transmission with variable size:
7 bits for byte-level D2R payload size indication

Agreements related to 944
Agreement
For the initial values of the shift register of the CC encoder, the initial values of the shift register of the CC encoder are set to the values corresponding to the last (K-1) information bits defined in TS 36.212.
Note: K is the constraint length.
For discussion on timing relationships in 9.4.4, the entire processing time for encoding (including finishing CRC encoding) should be taken into account